The purpose of backlog grooming is to keep the product backlog up to date and clean. Scrum doesn’t prescribe how you should do backlog grooming, and different approaches are used by product owners and teams to do this.
Jeff Patton describes an experience that he had with a team that was doing backlog grooming, in the blog post backlog grooming bugs me. Every week the whole team met and went through all the user stories in the backlog, to discuss them in detail. The product owner answered questions, and the scrum master captured the acceptance criteria from the team members. This was a long meeting, and the team members weren’t happy and felt that they were wasting their time. This meeting, as Jeff concluded, isn’t an effective way to keep the backlog cleaned up:
(...) the meeting I keep seeing that’s called a “backlog grooming” doesn’t make sense. In fact, any Product Owner who participates routinely in this meeting knows the one thing they can’t do in the backlog grooming meeting is tidy up the backlog.
To understand how good product owners fill in their role, Jeff started interviewing them:
When I asked successful Product Owners what they did to feel ready for the upcoming sprint, almost all of them described lots of frequent conversation and collaboration with team members to talk through upcoming work before the Sprint. Many of them described learning the hard way that on their own they could never come up with the right information to support a story. They needed the discussion with team members to help them work through the details and to understand what options were feasible and what details were necessary to help team members proceed.
As an alternative solution to keep the product backlog groomed, Jeff suggest to use a team for product ownership. He calls them a discovery team:
A balanced discovery team includes someone who understand the business concerns that motivate building software, users and their concerns and how they’ll use the software, and someone who understands the engineering concerns and can help identify what’s feasible to build. It’s from this intersection of valuable, usable, and feasible that good products spring forth. A single Product Owner may lead the team, but it’s still a team.
He gives a example on how you can arrange to have regular story discussions, with the right people involved:
One of the better product Ownership groups I worked with holds Story Workshops at least once a week, sometimes twice. (...) The stories to be discussed in the next meting look a little like “daily specials” at a restaurant. Team members “opt-in.” They decide if they want to attend or not. (...) Discussions are animated and fun. Team members look forward to this opportunity to collaborate.
His sums up his advice on how to groom the product backlog:
Yes, keep the backlog groomed, but don’t make the whole team do it. Do a bit of it on your own, and lots of it with your closest collaborators – a balanced product discovery team.
Joel Spolsky compares a feature backlog with an inventory, in the blog post software inventory. He describes the problems that he sees with they way that a backlog is often used:
The trouble is that 90% of the things in the feature backlog will never get implemented, ever. So every minute you spent writing down, designing, thinking about, or discussing features that are never going to get implemented is just time wasted. When I hear about product teams that regularly have “backlog grooming” sessions, in which they carefully waste a tiny amount of time and mental energy every day or every week thinking about every single feature which will never be implemented, I want to poke my eyes out.
He advices to take a different approach:
Do not allow more than a month or two of work to get into the feature backlog list. Once the backlog is full, do not allow new items to be added unless you remove an item. Do not spend any time speccing, designing, or talking about backlog items: the backlog, in fact, should be seen as a list of things you are not allowed to talk about or work on.
In the blog post soul-sucking death marches from hell, Dan Mezick describes how you can “game your backlog-grooming meetings”. He suggest to have a daily 25 minute time boxed meeting which he calls a “Backlog Timeout” meeting. Attendance from the product owner and scrum master is mandatory, team members can opt-in. Some of his advices for this approach to backlog grooming are:
The goal of the meeting is to answer the question “what do we know about the backlog today that we do not know yesterday?”
PO adds the freshly-generated EXPLICIT KNOWLEDGE to the [product backlog] each day. The most recent [product backlog] changes are reviewed at the start all subsequent meetings.
At the end of the [new way of doing backlog grooming], be sure to follow through by conducting a formal retrospective that you promised
Dan describes his experience with this backlog timeout meeting:
The folks participating appreciate the clarity and brevity of the meeting, and the ability to opt-out. In typical (weak) agile agile implementations, there is a death march at the end of the Sprint and attendance at the Backlog Timeout wanes until the Sprint is over.
Anders Abel describes how you can use kanban for scrum backlog grooming:
When an item is first added to the backlog it is put in the new column. The product owner decides if it’s even worth to put any effort into investigating the request at all. If it is, then it’s moved on to the investigate column. That is the “work in progress” column for the product owner and business analyst. When they think that they are done, they move it over to “Requirements Done”. Once that column contains 10-20 items (we don’t have a hard limit) it’s time for a backlog grooming meeting where the developers look at the product backlog item. If the developers think that the product backlog items is clear enough to be able to work with, they move it to the final “Backlog” state. The development team also gives a time estimate at this point (we use hours and not story points).
He explains how the kanban approach helps him to keep the product backlog cleaned:
With an efficient development team thanks to the scrum practices it’s more important than ever to make sure that a backlog is produced that give the developers the information they need to be efficient. (…) If we spend so much time to improve the development process I think it should be natural to also look at the process that leads up to the development phase. Unfortunately I think it’s quite rare to a have a well defined workflow for getting items into the backlog. (…) It is evident just after only a few months that a proper product backlog management process with good tool support helps.
How do you groom your product backlog?