{"id":338,"date":"2011-04-11T11:05:39","date_gmt":"2011-04-11T09:05:39","guid":{"rendered":"http:\/\/leanmagazine.net\/?p=338"},"modified":"2024-03-15T15:18:50","modified_gmt":"2024-03-15T14:18:50","slug":"making-the-product-backlog-lean","status":"publish","type":"post","link":"http:\/\/leanmagazine.net\/req\/making-the-product-backlog-lean\/","title":{"rendered":"Making the product backlog lean"},"content":{"rendered":"

\"Isolated<\/a><\/p>\n

\u201cWe have 12,000 stories in our product backlog. How can we best groom it?\u201d<\/em>, 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 artifact listing the outstanding work to bring the product to life. It\u2019s time to put any over-weight product backlog on a diet making it lean and concise.<\/h4>\n

Think Lean
\n<\/strong>Lean thinking aims to create a smooth, leveled flow of work by removing waste, minimizing 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.<\/p>\n

Eliminate Waste
\n<\/strong>Waste consumes valuable resources and makes it harder to focus on what\u2019s important. To remove waste in the product backlog, reduce the inventory\u00a0 the backlog holds, avoid overproduction and minimize defects, handoffs and wasted creativity, as I explain in more detail below. Reduce the inventory: Minimize the amount of detailed product backlog items and only include items in the backlog that are essential for creating a successful product. Ensure\u00a0 that just-enough high-priority items are detailed just in time for the next sprint planning meeting. As a consequence, product backlog items are\u00a0 progressively decomposed and refined \u2013 from sprint to sprint. Lower-priority items stay coarse grained and sketchy until their priority changes.<\/p>\n

Avoid overproduction \u2013 providing more functionality than users and customer need. Focus on the minimum functionality necessary to\u00a0bring the product to life, and only list truly valuable items in the backlog. Remove all other items from the product backlog. This keeps\u00a0the product backlog concise and the Scrum team focused. If the item becomes important for a future version, it will re-emerge.<\/p>\n

Minimize defects, handoffs and\u00a0 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 allows us to prevent defects at a later stage of the project.<\/p>\n

Limit Undesirable Variation<\/strong>
\nNot all variation in the product backlog is wrong. The size of the product backlog items should vary according to their priority, for instance. But unnecessary variation, also called unevenness, prevents a smooth flow of work. Try the following to minimize variation in the product backlog: Standardize the techniques for describing\u00a0 product backlog items. Choose user stories to capture functional requirements and operational qualities such as performance and robustness requirements, for instance. Agree on a common way to describe usability requirements such as sketches, wire-frames or mock-ups.
\nUse a sprint goal. The sprint goal summarizes the desired outcome of the sprint, and moves the Scrum team a step closer toward the release of the product. A shared sprint goal ensures that everyone is working toward a common goal. It minimizes variation by limiting the type of requirements worked on in a given sprint, for instance, by choosing items from the same theme. This facilitates close teamwork and can increase velocity.<\/p>\n

Ensure that the high-priority items have roughly the same size and favor small items \u2013 items that can be transformed into a part of the product increment within a few days. This reduces variation, improves the progress tracking within the sprint, and prevents defects by allowing the product owner to provide just-in-time feedback on the work results. Note that this approach works best when the team uses agile development practices including storydriven development.<\/p>\n

Create a steady cadence by using fixed-length releases. Timebox your projects: Identify the window of opportunity based on the product vision and the product backlog, and freeze the release date. Take Salesforce.com, a leading provider of on-demand customer relationship management services. The company releases a product update every four months. As a consequence, Salesforce.com experienced an amazing increase in the number of features delivered while drastically reducing its lead-time for new functionality. Note that a fast, steady cadence supports other measures including minimizing the inventory in the product backlog.<\/p>\n

Prevent Overburden<\/strong>
\nAs long as people work crazy hours, and as long as projects and teams are overwhelmed by the amount of work, the removal of waste and variation is ineffective. Waste and variation are likely to creep back in unless we limit the amount of work to the capacity and capabilities of the organization. Let\u2019s assume we try to eliminate defects but the project still suffers from overburden. Chances are that quality problems reappear since the project members still feel pressured and are overworked. In fact, overburden is a major source of waste including work-in-progress, waiting and delays, task-switching, and defects.<\/p>\n

To eliminate overburden, let the product backlog evolve based on customer and user feedback. View changing requirements as a competitive advantage and leverage the feedback together with the project progress to decide which functionality is implemented. Encourage the team to pull only as many items into the sprint as they can transform into a product increment in a sustainable way. Ensure that the high-priority items are ready: They should be clear, testable and feasible. This avoids that the team overlooks tasks and pulls too much work into the sprint. And last but not least, make high-priority items small. This allows the team to optimize its work utilization. It also avoids the danger of missing tasks \u2013 which is a common issue with large stories.<\/p>\n

Summary<\/strong>
\nKeep your backlog simple, concise and lean. Focus on the items that are essential for bringing the product to life. Be courageous and ruthlessly weed out all other items. This will make your product backlog lean and increase the likelihood to develop a successful product.<\/p>\n","protected":false},"excerpt":{"rendered":"

\u201cWe have 12,000 stories in our product backlog. How can we best groom it?\u201d, 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 […]<\/p>\n","protected":false},"author":32,"featured_media":455,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24,83,14],"tags":[15,29,45],"_links":{"self":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/338"}],"collection":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/comments?post=338"}],"version-history":[{"count":15,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/338\/revisions"}],"predecessor-version":[{"id":1113,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/338\/revisions\/1113"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media\/455"}],"wp:attachment":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media?parent=338"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/categories?post=338"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/tags?post=338"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}