Definition of Ready

Introduction

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:

Life of a User Story from Concept to Happy User

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 life of a User Story in a typical Scrum project

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.

Synchronization points

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.

Slides

These are the slides from my talk at XP 2011 in Madrid:

Conclusion

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.

15 Responses to Definition of Ready

  1. Pingback: Confluence: ATP-CMS

  2. Pingback: Confluence: Portal

  3. Pingback: Thoughts about ready for development | btd67

  4. Pingback: Confluence: LL Bean BOSS

  5. Pingback: Confluence: Mobile

  6. Pingback: Confluence: Agentur Köln

  7. Pingback: Confluence: Group - Technology

  8. Pingback: Confluence: Project Management Continuity

  9. ctreber says:

    Really good article! Just what I needed to sort my mind regarding “how much should (must!) we in our product owner team do before we can consider our part done”, in respect to creating and detailing user stories at least.

    What are your thoughts on this:

    By the time you are are ready for implementation (as in writing actual code), you ‘ll have to do the same work as for use cases, with the (dis?) advantage of not having written everything down in great detail. If you don’t clarify all details relevant to what you are implementing you are making assumptions, hopefully within the permissible range.

    If you don’t write the details down, they must be in the head (“tribal knowledge”) or in the code, which may cause problems or not. You say “I am not suggesting to turn user stories into specifications”. I would make the degree of documentation dependent on factors like colocation, fluctuation, future handovers (like, from initial implementation into maintenance), contractual relationship (“finger-pointing time”), and general desire for written documentation.

    I am well aware that the points I am listing likely identify a not-really-agile project, or conditions that are not conducive to Agile. Alas, I guess this is what many aspiring-to-be-agile projects have to deal with, an environment that is pretty conventional…

    So maybe I can answer my questions myself: If you need to write a l lot down for the reasons listed above, maybe, considering the circumstances, Agile is not the right approach.

  10. Pingback: User Stories: Ready, Set, Go! part-2

  11. Pingback: TFS as perfect tool for Scrum (Part 4) – Sprint | The Road to ALM

  12. Pingback: Confluence: MobileHub

  13. Very good article.

    I have a written an article on same topic – ‘Managing the iteration Flow–Getting Ready-Ready for user stories in an agile iteration’
    The link of the article is here –

    http://www.technodeation.com/2013/01/managing-iteration-flow-getting-ready.html

  14. Pingback: Confluence: Project - Dashbid

  15. olaflewitz says:

    Ken, this is awesome. And you are as well…
    take care
    -Olaf

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 29 other followers

%d bloggers like this: