We left the last post sharing some of Roman Pichler’s thoughts around readiness. Let’s continue…

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: