In my previous article, I give an overview of some of the interesting changes incorporated into the 2011 Scrum Guide. One of the most interesting changes in my view is the inclusion of Backlog Grooming as a required practice. In my Scrum coaching experiences, the one practice that seems to help beginner Scrum teams the most is backlog grooming. In some cases, the practice itself makes many PO related obstacles highly transparent, but transparency is what we want!
Backlog Grooming: The Red Headed Step-Practice.
I think that many beginner Scrum teams have trouble deciding on how best to transition to Scrum. They focus so much on the major practices (Product Backlog, Planning, Review, Retrospective), that they don’t realize that backlog grooming can ease some serious Sprint pain. This idea that the Sprint Planning Meeting is the first time we hear about all new backlog items is absolute nonsense, but that’s how the pre 2011 Scrum Guide read to a lot of people. Will there be late breaking backlog items that might be presented for the first time at the planning meeting? Yes, but it should be rare to very rare.
Third Time’s the charm…
I’ve found that most teams seem to have the highest productivity on implementing a backlog item when they’ve had a chance to discuss the item 3 times, with the 3rd time usually being the Sprint Planning Meeting for the Sprint in which it will be implemented. Each time a backlog item is discussed(with the whole Scrum team present), it is decomposed a little further and open questions and risks are identified. In between these three discussions, people should take action items to answer these questions and mitigate the risks. These action items are ones that often take days in duration to answer, for whatever reason (answers from stakeholders, technical deep thought and investigation, etc), but don’t take a lot of effort for each action item. Throwing all of these action items into a 2-4 week sprint means you’re putting these long duration tasks onto the critical path, and that’s just not productive.
My Coaching Style for New Teams
When I coach a team that is just beginning Scrum, I actually start with backlog grooming first. I usually pick a point on the horizon 2-3 weeks out and say: “Sprint 1 will start on date X, and between now and then, I want you to continue working how you have been working, except that we’ll have a few training sessions between now and Sprint 1 so that we can hit the ground running(or “Sprinting,” if you prefer). Much of the time in those training sessions is focused on good backlog grooming techniques (and usually User Stories and Story Testing). It all starts with requirements!
Experienced Scrum Teams are Not Immune
Other non beginner Scrum teams also never seem to get to the point where they do backlog grooming well. I think many Scrum teams plateau when it comes to implementing Scrum, and this is really unfortunate. As Jeff Sutherland suggests in the Enhanced Nokia Test (aka “The ScrumBut Test”), the huge productivity gains for Scrum teams are in the last mile of implementing Scrum. If a team never gets to that last mile, then the high productivity promised by Scrum is never achieved. If your team wants to get highly productive, then your team needs to get really good at backlog grooming.
In My Ideal World…
In my ideal world, a team will first see a backlog item at a high level in a Release or other high level planning meeting. They will then dive deep into the item during a backlog grooming session near the beginning of the Sprint before its most likely implementation, identifying requirement and technical risks, logic questions, and other things that get in the way of fully decomposing the item into acceptance (or story) tests. Then, the item might be lightly touched on outside the grooming when unknowns become known, or maybe again in a grooming session a few days before the next Sprint. Then, at the Sprint Planning meeting, there are only very minor unknowns about the item, and the team is well versed on what is trying to be accomplished by the item. Knowing what work will need to be done for the item means the team can better plan their work for the Sprint. They can front load risks, parallelize efforts (automating the acceptance tests is a good parallel effort), and visualize the critical path for this and other items.
Where to Find Out More
I’ve written a series of articles on Backlog Grooming. <shameless plug> I haven’t updated them for the 2011 Scrum Guide yet, but nothing much about the 2011 Scrum Guide changed the practice itself, so probably 97+% of the material is still applicable.
For my articles on Backlog Grooming, see:
- Why do Product Backlog Grooming?
- What does Product Backlog Grooming Look Like?
- Tips for Effective Backlog Grooming