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!
During the day we asked everyone to answer 5 questions:
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!
According to the participants, possible small improvements to the Scrum framework are:
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:
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.
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?
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?