{"id":2245,"date":"2022-02-07T14:40:46","date_gmt":"2022-02-07T14:40:46","guid":{"rendered":"https:\/\/dcss.in\/?p=2245"},"modified":"2022-02-07T14:45:13","modified_gmt":"2022-02-07T14:45:13","slug":"product-backlog","status":"publish","type":"post","link":"https:\/\/dcss.in\/index.php\/2022\/02\/07\/product-backlog\/","title":{"rendered":"Product Backlog"},"content":{"rendered":"Reading Time: <\/span> 5<\/span> minutes<\/span><\/span>\n

A product backlog in Agile is, essentially, a list of items that are \u201con deck\u201d for the development team. It\u2019s a to-do list of items that need to be completed within a larger product. It\u2019s worth noting that these aren\u2019t items that you\u2019re working on within the two-week sprint, but it helps you see what\u2019s coming up so your team can plan and work quickly to release new features.<\/p>\n\n\n\n

A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The development team doesn’t work through the backlog at the product owner’s pace and the product owner isn’t pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it, either continually (kanban) or by iteration (scrum). <\/p>\n\n\n\n

\u201cKeep everything in one issue tracker\u2013don\u2019t use multiple systems to track bugs, requirements, and engineering work items. If it’s work for the development team, keep it in a single backlog.\u201d<\/p>\n\n\n\n

The product backlog sits outside of the sprint loop (meaning it contains work that will not be completed during the current sprint) but informs how your sprint will be planned. The product backlog is composed of feedback from:<\/p>\n\n\n\n

  • The development team<\/li>
  • Customer<\/li>
  • Stakeholders<\/li><\/ul>\n\n\n\n

    Why does a product backlog matter?<\/strong><\/p>\n\n\n\n

    Think of a product backlog as a way of putting a brainstorm or a product plan into action. You\u2019ll undoubtedly be approached by stakeholders (or customers) who have many ideas for improving the product. Not all the ideas are good and not all the ideas are valuable, but without an organized product backlog, it\u2019s difficult to differentiate between the great, valuable ideas and the ideas that would only be a waste of time. Here are some other benefits of the product backlog:<\/p>\n\n\n\n

    • It\u2019s an organized list that\u2019s easily wrangled.<\/li>
    • It\u2019s simple to prioritize.<\/li>
    • It can be changed as priorities change.<\/li>
    • It allows you to immediately see dependencies and order them.<\/li>
    • It allows you to think about products in the long-term, not just in terms of immediate needs.<\/li><\/ul>\n\n\n\n

      In short, a product backlog allows you and your team to make systematic, smart improvements to a product over the long haul.<\/p>\n\n\n\n

      What\u2019s in the product backlog?<\/strong><\/p>\n\n\n\n

      The Scrum Guide is fairly prescriptive about what can be in the product backlog, which is helpful for keeping unnecessary items out. The product backlog contains:<\/p>\n\n\n\n

      • Features<\/li>
      • Functions<\/li>
      • Requirements<\/li>
      • Enhancements<\/li>
      • Fixes<\/li><\/ul>\n\n\n\n

        It\u2019s not just a simple to-do list, though. Each item in the product backlog:<\/p>\n\n\n\n

        • Adds value for the customer<\/li>
        • Is prioritized<\/li>
        • Is estimated<\/li><\/ul>\n\n\n\n

          There should be no low-level tasks in your backlog (like sending emails), and the backlog itself should be a living document that\u2019s regularly rearranged.<\/p>\n\n\n\n

          How to create a product backlog<\/strong><\/p>\n\n\n\n

          It\u2019s common for product backlogs to be presented in the form of a spreadsheet, but there\u2019s a big problem with that: Spreadsheets aren\u2019t meant to have their rows constantly moved. Plus, you\u2019ll find yourself dealing with formatting issues and the ensuing migraine.<\/p>\n\n\n\n

          Product backlog\u2014it\u2019s a living document that\u2019s easy to share with stakeholders and rearrange however you\u2019d like.<\/p>\n\n\n\n

          1. Add ideas to the backlog –
            Stakeholders will typically be approaching you with ideas for product improvements<\/li>
          2. Get clarification –
            Once you\u2019re approached by a stakeholder with a product addition or fix, make sure you understand:<\/li><\/ol>\n\n\n\n
            • The reason behind the addition or fix<\/li>
            • The amount of value it contributes to the product as a whole<\/li>
            • The specifications of the item<\/li><\/ul>\n\n\n\n

              3. Prioritize<\/p>\n\n\n\n

              The backlog should have clearly defined, high-priority items at the top and vague items that are not a priority at the bottom. If an item has no value, it should not be added to the backlog.<\/p>\n\n\n\n

              4. Update the backlog regularly<\/p>\n\n\n\n

              The backlog is a living document; make sure you\u2019re constantly prioritizing, refining, and keeping the backlog up to date.<\/p>\n\n\n\n

              You may have hundreds of items in your backlog as ideas for product improvements are suggested. Some of these items may be discarded, but many of them will begin making their way up the backlog for further refinement and, ultimately, development.<\/p>\n\n\n\n

              Start with the two “R”s<\/strong><\/p>\n\n\n\n

              A team’s roadmap and requirements provide the foundation for the product backlog. Roadmap initiatives break down into several epics, and each epic will have several requirements and user stories.<\/p>\n\n\n\n

              The product owner then organizes each of the user stories into a single list for the development team. The product owner may choose to deliver a complete epic first . Or, it may be more important to the program to test booking a discounted flight which requires stories from several epics. <\/p>\n\n\n\n

              What may influence a product owner’s prioritization?<\/p>\n\n\n\n

              • Customer priority<\/li>
              • Urgency of getting feedback<\/li>
              • Relative implementation difficulty<\/li>
              • Symbiotic relationships between work items (e.g. B is easier if we do A first)<\/li><\/ul>\n\n\n\n

                While the product owner is tasked with prioritizing the backlog, it’s not done in a vacuum. Effective product owners seek input and feedback from customers, designers, and the development team to optimize everyone’s workload and the product delivery.<\/p>\n\n\n\n

                Keeping the backlog healthy<\/strong><\/p>\n\n\n\n

                Once the product backlog is built, it’s important to regularly maintain it to keep pace with the program. Product owners should review the backlog before each iteration planning meeting to ensure prioritization is correct and feedback from the last iteration has been incorporated. Regular review of the backlog is often called “backlog grooming” in agile circles(some use the term backlog refinement).<\/p>\n\n\n\n

                Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items. Near-term items need to be fully fleshed out before they are labeled as such. This means complete user stories have been drawn up, collaboration with design and development has been sorted out, and estimates from development have been made. Longer term items can remain a bit vague, though it’s a good idea to get a rough estimate from the development team to help prioritize them. The key word here is “rough”: estimates will change once the team fully understands and begins work on those longer term items.<\/p>\n\n\n\n

                The backlog serves as the connection between the product owner and the development team. The product owner is free to re-prioritize work in the backlog at any time due to customer feedback, refining estimates, and new requirements. Once work is in progress, though, keep changes to a minimum as they disrupt the development team and affect focus, flow, and morale.<\/p>\n\n\n\n

                Once the backlog grows beyond the team’s long term capacity, it’s okay to close issues the team will never get to. Flag those issues with a specific resolution like \u201cout of scope\u201d in the team’s issue tracker to use for research later.<\/p><\/blockquote>\n\n\n\n

                Anti-patterns to watch for<\/strong><\/p>\n\n\n\n

                • The product owner prioritizes the backlog at the start of the project, but doesn’t adjust it as feedback rolls in from developers and stakeholders.<\/li>
                • The team limits items on the backlog to those that are customer-facing.<\/li>
                • The backlog is kept as a document stored locally and shared infrequently, preventing interested parties from getting updates.<\/li><\/ul>\n\n\n\n

                  Product owners dictate the priority of work items in the backlog, while the development team dictates the velocity through the backlog. This can be a tenuous relationship for new product owners who want to “push” work to the team. Learn more in our article about work-in-progress limits and flow.<\/p><\/blockquote>\n