Product Backlog Hygiene: Prepare to Be Groomed


Product Backlog Planning
Everyone agreed the product backlog was not ready to be groomed by the Scrum team. There were too many unknowns. The Scrum team wanted backlog items they could process and proceed with for implementation. As it stood, the product backlog identified many items that, as the measuring stick would tell, were of epic size. The product owner was given the task to meet with knowledgeable system architects, business leaders, and technical managers in an attempt to flush out the customer needs and capture as many story points as possible to convey the functionality. This became the goal of the product backlog planning sessions. In these sessions, the product owner—along with the system architects and leaders—defined feasibility, required high-level functionality, and product roadmaps that would support implementation. In the spirit of Scrum, a definition of done was established to identify when a product backlog item had completed planning and was ready for the development team to size and consider for a sprint.

The definition of done identified these acceptance criteria:

  • Planned backlog items: Backlog items needed to be broken down into stories that were understandable to the development team. Epics were clearly identified and tracked. But as always, epics weren’t ready for grooming until there were supporting story points.
  • Rough order magnitude of size: While the development team would provide an estimate of the story point later, the planning team was asked to identify a T-shirt size estimate for each backlog item. While it had no direct value for story point estimation, it did help justify the business value logic.
  • Business value: We found it useful to carry a business value index separate from the backlog item priority rank index. The business value was the justification, or backup data, to support the backlog rank order. Our product owner had an in-depth formula to calculate each item’s business value.
  • Priority (or rank order): Each item had to have a unique place on the product backlog.
  • Product version: Each item had to have a suggested place where it fit into the over-arching product roadmap. Defining the roadmap was more of a senior management activity, so this activity served us by aligning the product backlog items with the product roadmap.

Product Backlog Grooming
Armed with a product backlog including backlog items that had completed product backlog planning, the product owner and development team once again engaged to conduct another grooming session. The results this time were a lot more positive and productive. The goal of the product backlog grooming session, as we defined it, was to empower the development team with enough details so they could focus on execution and implementation.

The product backlog planning session had empowered the product owner to participate in meaningful discussions during the grooming sessions. By The Scrum Guide, the development team worked to refine the backlog list further and took care of providing story point estimates and selecting which items would go in which sprint. For each backlog item, the development team and product owner agreed on its acceptance criteria, estimates, and the refinement and agreement of its rank, business value, and product placement. As always, any attribute of a backlog item could be questioned, and it was the product owner’s responsibility to address those concerns.

Grade “A” Marks
Our experiment was a success. The development team was empowered and felt confident moving backlog items into sprints to move the product forward. The product owner felt empowered to drive the product backlog forward. The product owner had gained insight and support from the planning team and brought this knowledge to the development team for implementation. Because everything was stored in the product backlog, everything was transparent for all parties to see and process. The team agreed to continue to groom backlog items in this manner, and future grooming sessions proceeded smoothly.

In doing a retrospective of our experiment, we realized that we had actually implemented the very principles of hoshin kanri, a Japanese strategic planning process designed to ensure that the mission, goals, and objectives are communicated throughout an organization and implemented by everyone. The Scrum team had established a common goal, the product backlog, for all of us to focus on while involving the cross-functional team of system architects and business managers, who could align their support for the development team and product owner. We accomplished all of this while making sure we maximized our time and resources.

Who knew good product backlog hygiene could be so rewarding?

User Comments

Bob Galen's picture

Hi Darin,

Nice article. I appreciate your sharing it. Two comments or sort of concerns:

First, there's lots of language around maximizing everyone's time around their skills and not wasting their time. Doesn't this open the door to silo thinking and behavior within each of these "grooming teams" and across teams?

For example, I could see potentially "wasting" the time of an architect IF their involvement with the implementation team created a more robust product feature that delighted the customer with its value.

The second concern is are you leaving x-team collaboration insights on the table? Again, I wonder if the implemntation team would gain some interesting experience and skill be "being a part of" the initial backlog planning?

While I can see your need for the 2-phased meeting approach, I would personallyh work really hard to make the "team" grooming happen as much possible. And I'd want their to be some "discovery" going on in there.

Just a nuance or balance that I'm sure you're striking. Again, thanks for sharing with the community!

Bob Galen

September 20, 2013 - 7:54am
vidas vasiliauskas's picture

First of all, great article. I want to share our pratice of product backlog hygiene: we divide work into tasks by category (features, requests, bugs, support, expedite). Each has their own process steps and some of them tend to be overcrowded like requests or features. We prioretize after new items added those categories and each time we drop 20% of lowest priority tasks. It gives us focus only on what is most importnat. Yet it is sad, that this is good only for product development. 

October 7, 2013 - 3:54am
Madhava Verma Dantuluri's picture

Excellent share and i really liked your idea of breaking the backlog into grooming category. This makes lot of sense and would like try in my project.

February 26, 2014 - 6:45am

About the author

Darin Kalashian's picture Darin Kalashian

Darin Kalashian has over 20+ years of software development experience, with key accomplishments at the organization and individual levels (and everywhere in between). Having worked in some exciting spaces that include: development of high-tech air traffic control and weather detection systems; the first commercial web browser; audio modeling and simulation tools; Darin has developed a solid understanding of how to use software methods, tools, and techniques to deliver successful and effective software products.

Darin is a Certified Scrum Master and enjoys coaching teams as they embrace agile/iterative development. Relying on his past experiences, Darin helps teams set their sights on “win-win” scenarios, where they pro-actively developing high quality software in a timeframe that achieves high customer satisfaction while supporting the larger organizational mission. Complementing his agile practices, Darin has recently been certified as a Six Sigma Green Belt, where he now focuses on integrating Six Sigma/Lean analysis to drive focus for improvements.

Please feel free to reach out to Darin at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!