Are you ready to go? More importantly, are your Product Backlog Items “Ready to be worked?” In this blog post we’ll explore the concept of “Ready”, the I.N.V.E.S.T. Criteria (INVEST), and why developing a “Definition of Ready” is such an important step in building a high performing Scrum team.
One of the things I see consistently in my coaching practice is teams failing sprints because they commit to work that the team has not refined well enough. They either hyper-focus on how to solve it and miss big picture items, or they rush through and miss the details that cause “Godzilla to pop out from behind a rock”. Setting and adhering to a clear Definition of Ready can help your team avoid these pitfalls and improve your outcomes.
What is a Definition of Ready?
In Scrum, “Definition of Ready” is a checklist that lets a team know that a user story or product backlog item (PBI) is fully understood, defined, and agreed upon by the development team and stakeholders. It is important because it ensures that the team is clear on the requirements and objectives of a given task before beginning work on it, reducing the likelihood of misunderstandings or rework.
Your Definition of Ready lets a team know when they have refined an item well enough to be able to commit to it during Sprint Planning. Often, we see teams use the INVEST acronym as the criteria for their Definition of Ready. This acronym stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Why is this important? Imagine you are cooking an elaborate date night meal. You read all of the instructions, buy all of the ingredients, but when you start to prepare it, you realize you forgot a key component. You started preparing the meal before you had everything in place and ready to go. While this might derail your next date night, failure to ensure work is ready to be worked could cause your team to fail an entire Sprint if you aren’t careful.
How do you create a Definition of Ready?
The answer to most questions in the Agile world begin with the first value from the Agile Manifesto — Individuals and Interactions. Creating your Scrum team’s Definition of Ready is no exception. Often you will have these conversations as part of a team launch, but you can have them at any point the team is ready or feels they need to improve their Refinement and Planning.
If you have a brand new team, you might start the conversation by reviewing the INVEST criteria and asking them to consider what that might look like for their team and their specific domain. From there, build a simple and concise checklist based on the INVEST criteria. You will review this checklist for every item you are refining and ensure that PBI meets the criteria before it is brought into a Sprint.
If you have an existing team, have them look at what has and has not been going well in their Refinement. Specifically, have them consider a typical Sprint and see if there are times work did not get completed in the time box. Perhaps they can do a Five Whys Retrospective to identify the root cause of failures. Integrate that thinking with INVEST and create your Definition of Ready.
As I’ve mentioned a couple of times, INVEST is a great place to start your Definition of Ready thinking.
Is your story INVESTable?
INVEST refers to a common set of guidelines we often use in the Agile world to assess a PBI. Each letter in the acronym represents a characteristic that a user story should have in order to be considered ready for development.
Independent
The story should be able to stand alone and not depend on other stories or Product Backlog Items for it to be completed. We do this to ensure that every backlog item maximizes the ability to receive feedback. If something is dependent on something else, then we have to wait for multiple items to be completed before we get feedback. A rule of thumb in Agile is to reduce the length of time it takes to receive feedback. Making independent backlog items greatly helps with this.
Negotiable
The story should be open to discussion and change as more information and feedback become available.
Often, I will see early Agile practitioners create highly-detailed acceptance criteria or even “requirements” for a PBI. They will often feel the specificity will help the developers, but what typically happens in this scenario is a game of telephone. One person has an idea, another person tries to codify that idea as a list of acceptance criteria, that someone else tries to interpret. This is a situation in which too much detail might make you feel more confident, but in reality it can slow down the single most important thing in Agile…Individuals and Interactions.
I think Alistair Cockburn describes it best when he says “a card is a promise for a conversation”. You should have enough clarity on your Acceptance Criteria to understand how the world will be better when the work is done, but not so much that you are actually telling your developers how to do the work. The How will come once the work is committed and your team is solving the problem on the card…and they will negotiate how to solve the problem and make the world better.
Valuable
The story should deliver value to the customer. In other words, if this is the only thing you deliver in your sprint, it should independently deliver value to your users and your users should have a clear understanding as to what that value is.
The best way I’ve seen to ensure this is that your PBIs should be written in a way to highlight the problem that is trying to be solved. Agile teams create value by solving human problems. Instead of focusing your PBI on what you are building, instead focus on what problems you are solving. When you do this, it becomes much easier for everyone to understand the relative value created by any individual PBI.
Estimable
The story should be well understood and defined enough that the team can provide a relative sizing estimate on the work involved. Your team should be able to look at the PBI and have a fairly immediate thought on where they would estimate it using traditional Agile estimation techniques.
Small enough
The story should be small enough to be completed within a single Sprint. Ideally, it should be small enough that you can deliver several PBIs in a sprint. If your team is using the metrics-based planning we describe in our Scrum training, then you can quickly determine if a story is small enough once the team complete estimation. Remember, “if it doesn’t fit, you must split!” Make your story small enough to be done in a day or so in a typical sprint and you will increase your chances of success.
Testable
The story should have clear acceptance criteria that outline how the world is better when the work is done. This Acceptance Criteria should be written in a way that the team can quickly verify that the story is complete. Clarity is your friend here, but also, don’t overthink it. Keep in mind that all of this is wrapped around lots of conversation between the Product Owner, the Developers, and the Scrum Master. Keep your AC clear, focused, and avoid so much detail that you run the risk of making your story non-negotiable.
How do you use a Definition of Ready in refinement?
Once your Definition of Ready is established, use it to guide your refinement process. Make it visible to your team during refinement and refer to it as you are gaining an understanding of the work to be done on a Product Backlog Item. By just having it in mind, your team will be able to improve the quality of the conversation and questions happening during refinement.
After the team feels they have refined a PBI “enough to be Ready”, consider using a Fist of Five for each of your ready criteria to confirm the story is ready to go.
That is all it takes to start implementing a Definition of Ready. But, that’s not the end of implementation. Agile focuses on Continuous Improvement and that applies to your Definition of Ready as well.
How often do you update your Definition of Ready?
Agile is inherently focused on change for the better. Once your Definition of Ready is established and your team is using it for Refinement and Sprint Planning, periodically reflect and see if it needs to be iterated and improved.
Here are a couple of simple indicators that might tell you it’s time to iterate on your Definition of Ready.
Consistently Carrying Work Over
One indication your team’s refinement might be off (and your Definition of Ready) is if your team is consistently carrying work over from one Sprint to the next. While carryover work will, inevitably, happen, it is an anti-pattern we want to avoid. Carryover work increases the time it takes to receive feedback and reduces the value your team creates each Sprint. If you see this, consider revisiting your Definition of Ready.
Contentious Refinement
Another indication your team should revisit their Definition of Ready is when you see your team get frustrated or tense during Refinement. Friction and disagreement within a team is not automatically bad. Some frustration is natural when dealing with the complex world Agile teams work in regularly. However, if your team is consistently fighting and dreading Refinement, check in and see if they are all working to a shared understanding of the work that needs to be done to get an item Ready to take into a sprint.
Negative Outcomes
If your team is consistently releasing the work and the end users, customers, and stakeholders are not happy with the resulting effort, check to ensure your Definition of Ready is creating a clear understanding of the value that is expected by the work being performed. Involve your end users in the refinement process and see how they feel about the backlog items before the team commits to working on them. This rapid feedback, in alignment with your Definition of Ready, will help create better outcomes at the end of the sprint.
In Conclusion
In conclusion, the Definition of Ready is a critical aspect of agile software development that ensures that a team is prepared and equipped to begin working on a new user story or feature. It helps to establish clear guidelines and expectations for what constitutes a “ready” item, ensuring that the team can move forward efficiently and effectively. Additionally, it promotes collaboration, communication, and accountability among team members, ultimately leading to better quality work and faster delivery times. Implementing a Definition of Ready can be a powerful tool for any agile team looking to improve their workflow and increase productivity.
