Your 6-Point Checklist for Good Agile Requirements

If anyone has ever been in a painful sprint planning meeting, one of the things that makes a sprint planning meeting is that the product backlog items (PBI)/user stories/requirements brought into sprint planning aren’t quite ready for the Scrum team to review. They are half written, sometimes without acceptance criteria, not ordered, and brought in without any dev team members having seen the items before sprint planning.

To help address this issue, there is a concept called “definition of ready.” It’s not an official Scrum concept, but there are quite a few advantages to having a definition of ready, but it should also be noted that some Agilists have argued against definition of ready. The main argument is that it promotes too much major upfront planning and leads to over-engineered requirements, which is a valid concern. To combat this, the definition of ready needs to be lightweight while ensuring the team has enough of an understanding of the needs to reach the next steps of implementation. The critical benefit of a definition of ready is a shared understanding of what it means for PBI to be ready for sprint planning and to be worked on.

One of the most well-known forms of definition of ready is INVEST from Bill Wake. INVEST stands for:

• I– Independent
• N– Negotiable
• V– Valuable
• E– Estimable
• S– Small
• T– Testable

While there is a lot of value in Bill’s INVEST idea, below is an updated version that is more actionable:

First, after the Product Owner has created the PBI, have at least two dev team members (you can have as many as you like, but at least two) review the PBI. When they review the PBI, they should be able to address the following:

1. Do we understand the PBI/user story? – Do we understand what the PBI is asking of us?
2. Do we understand the acceptance criteria? – Do we understand how to ensure we have satisfied this need?
3. Do we understand the value? – If it’s not valuable, why are we doing it?
4. Do we know how to implement it? – If we don’t know how to implement the item, we may need to do some more research, perhaps by using a research spike.
5. Is it the right size? –  Recommended less than 5 days if your sprints are 2 weeks or longer). If it’s too big, break it down.
6. Do we have a better way of doing it? – If the dev team member has a better, faster, more effective, more efficient, or other recommendation to address this need, we want the dev team member to tell the Product Owner. I recommend that the Product Owner follow the dev team member’s recommendation unless there is a product or business reason not to follow their recommendation, but as a Product Owner, we appreciate hearing any recommendations the Dev team has.

Note that this conversation should happen prior to sprint planning to ensure the PBI is ready. If all six points are well aligned, then you are ready for the PBI to be reviewed by the entire Scrum team. By doing this, we have a greater guarantee of an effective sprint planning meeting and greater probably of success in our sprint.

Join us for our Certified Scrum Product Owner (CSPO) training to learn how to transform concepts and goals into a product backlog and ultimately, project deliverables.