Agile Mondays: Grooming The Backlog, And Combing The Desert

What is Backlog Grooming? In the past few years the adoption of a dedicated Product Owner has become fairly common, and Agile/Scrum/Whatever methodologies abound, but this sort of vague concept of GROOMING THE BACKLOG keeps coming up. So what is grooming the backlog? How does it apply? I’m here to offer my perspective as a Product Owner and how I’ve implemented it thus far at a few organizations.

What is Backlog Grooming?

Technically grooming the backlog is something that happens ALL the time, and that is not a bad way of putting it. An active Product Owner is continuously going over the Product Backlog and adjusting priorities as well as adding or removing detail from User Stories to either get them to meet the Definition Of Ready, or to determine if it is a good idea or not.  This is all fine and well, but practice tells us that the being a Product Owner is a shared role and you should involve your team in that role ultimately. However, how does Backlog Grooming apply to teams and begin to escape just this neat little person called Product Owner?

Backlog Grooming with Small Teams

If you are a Product Owner working with say one Agile/Scrum team sized three to nine people in total, it’s likely a good idea to get together with your team at the very least once a Sprint and do a few things:

  • Adjust priorities based on team input
  • Refine acceptance tests or add additional tests to stories
  • Ask your team WHAT they need to know in order for a story to meet the team’s version of the Definition Of Ready
  • Elicit estimates by the team that may help you either adjust priorities or help break a story down into smaller chunks that meet INVEST┬ástory criteria

 

Practice has told me that spending approximately an hour doing this with a team doing weekly Sprints has paid off. In the case of two week Sprints, spend a little bit more time, maybe two hours. Obviously the amount of time spent doing backlog grooming is going to vary from team to team, but this is what I have found works to date. Once you have the team together you can ask them a great deal of questions that help meet the criteria above such as:

  • What would it take to get this story to a point where it is less vague?
  • Can you help me think of additional acceptance tests that will make this story higher quality?
  • What am I forgetting in terms of performance tests or additional tests that may not be functional in nature?
  • What do you feel the effort is on this story? Is there a way I could slice it to be smaller and still deliver value?

 

Being you have a smaller team with you, it is likely that your team will be easier to keep engaged and continuously offer input instead of feeling like the topic isn’t relevant to them. What I do is type or write on the fly, adding acceptance tests, new stories, or notes for what I need to follow up on to help the team move forward with a story.

How Do I Backlog Groom With More Than One Team?

Say you have multiple teams working on the same Product or Platform, how do you address that? This is my current situation, and I’m always cognizant of people’s time and not wasting any of it. What I believe is the best solution to this problem is to invite smaller portions of each team to your Backlog Grooming to help you identify the same answers to the common questions above. What I am thinking is the best mix is to ask the teams in the Sprints to identify who the best members are to attend Backlog Grooming! I can give you the following advice:

  • Make sure not to just invite tech leads! Bring in who is best for the Grooming, the tech leads may have a more senior perspective but this can drown out young and interesting voices
  • When you invite people from each team, make sure to invite one of each distinct role to Grooming such that you get for example a Tester, a Developer, and maybe a DBA if the team needs it. You want a representative of each distinct skill set from a team to help you figure out what will help a story become Ready, agnostic of which team it ends up with.

Combing The Desert

This was my way of making a Spaceballs joke in an Agile Monday post, but what I’m talking about with combing the desert ties in very well with my running theme in this blog of addressing Technical Debt (Did you know I write about it?). Technical Debt can sometimes feel like the desert because like the amount of sand in a desert, you may encounter a large variety of Technical Debt with no clear direction on how to address it or even to comb through it. You should ask the team in Backlog Grooming if there are any items that behind the scenes should be addressed, try and capture them as stories and ask them to help you prioritize them. As part of defining a User Story is ready, perhaps there is another technical item that if addressed would make the current User Story much easier to implement. This could help you prioritize some technical debt which will help the team understand you are invested in helping not just your stakeholders but the team as well, and as well help you implement new features in a much more efficient manner. You of course can also elicit ideas for addressing Technical Debt in the Retrospective meeting, or really any time!

What Do I Do If They Can’t Find Stuff?

Another Spaceballs pun, but if you’ve combed the desert with the Development Team and they can’t find Technical Debt try asking the following questions:

  • On a daily basis, what is one thing that you feel takes WAY too long to do?
  • What is the piece of technology that is hardest for you all to work with?
  • Are there any bottlenecks to the daily development process that you feel we could improve?

 

Continue to challenge the team as there is likely ALWAYS something that can be improved in your Product’s code. You as the Product Owner will need to ultimately weigh on if it will return the highest value to users/purchasers, but it is very important to chase these items out.

And here we have my initial thoughts! Hit me with some feedback to how you have been Backlog Grooming with a team or as teams as I would love to hear it! I’ll follow up this post next week with what I’ve found to be a good framework for a Backlog Grooming meeting with Agile/Scrum teams and try and build on the theme of Grooming the Product Backlog in general.

Leave a Reply

*

captcha *