Why isn't the Definition of Ready described in the Scrum Guide?
Barry Overeem
Co-founder The Liberators & Columinity: a product to help teams improve based on scientific insights. ??
On July 7th the Scrum community gathered in Amsterdam (The Netherlands) for the 5th edition of Scrum Day Europe. This years theme was 'the next iteration'. Therefore we looked back to see what Scrum brought us the last 20 years, but also looked forward into the future of Scrum. Naturally, the evaluation was done via a retrospective. The goal was to generate insights and define improvements for the Scrum framework from the Scrum community. Every participant contributed and provided input; thereby it proved to be a true community event!
The 5 Retrospective Questions
During the day we asked everyone to answer 5 questions:
- What has proven to be the strength of Scrum the past 20 years?
- What should be the focus of Scrum the upcoming 20 years?
- What of Scrum frustrated you the most so far?
- What connects you to Scrum?
- What is a small improvement that could be added to Scrum?
In a series of blog posts I'll share the answers we've received on these questions. This final blog post will be about what the participants of Scrum Day Europe considered a small improvement to the Scrum Framework. I'll share the outcome of the Retrospective and my personal opinion. Of course I'm also interested in your point of view!
The Suggested Small Improvements
According to the participants, possible small improvements to the Scrum framework are:
- Adding the Definition of Ready to the Scrum Guide
- Adding an appendix to Scrum Guide with “what to do when…"
- Providing a Scrum starterskit for new colleagues
- Creating an EBM presentation for management/organization
- Offering practices to improve soft skills
- Creating an experiment canvas > hypothesis driven
- Introducing a strategy clock
- Humanizing the workplace
- Setting up a Definition of Fun
- Creating official profiles of all the roles based on ICT competency standards
The Definition of Ready
Out of all the suggestions made by the participants I would like to focus on the suggestion of adding the Definition of Ready to the Scrum Guide. It's a question I get during every Professional Scrum Training:
"Why isn't the Definition of Ready described in the Scrum Guide?"
First, let's clarify what is meant with the Definition of Ready. While the Definition of Done is used to assess when work is complete on the product Increment, the Definition of Ready is used to assess if Product Backlog Items (PBI's) are "ready for Sprint". Often the acronym "INVEST" is used as a checklist. PBI's are ready for Sprint when they are independent, negotiable, valuable, estimable, small and testable. Although such a checklist can be a useful instrument to improve the quality of PBI's, I'm not a big fan of the Definition of Ready. Quite often it becomes a contract - instead of a guideline - between the Development Team and the Product Owner. Only PBI's that meet the entire checklist will be selected for the Sprint Backlog. Basically the Development Team is using a sequential, phase-gate mindset which only increases unnecessary process overhead.
Luckily the Scrum Guide offers a great alternative for the Definition of Ready: backlog refinement. Backlog refinement is the act of adding detail, estimates and order to items in the Product Backlog. Scrum uses backlog refinement as an activity to improve and clarify the Product Backlog. Backlog refinement is an ongoing process, therefore it's not restricted to an event but considered an activity.
As a rough guideline, the Development Team spends 10% of their capacity on backlog refinement. A good practice is to have at least two sprints of PBI's ready for Sprint (clear, feasible, testable). To use Pacman as an example: when Pacman can’t ‘eat’ enough PBI’s anymore because they aren’t small enough, backlog refinement is necessary. Just enough, just in time. Everything with the goal to feed Pacman delicious 'ready' PBI's.
Instead of using the Definition of Ready as a sequential, phase-gate checklist I prefer the activity of Backlog Refinement. Frequent refinement of the backlog creates a flow of Product Backlog Item readiness. Although it might seem a contradiction; I do support using a checklist that clarifies 'readiness' during backlog refinement. Mainly because during refinement such a checklist isn't used with a phase-gate mindset but purely to improve the quality of the Product Backlog. It's a small but important difference.
So why isn't the Definition of Ready described in the Scrum Guide? Because it is. However not as a checklist but as an activity: backlog refinement.
Closing
This is the 4th blog post about the Scrum Day Europe 2016 Retrospective. In the first blog post I've described the strength of Scrum. The second blog post was about the desired focus of Scrum. The third blog post described the frustrations people experienced with Scrum so far. The fourth blog post offered examples of what it is that connects people to Scrum. This final blog post contains my view the Definition of Ready as a possible improvement to the Scrum framework.
What is your experience with using a Definition of Ready? Do you think it should be explicitly described in the Scrum Guide?
For a new team, this can be a good tool to govern their effort to plan effectively and build muscle memory.
Great post! I don't remember where 'definition of ready' came from, but I find teams that are new to Scrum like using it quite a bit. One team I'm working with now is on the dangerous line of using as a weapon, but the intent is to be more deliberate about being more thorough than 'just start building...'
Thought Provoker / Founder @VXS
8 年The DoR is required when teams are not sufficiently mature to minimize lead time below the duration of 1 Sprint. In fact, a DoR results in splitting work into 2 portions: "Done before Sprint X", "Done in Sprint X", resulting in huge amounts of batched WIP. DoR is required for "Shu" level teams, not for "Ri" level teams. On the other hand, Scrum is actually a "Ri" level framework, meaning it's full value is not realized until teams *are* sufficiently mature that they can actually minimize lead time. So, I would also agree with Gunther Verheyen. It's not a core rule and shouldn't be.
Agile Coach at ANZ Bangalore
8 年I always feel DOR is important to have, It will be formed by utilizing learning of team sprint by sprint, It need not to be a big list, even one or two pint like you said ( clarity, feasible and testable), It will act as a check point to see where Scrum master or Product owner need to concentrate more. Agree with Gunther Verheyen, Depends on Team to team, App to App, need not be a part of Scrum Guide
Agile & Business Strategist : Transformation Catalyst
8 年It is a concept and not practice that depends on team discipline and can be easily abused by the team