Many agile teams are familiar with Definition of Done as a set of agreements that let everyone know when a user story (or a sprint or a release) is really done, and all necessary activities are complete. Definition of Ready is a set of agreements that lets everyone know when something is ready to begin, e.g., when a user story is ready to be taken into a sprint, or when all necessary conditions are right for a team to start a sprint.
Life of a User Story
The typical life of a User Story is shown in the following diagram:
At some point in time someone will have an idea or concept for a new feature. The concept will be expressed as one or more user stories, and get added to a product backlog. The team, working together, will figure out how to turn this concept, expressed as one or more user stories, into a real product feature that delights end users. That’s the abridged version; all sorts of interesting things happen along the way.
Viewed another way, we can consider the level of focus that a user story gets at different times.
The horizontal axis represents time. The vertical axis examines the level of focus on the user story from the perspective of the Product Owner and the Delivery Team. Of course there are other stakeholders in the user story, but these are the two perspectives I want to consider right now.
Let’s assume we’re talking about a typical Scrum team, although the details are similar for any other agile process. At some point before the Sprint starts (represented by Sstart) the Product Owner has a high degree of focus on the user story. They are trying to figure out what the value is for the user, and how to express that as a user story. As we approach the start of the Sprint, the rest of the team increases their focus on the user story. As part of their Backlog Grooming and look-ahead planning activities the team will start to consider the user story’s general feasibility, acceptance criteria, dependencies and related details. The team will size the user story, and maybe even start to think about the tasks.
Between Sstart and Send the team works on delivering the user story. The team gets into more detail than the Product Owner during this period, as they figure out the software design, test cases, user experience details, implementation details, and generally work towards getting the user story Done (according to the team’s own Definition of Done) and Accepted by the Product Owner. The Product Owner is involved every step of the way – the intention of the diagram is to convey that the team is bringing a higher degree of focus during this time.
After the user story has been accepted the team’s focus changes to the next user story.
At some point after the Sprint ends (represented by Send) the team is considering the product as a whole, and preparing to ship it. By this time the user story has been combined with many others to form a complete product.
The Product Owner and Delivery Team work at different cadences. They focus on different things at different times. Time-boxed iterations (or Sprints) are one way to synchronize their different areas of focus. Having a Definition of Ready that serves as a set of mutual agreements between Product Owner and the rest of the team brings a focus to upcoming Sprint synchronization points.
Why Have a Definition of Ready?
A Definition of Ready lets everyone know when a User Story is really ready to be taken into a Sprint. It does not need to be “100% defined” with all acceptance criteria, etc. but it should be “ready enough” so that the team is confident they can successfully deliver the user story.
It will save a lot of time if each user story meets Definition of Ready before the Sprint Planning meeting, but it is also OK to work on the user story during the Sprint Planning meeting to bring it to Ready.
Sample Definition of Ready
This section shows a sample Definition of Ready for a user story, and a sample Definition of Ready for a Sprint. I generally use these as baselines or starting points, and work with teams at the start of a project or release to customize the Definition of Ready for their product and environment.
Definition of Ready for a User Story
- User Story defined
- User Story Acceptance Criteria defined
- User Story dependencies identified
- User Story sized by Delivery Team
- Scrum Team accepts User Experience artefacts
- Performance criteria identified, where appropriate
- Person who will accept the User Story is identified
- Team has a good idea what it will mean to Demo the User Story
Most of these bullet points are targeting specific problems I have encountered on projects over the years. A little preparation can go a long way towards helping the team delivery user stories. When I presented this at XP 2011
, one of the participants suggested adding that last bullet point. I like that suggestion.
I advocate that teams do not commit to taking a user story into a Sprint unless there is sufficient clarity and evidence of commitment from Product Owners. Remember the “3 Cs” of a user story
(Card, Confirmation, Conversation). There’s a balance here, and judgement and common sense need to be applied. We don’t want to replace the Conversation aspect. I am not suggesting to turn user stories into specifications. I am suggesting that Product Owners and teams give themselves a greater chance at successful delivery of user stories by considering some issues ahead of the Sprint.
Definition of Ready for a Sprint
- The Sprint Backlog is prioritized
- The Spring Backlog contains all defects, User Stories and other work that the team is committing to
- No hidden work
- All team members have calculated their capacity for the Sprint
- Fulltime on project = X hours per day
- All User Stories meet Definition of Ready
Examples of ‘other work’ might include lab setup, build environment maintenance, creating a test application.
Scrum Masters, working with Product Owners and the rest of team, can use this to prepare for upcoming Sprints.
These are the slides from my talk at XP 2011 in Madrid:
Try using Definition of Ready to bring a focus to Backlog Grooming meetings and Look-Ahead planning activities. Product Owners can use it as a guide when preparing user stories for upcoming Sprints. Teams can use it as a checklist to make sure that they have an increased chance of success in delivering the completed user story, and that there is enough thought gone into the user story before they start to deliver it.