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.

We’ll finish this post in part #2 next…

Stay agile my friends,

Bob.