Have you ever entered a Sprint taking on a User Story that you later regretted? For example:

• One that you should have broken down a wee bit more?
• Or one where the team had not a “snowball’s clue” how to technically implement?
• Or one where the value wasn’t clear from a business perspective?
• Or one where the estimate and the reality were not equal?
• Or one that, when you got it “Done”, you weren’t quite sure how to determine that it was done?

I’m guessing, of course you have. I encounter these scenes in teams I’m coaching all the time. And truth be told, it’s not a terrible event. Teams make mistakes…all the time. And they usually learn from them.

The real problem, from my perspective, is with the teams that continue to do this sprint over sprint over sprint. Yes, the dynamics slightly change, but the end result is the same.

The team is taking on User Stories that are truly not READY for the Sprint!

So the question is: what can be done to prevent it? Is there a technique that will prevent this from happening or are these teams doomed to keep repeating their mistakes? I’m glad you asked.

The Flip Side of Definition-of-Done

I hope everyone is familiar with the terminology Definition-of-Done (DoD)or Done-Ness from an agile methods perspective. It’s a common phrase and incredibly important to agile team health and maturity. It’s essentially exit criteria, if you will, for the teams sprint work.

At a User Story level, it’s common to refer to each story’s acceptance criteria as the done-ness check for story completeness. At a sprint complete level, it’s common to refer to the Sprint Goal as the checkpoint for what the team was trying to deliver. And done-ness also permeates into how each team member does their work. For example, are code reviews part of a teams’ done-ness criteria? If so, then they will consistently plan for and execute code reviews as a part of developing and delivering each story.

So the Definition-of-Done is an “exit criteria”; one that determines condition of completeness for work being delivered. But there is another criterion that is useful in agile teams at the “other end” of the workflow—the delivery end. Let’s call it Definition of Ready (DoR) or “Readiness Criteria”. In this case, it’s associated with each individual work item that flows through an agile team.

If you’re practicing Scrum, then it would be at the Product Backlog Item (PBI) level. If you’re an XP team or leveraging User Stories, then it would be for each story that enters a team. The readiness criteria would be a clear definition of what connotes a User Story or PBI that is “ready” for execution within the iteration or Sprint.

It turns out that preventing ill-defined stories (or work) from entering each Sprint in the first place, is an incredibly healthy way of warding off the challenges I described in the introduction. But let’s explore readiness in a bit more detail.

Ways of Looking At It

The 4–R’s

Tony Shawver is a coach and consultant working for Matrix Resources in Atlanta. In this , he described a method or approach for defining “The 4-R’s” of story readiness:

1. Raw – This is an “initial placeholder” User Story which generally only includes the title and possibly a supporting sentence or two. It allows the Product Owner or stakeholder to enter the general thought for later refinement.
2. Refined – In this state, the Story has been refined by the Product Owner or stakeholder and includes: a) an appropriate title, b) an adequate description, and c) acceptance criteria.
3. Reviewed – In this state, the Story has been reviewed by one or more team members. The team members have vetted the general requirement and posed needed questions/clarifications back to the Product Owner/stakeholder for response.
4. Ready – The content of the Story is complete, all questions/clarifications have been made, and all acceptance criteria are adequate for development and testing. This Story is now ready to be taken into a Sprint planning (or pre-planning) session.

Stories and work on the teams Product Backlog is moved through these ‘phases’ as a way of preparing each story for execution. Clearly a story could move from Raw to Ready very quickly. Let’s say it was a small, relatively straight-forward story that was clearly understood by the team. A few questions and some writing later, the story should be “good enough” for execution. Conversely, a complex or technically challenging story might take many iterative discussions to move it into a Ready state.

Ultimately, the team is the final arbiter for whether a story is ready or not—based on their understanding and ability to envision executing the story without major impediments.

Roman Pichler

Roman Pichler wrote a book related to the Scrum Product Owner role. Since he and I are competitive authors, I try to quote him as infrequently as possible. But he shared a that focuses on this topic and I thought it valuable to share. Here’s an excerpt:

 A ready story is a detailed user story with a narrative and acceptance criteria. It should also be clear if there are any story-specific operational qualities such as performance, and what user interface design should roughly look like. I prefer to capture the qualities on constraint cards, and the design on a piece of paper. The artifacts are simply attached to the story, as the picture below illustrates…

Roman brings up a couple of important points in your definition of readiness:

