A well-groomed product backlog facilitates the development of a successful product: It incorporates the team’s learning, and provides items that are ready to be implemented. But when should grooming take place? Before the new development work starts or at a later point in time? And how can you decide which option is appropriate for your product? Continue reading to find out the answer.
Option 1: Grooming Takes Place before New Development Starts
Your first option is to groom the product backlog before any new development work starts, as the picture below illustrates. This includes obtaining feedback from users and customers, analysing it, integrating the learning into the backlog, and getting the product backlog ready. (Please see my post “The Product Backlog Grooming Steps” for a more detailed discussion of the grooming activities.)
Grooming takes place before more development occurs
Choose this option if you require feedback from customers and users to decide if and how to take your product forward. Let’s say you develop a new product and you are trying to understand if the solution addresses the user needs selected. It would then be advisable to collect the relevant data, for instance, by demoing the latest product increment or releasing it to the users, to analyse the data, and to integrate your insights into the backlog before you continue developing the software.
Employing this option may mean stopping coding for a few days before the relevant data is obtained and analysed. But this can be preferable over rushing on, only to find out later that the direction taken is wrong, and all the hard work has to be undone.
Option 2: Grooming Takes Place after New Development has Started
Your second option is to continue the development work while you are collecting and analysing the user feedback. The grooming is hence delayed, as the image below shows.
Grooming takes place after more development has started
Choose this option if you do not require the user data to continue developing your product. To put it differently, doing more coding without having first analysed the user feedback does not imply a significant risk of taking your product in the wrong direction.
There are two scenarios when delayed grooming may makes sense: Imagine you develop a new product and you are waiting for user feedback on the latest product increment. Now you want to validate a new, independent assumption, for instance, that you have selected a viable revenue source. So you decide to continue the development before you have analysed the feedback. Similarly, delaying the grooming work may be acceptable if you develop a mature product where swiftly reacting to user feedback is often not as critical.
Choosing the right point in time to groom your product backlog minimises the risk of developing the wrong product. It may be tempting to delay the grooming work, as it can be easier to write code than talking to target users and customers. But you should only employ this option if you do not require user input to decide how to take your product forward. Have the courage to stop and reflect on the feedback obtained rather than ploughing through your backlog items. To learn more about product backlog grooming, book a place on my Mastering the Product Backlog training course, or get in touch.
About the Author
Roman Pichler helps his clients develop innovative and successful software products – products that customers love. He is the author of three books on Agile and Scrum including “Agile Product Management with Scrum: Creating Products that Customers Love,” and a frequent speaker at international conferences. Find out more at his website or visit his blog.