Often times we come across poorly written backlogs and defects. This not only leads to confusion but also creates rework in the sense that spending time to understand what is happening to the system and what are the expectations from developer or tester.
Here’s why developers need clarity in the backlogs or user stories
As someone said, clarity is divine. Without clarity there is chaos and confusion; ultimately this leads to delays is the software delivery. Maintaining clarity helps involved stakeholders in following manner –
- To identify work involved
- To come up with list of tasks, before actually working on the backlog or defect.
- To come with any proposals that can be shared with stakeholders for approvals (if required)
- To know risky areas upfront as far as possible
- To know dependencies/bottlenecks before working on the tasks
A highly skilled and experienced C# .NET developer knows how important it is to get the requirements clarified before starting the work.
Why should we provide details in the backlogs (or user stories)?
- Clarity on the use case to the developer
- To determine priority by the product owner and/or marketing
- After some time gap there is possibility of even submitter not remembering about how to reproduce the defect
- When we provide details, we come to know whether backlog is too big, if it is, then backlog needs to be broken to fit into one single sprint (just in case anything is missed in backlog grooming)
What should be provided in the backlogs (or user stories)?
- Crystal clear acceptance criteria is must. In absence of it, developer and tester cannot know what is the measuring criteria to mark the backlog as done
- To write test cases clarity on acceptance criteria comes handy
- Some of the generic tasks like code review, document update, test case writing must be added by default. In version one this is possible by creating Template Backlogs. (This may differ in between various defect / backlog tracking system)
- As far as possible list of tasks to be done should be added to avoid rework on tasks identification.
- A wireframe/screenshot of UI (if applicable)
- Establish dependencies between backlogs
- Map to parent Epic as far as possible, this associates a chain of requirements
Why should we provide details in the defects?
- To let severity determination by the product owner and/or marketing to prioritize the defect. Detailed information on the defect helps in the decision process.
- To let developer reproduce defect on his own
- To make developer, tester and other stakeholders on the same page
What should be provided in the defects (or user stories)?
- Exact use case with steps
- Observations after performing the steps
- What is the expected behavior from your perspective
- Initial severity, based on the pre-existing shared guidelines
- Initial priority, from your perspective (this can be discussed and then updated too)
- Build and release number of the software, service pack number and other useful info on which issue is seen
- Backlogs broken by the defect
- OS details
- Clear distinction between “Unit Testing Defect, Integration Testing Defect, Acceptance Testing Defect and Regression Defect” &/or other such types
- A screenshot of the issue (if applicable)
- Any input data/files necessary to reproduce the defect
Common for both backlogs and defects
- When discussion happens on the backlog/defect it should be captured and attached to it in the system. In future this helps to understand the requirements etc. for new comers and can be used as requirement documentation.
- Map to parent Epic as far as possible, this associates a chain of requirements that can be easily viewed
- Provide/attach any external links where discussion happened or that may help to understand the requirement
Note: All images belong to their original contributors.