Tag Archives: waste

Grooming the product backlog means managing the backlog. This is necessary, as the product backlog changes and evolves: The team gains knowledge from exposing a product increment to the users, and the latest insights lead to a backlog update, as the picture below shows.

Much of the existing advice on product backlog grooming focuses on getting the backlog in shape to supply the development team with concise stories. Unfortunately, evaluating user feedback and integrating it into the backlog has been underemphasised. This blog posts tries to set the record straight by offering a holistic, five-step grooming process – from analysing user feedback to getting the backlog “ready”. Please note that I focus on new or innovative products rather than incremental updates of mature products.

Step 1: Analyse the Feedback

Grooming the product backlog starts with analysing the feedback collected from exposing a product increment to target users and customers. The increment may be working software, or in the case of a brand-new product, a paper prototype. The data obtained may be quantitative, qualitative, or both depending on what’s feasible and beneficial. I prefer to work with both, qualitative and quantitative data.

When evaluating the feedback, focus on the data that is relevant to test your ideas and answering your questions. Have the courage to say no to new ideas and requests if these are not helpful to move you closer to your vision. Otherwise, your product is in danger of becoming a feature soup, a loose collection of features with little or no connection, which usually results in a poor user experience.

Be aware of the cognitive bias we all have, your hidden assumptions and wishes, as these can lead to ignoring or misinterpreting data. To mitigate the risk, analyse the feedback together with the team members. Remember that negative feedback is good feedback: If all you ever hear is positive, you are not learning anything new.

Step 2: Integrate the Learning

Once you have analysed the feedback, incorporate your insights into the product backlog. This results in removing, adjusting, and adding content: epics, operational constraints, design and workflow sketches. If the feedback invalidates you assumptions regarding the target group, the user needs, and the business model, you may have to adjust your vision board, remove the product backlog content, and restock your backlog.

Note that in the image above, the product backlog board’s top section is empty, as the high-priority items have been consumed, and new ready stories still have to be created. (This is done in step 4.)

Step 3: Decide what to do Next

After incorporating the learning into your backlog, decide what to do next. Ask yourself why you want to carry out the next cycle. What do you want to learn? Which ideas and assumptions do you want to validate? Which functionality do you want to provide? For new products or innovative features, your goal should be a testable hypothesis, for instance, by using the following format: If we do x, we will achieve y.

My goal for writing this blog post, for instance, is twofold: Consolidate my knowledge about the grooming process and understand if my recommendations resonate with my readers. The first sub goal is met by making time to write the post. The second one is attained if the post gets a comparatively high number of hits, generates a certain amount of Twitter traffic, and attracts meaningful comments.

Step 4: Create Small Stories

Next, carve stories out of the epics in order to reach your goal. Then make the stories high-priority, and order the stories according to their importance for reaching the goal, as the image below shows.

You may also want to ask the team to estimate any epics that have been added or adjusted as well as the newly formed stories. This allows you to understand how much effort is roughly contained in the backlog.

Step 5: Get the Stories Ready

With small, ordered user stories in place, you are close to starting the next cycle. But before you do so, ensure that the stories are “ready”: clear, feasible, and testable. This may entail creating a user interface design sketch and one or more operational quality constraints for the stories, as the image below illustrates.

Getting the stories ready may also require resolving dependencies between teams if several teams work on the same product. The stories should now be ready to be pulled onto the sprint backlog or the Kanban board.

Leverage Teamwork

When I talk to product owners about grooming their backlog, I often discover that the individual carries out the work largely alone. This wastes a massive opportunity: to mitigate the product owner’s cognitive bias, to create shared ownership of the backlog, and to leveraging the team’s collective wisdom and creativity.

As the product owner, involve the team members in the grooming steps. This reduces your workload, and it is likely to result in a better product. Don’t be afraid, however, to facilitate the discussions and to make a decision if no consensus can be reached. You don’t want to get stuck in analysis-paralysis but move on, and test your new ideas and assumptions.

Summary

When grooming your product backlog, don’t forget to collect and to analyse the user feedback. Integrate your insights, select your next goal, write small, detailed stories, and get them ready for implementation. Rely on your intuition as well as the data analysis, and involve the team in the grooming steps.

If you want to learn more about the product backlog, book a place on my Mastering the Product Backlog course in May in London or in September in Cambridge, or contact me.

“We have 12,000 stories in our product backlog. How can we best groom it,” I was recently asked. Trying to deal with a huge product backlog is more common than we would like to think. Many product backlogs are too long, detailed and complex. This is in stark contrast to what the product backlog should be: a simple artefact listing the outstanding work to bring the product to life. It’s time to put any over-weight product backlog on a diet making it lean and concise.

Think Lean

Lean thinking aims to create a smooth, levelled flow of work by removing waste, minimising variation and avoiding overburden. Waste includes inventory and work-in-progress, defects, delays, and unused employee creativity. Examples of variation are frequent changes to the team and varying release cycles. Overburden occurs when people and resources cannot cope with the workload placed on them. If we want a lean product backlog, then it should contain as little waste and variation, and cause as little overburden as possible. This post focuses on eliminating waste. I will discuss minimising variation and avoiding overburden in a future post.

Eliminate Waste

Waste consumes valuable resources and makes it harder to focus on what’s important. To remove waste in the product backlog, reduce the inventory the backlog holds, avoid overproduction and minimise defects, handoffs and wasted creativity, as I explain in more detail below.

Reduce the inventory in the product backlog: Minimise the amount of detailed product backlog items and only include items in the backlog that are essential for creating a successful product. Ensure that just-enough high-priority items are detailed just in time for the next sprint planning meeting. As a consequence, product backlog items are progressively decomposed and refined – from sprint to sprint. Lower-priority items stay coarse-grained and sketchy until their priority changes.

Avoid overproduction – providing more functionality than users and customer need. Focus on the minimum functionality necessary to bring the product to life, and only list truly valuable items in the backlog. Have the courage to remove all other items from the product backlog. This keeps the product backlog concise and the Scrum team focused. If an item becomes important for a future version, it will re-emerge.

Minimise defects, handoffs and unused creativity by involving the team members and the stakeholders in grooming the product backlog. Jointly discovering and describing product backlog items avoids handing off requirements to the team. It ensures clarity of the requirements thereby reducing defects; and it leverages the creativity and knowledge of the team members and stakeholders. Jointly prioritising the product backlog ensures that technical risks and dependencies are accounted for. Problems consequently surface early, which prevents defects at a later stage of the project.

You can find out more about working with the product backlog effectively in my book Agile Product Management with Scrum: Creating Products that Customers Love or by attending my lean thinking course that teaches product owners how to leverage lean techniques.