Agile product backlog grooming is a development team and product manager/owner activity that removes the necessity of massive up-front planning. Backlog grooming is also a key risk reduction activity for an Agile project. The risks reduced or eliminated can include feature dependencies, costs, schedule, building the wrong product, knowledge, feasibility, and capability.
With Waterfall projects, there’s a great deal of up-front analysis of requirements and locking down scope from which cost and schedule are derived. There’s no need to ‘groom’ these requirements throughout the project because they’re not meant to change. Product backlog grooming is a frequently occurring process in Agile projects for the simple reason that Agile projects do not do full up-front requirements analysis. With Agile, the assumption is we focus on the value delivered to the customer and anticipate the customer changing requirements as their business world changes and evolves. Agile caters to the dynamic customer and business while Waterfall works really well for customers whose world changes very slowly if at all during the lifetime of a project.
In anticipation that some of the up-front analysis of requirements will be wrong, the Waterfall project manager puts in a great deal of effort to define and manage the risks associated with locking down scope so early, often times before people in the project know what they’re getting themselves into. This is a good thing because no one can know everything up-front.
With Agile, there is no pretense that we know everything. In fact, the Agile project team goes into the project knowing that they know very little of the details. For example, a typical Agile project might know enough to plan for the next 2-3 sprints (6-weeks if doing two-week sprints). Scrum defines an activity call ‘Product Backlog Refinement’, grooming by any other name, which is an ongoing process conducted by the Scrum team to add details, review, refine, estimate, and order the user stories in the backlog. While the Waterfall project has a risk registry and an ongoing risk management plan, Scrum involves the Scrum team in backlog grooming as a key risk reduction activity. These risks include:
- feature dependencies – Scrum teams will try to make stories independent but this is a goal, not the reality. Implementation dependencies will exist at times and through the efforts of backlog grooming, these dependencies are identified. Once identified, the development team and product manager can order the backlog taking these dependencies into account
costs – grooming can reduce wasteful work being prioritized too high. The scrum team combs through the backlog looking to keep those stories customers are willing to pay the most for near the top. Grooming keeps those stories that make achieving business goals and customer goals at the top while placing stories about, lets say, place settings on the titanic, at the bottom or removed entirely.
- schedule – most projects work to some schedule and grooming helps keep focus on those stories that will make your project a success. Schedules might be tied to sales cycles, business cycles, customer deadlines, or events. The goals for these scheduled dates are usually agreed to by the teams but based on the available knowledge when the commitment was made. Backlog grooming can help keep the biggest bang stories, those stories that provide the greatest contribution toward the goal, at the top even as more knowledge is gained.
- building the wrong product – backlog grooming asks if the stories in the backlog are what the customer needs so business goals can be achieved. As the project progress so does the likelihood that customer wants and needs change. Backlog grooming sessions check the staleness of information used to prioritize stories. If it’s been awhile since the team spoke with customers or customers have been absent from sprint reviews, then an action from a grooming session could be to re-validate a customer problem or solution with customers.
- knowledge – product backlogs usually have the structure where large stories sit near the bottom and progressively smaller stories populate the backlog until the top 2-3 sprints worth of stories are small, ‘sprint ready’ stories. The process of taking larger stories and breaking these down to sprint sized stories never ends and will transcend projects. The process of breaking down stories involves digging out more details. These details can reveal a knowledge gap exists that needs to be closed before a story can be worked. Unless the story came up from the depths unexpectedly, there will always be time to recognize the knowledge gaps and find the knowledge either through training or getting a temp specialist.
- feasibility – like the knowledge risk, feasibility can be handled before actual time to implement the story. When following a routine groom paradigm where large stories are broken down over time, it will be easier for the development team to provide earlier analysis of feasibility. The first analysis of feasibility would normally occur during the ideation phase, when a feature is added to the road map. However, the difference between “we should be able to do this” and “we know we can do this” can potentially put a company out of business.
- capability – this ties in closely with the knowledge risk but is broader than team skills and capabilities. This includes things like test environment, development environment, build environment, customer access, and stakeholder involvement. Again, as larger stories are broken down during grooming, the team assesses the these needs to make implementation and delivery of the story successful.
Things that impede grooming sessions
Development team doesn’t feel responsible for the user stories.
“writing and rewriting user stories ain’t my job.”
I think this will be the impediment most often seen slowing down grooming sessions. I found that once development got used to their traditional roles, it was hard to get the developers on board with writing and rewriting user stories. Although the product owner remains accountable for the order of the backlog, they are not necessarily solely responsible for the stories.
All I can advise is setting the expectation that as members of the Scrum team, they all equally share the responsibility for the product backlog and its contents. This is best if re-enforced by management. The other factor will be time, it may take several months for the full team to accept this new responsibility. The Scrum Master can use the retrospectives as a vehicle for improving the grooming sessions. For example, can the bigger stories be broken down by anyone else other than the product manager? Someone in the team will suggest they can help the product manager. This is a very positive step forward. A note of caution: developers might try writing user stories that are very technical in nature.
Product manager not giving up control of user stories
I found that this will happen but goes away rather quickly as it’s the development team that needs good stories so they can attain a good understanding of the work required. This follows these three steps:
- Product manager controlling all aspects of user story writing
- Development team is in a struggle with the product manager over meaning and acceptance of user stories
- Product manager makes a business decision to allow the development team in on writing stories and reducing the amount of time explaining what the stories mean.
Backlog grooming sessions not a team event
How much fun is backlog grooming for your Scrum team? Are you part of a team or scrum master of a team that goes to grooming only to agree with whatever the senior developer or team lead says? “Does everyone agree?” “Yes.” [Audible ‘TICK’] Maybe is was better when we did waterfall!?
It’s important that the first backlog grooming sessions be well facilitated so the team can be drawn in to the backlog and backlog grooming process. Going around and asking each individual what their opinion is, to explain their understanding of the story, and to describe what the high level design is will help. Some people will take to this quickly while others will take several grooming sessions to draw them out. Don’t give up but continue the facilitation until participation becomes natural for the team.
I’ve also seen where having the team lead or team manager as part of the team can stifle participation at grooming sessions. Providing coaching to the manager to encourage a ‘servant leadership’ approach is of inestimable value to creating a self-organizing team. This has worked great in the past and was the subject of a talk I gave at Scrum Australia 2016.