Product Backlog Hygiene: Prepare to Be Groomed

How do you start with a product backlog when you’re transitioning to agile? In this article, Darin Kalashian shows us how a cross-functional team at the product owner level creates a product backlog.

When a product development team begins to use the Scrum framework, one of the first objectives is to form a product backlog for the Scrum team to work off. The product backlog is the product owner’s responsibility to oversee, though the product owner seldom has all the knowledge needed to define a high-value solution that will be successful in the marketplace. To create a useful backlog, the product owner must rely on supporting roles, such as system architects, management, and subject matter experts.

The Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum, lightly touches on how to groom the product backlog. As an experiment, our development team complemented The Scrum Guide with some additional events and artifacts to help ensure product grooming was performed to a level where sprint teams could go to the next step, sprint planning. Additionally, by inserting a definition of done for the grooming of product backlog items, we made it easier for the team to manage the quality. This article defines the high-level workflow used to streamline our execution of product backlog grooming.

Where to Start?
Just like every other team out there that has had to get ready for its first Scrum project kickoff, we did all the preparation—reading through The Scrum Guide, enrolling in formal Scrum training to better understand the fundamentals, and assigning the roles of product owner and ScrumMaster. We huddled back in the office, all literature’d up. We even organized a Sprint 0 to get everything set up and ready for kickoff. We thought we had a handle on it ... until we sat down with our product owner, sprint team, ScrumMaster, and various stakeholders and tried to make a plan out of our product backlog. We quickly realized that grooming our identified product backlog items wasn’t as easy as we first thought.

In our environment the application is very complex, with multiple vendors, subsystems, and customer needs, not to mention our own roadmap and business objectives. It was unrealistic for the product owner to know it all. For the product owner to understand the business value of a customer request, we needed to pull in a larger, cross-functional team of system architects, business leaders, and others not typically part of a “traditional” grooming session. However, we agreed that having a grooming session with all of these roles present in addition to our development team would not be particularly productive.

As the coach of this Scrum team, I suggested that all of our stakeholders should huddle up and brainstorm some ideas on how to make product backlog grooming more effective. This collective team decided to experiment with breaking the product grooming activity into two separate, supporting activities. We termed these activities “product backlog planning” and “product backlog grooming session,” as depicted in figure 1. While we did not want to squelch the team’s emphasis on collaboration, we needed to make sure each contributor maximized his or her value and use of time.

Fig 1

Figure 1. Product Grooming

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!