What the Hell Is a “Groomed Backlog”?
After a day-long sprint planning session, another exhausting sprint ensued. By the time this mini-death march completed, we were “rewarded” with another day-long sprint planning session. By the third sprint, the product owner got mad because we missed our sprint goals again, so the team asked for a week between each sprint for “prep” (and recovery). Grumbling turns into demands that the product owner produce a “groomed backlog.”
Does this feel like life on your team? Read on.
When things get to this point, the team has two choices:
1. Recognize that everyone is reverting to form (and that’s usually the familiar “waterfall”). Stop working together, and start becoming document and driven by sign-offs.
2. Embrace the shared responsibility for grooming, and understand that the definition of “well-groomed for a product backlog is based on the context of the team and the project, and thus is harder to define. The entire team has work to do to face and resolve this impediment.
What is Grooming?
For a product backlog, Scrum provides three considerations that pertain to “grooming”:
- Items in a backlog are “ready” when they are understandable by both the product owner and the team.
- The team should spend five or ten percent of the its capacity in each sprint working with the product owner to get the backlog ready for the next Sprint.
- The team works on the highest-priority product backlog items and elaborates them just in time.
When you add the three, you get really valuable grooming! So, the team should meet about two days before end of sprint and get grooming:
- The product owner brings about one-and-a-half times the number of stories, that, based on the team’s velocity, are likely to fit into the sprint. Those stories come, of course, from the top of the stack-ranked product backlog,
- The team does the following, in the order that makes sense for the team and repeat when necessary; don’t fear this healthy, emergent behavior:
- Agree on the acceptance criteria for the story
- Estimate the story
- Split the story, if necessary
- Re-prioritize the story (or stories, if you split the story) against others in the backlog
What value does the team realize from their investment of time and effort?
- The team gets to “sleep on” their estimates before they’re used in a sprint planning meeting.
- If a critical piece of information is identified as missing as you grooming, the team has a bit of time to get it, or to bump the affected items to another sprint.
- Sprint planning meetings will be at least half as long.
- Sprints will be less chaotic.
- The team will hit its sprint goals more often.
This is the best use of time a product owner and a team together can invest towards successful sprints.
Tags: Agile, planning, product owner
February 6th, 2009 at 7:24 pm
Recent projects I’ve been a member of have found it too risky to wait until near the end of the sprint to groom the backlog. Also, as work is being wrapped up for the sprint it risks taking devs away from the delivery of that sprint’s commitments.
As such, we’ve found it works best to spread out grooming. Typically, with a two-week sprint starting on Monday and ending the following Friday the best time to groom without interfering with sprint start and end is Tuesday and Thursday. Hence, we groom for an hour each Tuesday and Thursday. Occasionally we’ll schedule an additional session or two, but typically 4 one-hour sessions (along with the planning session) have been sufficient to prepare enough stories for a two week sprint.
February 13th, 2009 at 11:38 pm
Good comments, Jeff. Proof that no two teams are really alike. What I like is that you are about preparing for the next Sprint so it isn’t a surprise at Sprint Planning!
March 4th, 2009 at 3:36 pm
On a past well functioning team I had the pleasure to be a part of, we also groomed the backlog at several meeting through out the current sprint. It worked very well although not without the team being committed to doing the work!
We had 4 squads (sub-teams) one backlog and an excellent Product Owner who made decisions on the spot when required, and also give the grooming sessions plenty of her attention.
We did however arrive at some tips that may help others in the grooming sessions.
We found that too many people in one session was more than 5 active participants in the conversations (sometimes more people were in the room – but typically more as observers, rarely involved in the debates).
We found the PO frustrated by the development team rotating people in the sessions. The lack of continuity was the cause of frustration, as we would often go back to past stories and a new dev. member of the group would not have the context for the discussion. We resolved this by rotating on the sprint boundaries rather than the meeting boundaries. The desire to rotate which developer attended the grooming session was a team desire, the PO wanted the same people each session. The team felt that exposure to the backlog was a team responsibility that had to be shared, not shouldered by a few select members.
Our Business Analysis were frustrated by the constant writing and rewriting of stories and splitting and combining of stories. There was a good bit of churn, and as everyone has a belly-button, everyone has an opinion of how to split a story! But they soon learned that just the minimal information was required and that it took viewing the stories in different context and that this was not requirement gathering – but indeed product design that was happening right before their eyes, and they played a part of it!
We rarely got a story right! That is at the grooming session. We allowed that the story would be better understood at the planning game, and even better after work had progressed for a day or so. Therefore the BAs took on the responsibility for documenting the negotiations in the story for the acceptance criteria that the PO and Team made on an ongoing basis. This is important – no one can remember after a month why the story was acceptable with such-and-such a limitation, but the story if updated with the negotiated criteria can act as a “as-is” documentation – remember to record these or you will have a brewing misunderstanding on you hands.
March 4th, 2009 at 3:47 pm
Oh – I also want to add that we found the most pride in workmanship in the stories that we involved the end-users (or a representative) in the planning and in reviewing the stories as it was being built. Which allowed for small and medium size changes in the story as the sprint progressed. These small changes were sometimes the biggest wins at the demo! As the end-uses got something that wasn’t “planned” and was discovered on the route to the incrementally designed feature. Sometimes it was a small feature that would be removed in a future sprint when the “finished” feature was again being worked upon. But it provided value in the intermediate phase that the end-uses really liked. WOW does that build good will and trust! And allows the end-user to see how iterative/incremental development can benefit them.