On Being Ready
In an Agile team, be it Scrum or Kanban, we want to be Ready before we start work on any Backlog Items. Confirming that we are Ready helps us convey confidence to our Product Owner that the team will be able to achieve their goal. The team defines what it means to be Ready, shares that with their Product Owner for transparency, and leverages it with every Backlog Item.
So what does it mean to be Ready? It means the team knows enough about the work that they know they can complete within their committed timebox, and fairly certain they will not encounter any Blockers. To get to Ready the team will spend plenty of time refining the story with their Product Owner, clearing any dependencies, and verifying several other points they will outline in their Definition of Ready.
Defining Ready
When a team forms one of the first activities they will work through is defining Ready and Done. These definitions don’t have to be perfect, they just have to be good enough for the team to assess Readiness for their first batch of work. The team can base that Definition of Ready on some common aspects of readiness, as well as on their understanding and expectations for the type of work they will be doing. And as with everything in an Agile environment, the team will periodically look back at their work and consider changes to their Definition of Ready as part of a team Retrospective.
Before Refining
The Product Owner will source new features and capabilities from various stakeholders. Before bringing these work items to the team the Product Owner will do a Readiness assessment of their own. The Product Owner will focus on the most basic question, outlined in the first Agile Principle:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The Product Owner will first assess for the Value of the work. Once the value is understood the Product Owner will then determine where the work fits relative to the other work on the backlog, and determine the right timing to bring it in front of the rest of the team for refinement.
Work Specific
There are certain common aspects of readiness the team can start with, including clearly defined value, sufficiently detailed acceptance criteria, and that the work is sized to fit within the timebox. These are easy to identify, start with INVEST.
The team must also look for work specific considerations for their Definition of Ready. These might outline specific information the team will need to execute on the work, or specific dependencies that need to be considered such as UX or data modeling. The team may also find different types of work have slightly different considerations for Definition of Ready. It is a GOOD thing for the team to identify these considerations, and adapt their Definition of Ready.
Clearing Dependencies
Refinement of backlog items will often uncover dependencies. There are going to be other things that have to be in place before this work can be started or completed. It might be as simple and direct as a need to sequence certain stories within the team’s backlog. Or it might be more complex like having business dependency on regulatory or compliance approvals.
Whatever those dependencies are, the team needs to talk about how to clear those dependencies. Ideally they could decouple the dependency, and allow the work to proceed. This may not always be possible, in which case the team will need to explore how hard that dependency is, and whether it will prevent the work from starting or could at least be handled in parallel with the work.
No Really, Be Ready
We’ve defined Ready, confirmed Value, have clear Acceptance Criteria, sized the work, met our other aspects of Ready, and cleared our Dependencies. Are we Ready?
What about the team? Are they Ready? Do they have the right knowledge and experience, or do they need to do any research, knowledge transition, or proof-of-concept work? Is anyone taking a leave during the iteration? Are there any key subject matter experts or stakeholders who might be unavailable for review or any clarifications?
When the team agrees to take work into their iteration, they should consider any constraints outside of the work that might impact their ability to make progress on and complete the work.
Take Caution
All of this talk about being Ready could leave any team overly cautious and unable to feel like they could really be Ready. Watch out for this becoming a waterfall tollgate, which could slow down the flow of work and Value. Remember that often the best input we get can be the feedback from users actually using our software, which is much more valuable than spending extra time anguishing over Readiness. Keep an open mind about what it means to be Ready, and what is “Good Enough” to allow the work to continue, so we can keep that Value flowing.
Additional Reading
INVEST in Good Stories | Scrum.org Definition of Ready | Visual Paradigm on Definition of Ready | Mike Cohn on Dangers of Definition of Ready