It is very common that a developer looks at a PBI to work on, and finds out that it has limited or missing information. Usually, this is due to unclear requirements, ambiguous instructions or people simply don't understand the importance of getting the right information in the PBI.
When that happens, it is crucial for the developer to raise their voice and gather enough information so it meets the Definition of Ready. Additionally, anyone working on the task who doesn't fully understand should raise the problem ASAP.
Generally, there are a few pieces of information that every PBI should have:
- Title - Read the titles of PBIs should give an understanding of them
- Description - The required steps and critical information to complete the PBI
- Acceptance Criteria - Essentially the contract between the developers and the Product Owner
- Screenshots - E.g. Mock-ups, context for bugs etc
- Estimate - How long it's going to take
- Business value - What's the value for the Product Owner
If the PBI is missing any of these things, make sure they are defined. Don't be afraid to push back, all developers should understand exactly what is expected.
Remember, it is not your fault if there is missing information in a PBI, but it is if you allow that incomplete PBI into the Sprint.
The Definition of Ready helps to enforce this, by formally documenting the requirements for acceptance from the team. So, make sure to refer to this document if there is any confusion about a PBI definition.
Here are a few key checkpoints where these issues should be flagged:
- Backlog Refinement
- Sprint Planning
- Daily Scrums – after in the Parking Lot
- Before commencing work
Ideally, you want to flag the missing information early, but it is better late than never.
