“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.
Scrum has a product focus; it knows a product owner, a product vision, a product backlog, and a product increment. But what is a product?
The answer to this question can be tricky. Take the attendees of a recent product owner workshop I ran who found it difficult to agree on what their products are. Another client of mine was completely project-driven before using Scrum; short projects often updated a number of application and systems. When asked about their products, developers would answer, “Oracle,” or “Websphere” rather than referring to the software they created. And another company I worked with had more than 20 different definitions of the term product.
So what is a product? I like to think of a product as collection of attributes (or features) that address customer or user needs thereby providing value. A good first step in identifying products is to ask, “Who benefits from our software? Who purchases and who uses it?” and “What value does the software provide?”
A product is developed using a project, which creates one or more releases and results in a new product version, as the following sequence shows:
Customer and user needs
→ Are addressed by a product
→ Has a version
→ Is developed by a project
→ Creates one or more releases
Products are means to an end – to meet customer and user needs. Projects and teams serve to bring the next product version to life. Understanding which products an organisation develops is the prerequisite for achieving product success. It enables longer-term thinking and finding the right people. Only if it’s clear what the product is can management find the right product owner and can the right people be invited to join the development effort.
So think products. Not projects, not teams, and not components. Focus on what ultimately counts – to create a great product to help customers and users – and organise accordingly.
RSS