1. Operational Constraints – define any and all constraints that the story will have related to releasing it. I like the notion of viewing agile work from “concept to cash”. I.e., it’s not ‘done’ until it’s in production and being used by your customers. So, from that perspective, make sure that all of these constraints are visible as part of the story.
2. Sufficient Pre-work Design – another important balancing act agile teams have is guarding against BDUF (Big Design Up Front), while still doing just enough design to fully understand the scope and integration of a feature. This is particularly important when a team is working on cross-team features or on technically complex work. You can see design being needed at a UX level, but also in general.

Thanks to Roman for helping to “flesh out” a healthy alternative view to readiness.

Another way of Describing Ready

I personally like a checklist approach for describing teams’ readiness criteria for work.  Here’s an example of the sorts of checks that I’ve seen prove valuable for teams to leverage when maturing their stories:

• The Story is well-written; and has a minimum of 5 Acceptance Tests defined.
• The Story has been sized to fit the teams velocity & sprint length; for example somewhere between 1-13 points.
• The team has vetted the Story in several grooming sessions—its scope & nature is well understood.
• The team has the requisite skill-set & experience to implement the Story and deliver it to meet the organizational and teams’ Definition-of-Done.
• If required, the Story had a research-spike to explore (and refine) it’s architecture and design implications; or to explore the testability challenges associated with it.
• The Story describes end-to-end behavior in the system.
• The team understands how to approach the testing of the Stories’ functional and non-functional aspects.
• Any dependencies to other Stories and/or teams have been “connected” so that the Story is synchronized and deliverable as part of the “greater whole”.
• The Story aligns with the Sprints’ Goal and is cleanly demonstrable.

So there are no distinct phases in this case. A new User Story simply has to meet all of the above checks in order for it to be considered ‘ready’ for execution. How each story gets ready is up to the Product Owner for each Product Backlog collaborating with their team. It could take one or fifty steps to get there. It could be fast or slow. But working together, they decide on how to shepherd a story towards execution readiness.

Beyond Scrum, you can see how this technique would be useful. If you’re implementing Kanban, than readiness criteria is the definition work required for something to enter the “ready queue” on your Kanban Board.

Relationship to Backlog Grooming

So you might be asking yourself the question, how does a User Story achieve done-ness? From my perspective, it’s part of ongoing, real-time Backlog Grooming or Backlog Maintenance that a team takes on as a natural part of maturing their Backlog.

Regular grooming meetings provides a venue for these discussions, and as a part of grooming, I like a 4-phased approach to reviewing stories. What Sprint each story is planned for delivery is a leading indicator for when it’s grooming needs to be completed by. I call each phase a “different point of view or lens” for looking at the Backlog and what’s moving towards execution & delivery. For example:

• Lens One:  The Very Next Sprint – These Stories would need to meet the readiness criteria. Using a 4-R’s approach, these are READY.
• Lens Two:  2-3 Sprints in the Future – These Stories are quite mature. If they needed design work or spike work, it’s been done (or minimally planned). Using a 4-R’s approach, these are REFINED to REVIEWED.
• Lens Three:  The Next “Release” – These Stories our in the future. Typically, they’re far from ready, but the teams’ responsibility is to “get them ready”. Often early activity surrounds estimation and removing technical risk or ambiguity—so that the Product Owner can “plan for” and commit to the release. Using a 4-R’s approach, these are mostly being REFINED.
• Lens Four:  The Far Flung Future (Epics) – These Stories are future context based. They mostly help the team to understand where they “might be going” in their development efforts. High level sizing’s and ROI determination is a large part of the work here. Using a 4-R’s approach, these are mostly RAW to slightly REFINED.

I sometimes refer to grooming as a “conveyer belt” moving User Stories close and closer to execution. The concept of Definition-of-Readiness nicely complements this analogy and strategy.

Wrapping Up

I often use the term guardrails as a synonym for DoD. These are constraints that are defined for the team to help “keep them on the road” to agile maturity and delivery. I would liken the Defintion-of-Readiness (DoR) or readiness criteria as another guardrail for the team. These are not typically part of the “Core Scrum” definition. However, like User Stories and Backlog Grooming, they are incredibly useful practices for many teams.

If you go back to the introduction, those struggling teams have lost sight of how to properly pre-define their work. Establishing a Definition-of-Ready for a while should help them improve. Once that becomes a part of their culture and DNA, then it may not even be worth definition going forward, as it’s served its purpose.

Stay agile my friends,

Bob.

References

• Tony Shawver’s  blog post –
• Roman Pichler’s blog post –
• Agile Alliance definition –

A few additional links to Definition of Ready information: