A Wishlist of Ready!
Many Agile and Scrum teams have adopted the practice of having a “Definition of Ready” as a way to explicitly define when a Story – or Backlog Item – is “Ready” for a team to take into a Sprint. This often serves as an entrance gate for Stories and ideas to be proposed for Sprint Planning. Some view this as a best practice but far more often this is an anti-pattern that often time creates the same impediments to a team’s agility that the organization was hoping to eliminate by adopting Agile or Scrum in the first place. It is important to note that the “Definition of Ready” – or DoR – is technically not a part of Scrum. The Scrum Guide – which was created and is maintained by the founders of Scrum – makes no mention of the DoR.
Typically, a team’s DoR will contain a list of criteria that a story has to meet before being eligible to be proposed by the Product Owner for Sprint Planning. Some typical criteria might include (examples, not an exhaustive list):
- A story needs to be estimated
- Dependencies must be resolved
- UI Wireframes have been created
- A UI mockup has been created
- All acceptance criteria have been documented
- Test scenarios have been defined
- A user workflow has been diagramed
Having these criteria are helpful, but they become a rigid list of entrance criteria for a sprint, they serve as a barrier to entry for new ideas. This will often result in a number of unintended consequences:
Idea Lag
The promise of agility included the ability to rapidly respond to feedback and learning. For scrum teams one opportunity for short-term feedback is the end-of-sprint Review. This is often the first opportunity for stakeholders outside of the Scrum team to see firsthand what the team has created; and an opportunity for the team and its Product Owner to get feedback and ideas from outside the team. The hope is that we will learn or discover new opportunities that are even more valuable than the ones already identified in the Product Backlog. If we get feedback, or identify an idea that is really important, we should be able to incorporate it into the team’s next sprint – which begins shortly after the review. This is at the heart of the ‘act-inspect-adapt’ cycle. However, the DoR often renders this impossible. If an idea has to meet the DoR before a team can work on it, there simply isn’t time between the Review and Sprint Planning to do all the pre-work necessary to make it ‘ready’. This means that the new idea cannot be worked on in the next sprint – it will have to wait at least the length of the Sprint.
Higher Risk, Uncertain Ideas are Deferred
Each sprint a Product Owner faces the additional burden of making sure that backlog items are ‘ready’ for the team’s next sprint. This is on top of an already full plate or collaborating and supporting the team’s current sprint work as well engaging and conferring with stakeholders as part of maintaining and managing the backlog. This creates pressure to get stories ‘ready’. Generally, the more complex, uncertain or risky a story is, the more difficult it is to make ready. The more familiarity we have with a story, the easier it is to make ready. Since Product Owners run the risk of not having stories ‘ready’ in time for the next sprint, it is natural for them to gravitate towards stories that easier and faster to make ‘ready’. This results in teams often working on the most ‘ready-able’ items, and not necessarily the most valuable items. This also means that stories that have a high degree of uncertainty, unfamiliarity and risk, will end up being deferred to later sprints. Deferring high-value, high-risk items is a poor product strategy resulting in increased risk over time.
Requirements and Analysis become Pre-work
The Definition of Ready for most teams is intended to ensure that we know ‘what needs to be implemented’ so that in Sprint Planning teams can focus on ‘how to implement it’. This means that the solution is pre-determined prior to Sprint Planning – essentially the requirements have been determined prior to the sprint. A far better approach would be to have the team collaborate to explore different options of tackling a user or customer problem (or opportunity) that might be feasibly within the current sprint. The analysis and discovery is now part of the story implementation – not something that is completed prior. This also will allow the team to transform from a ‘Feature Factory’ to a team of ‘Problem Solvers’ and ‘Opportunity Enablers’.
A small shift in the way that a team uses a ‘Definition of Ready’ may significantly improve both their Agility and Delivery – is instead to tread the DoR as a ‘Wishlist of Read’ – or WoR. Instead of criteria of ‘must haves’, the WoR represents criteria of Nice-to-Haves.
- It would be nice to have a story estimated before sprint planning, but we could work on it even if it isn’t.
- It would be nice to have dependencies identified before we start, but in Sprint Planning we have the right people in the room to deal with these so why not get started right there in sprint planning anyway.
- It would be nice to have a user workflows and user diagrams before we start planning, but if we didn’t, we could still figure those things out during the sprint.
- It would be nice to have all Acceptance Criteria documented, but it is far more important that these be understood the team. What better time to discuss these than in Sprint Planning when the entire team is present, the Story has been identified valuable enough to have the team work on it?
This idea of a ‘Wishlist-of-Ready’ rather than a strict ‘Definition of Ready’ minimizes the amount of pre-work and pre-effort that goes into the story and also maximizes the benefits of having your team collaborate to understand the story and optimize the solution.
Give it a try for your next sprint planning, and see how it makes a difference to communication and agility!
If you’re enjoying these Agile QuickTips by Giora Morein, make sure you never miss a valuable one by subscribing to our YouTube Channel. You can also follow me on Instagram or on Twitter, @GioraMorein
