Work Prioritization in Team Backlog

In the world of Agile development, a product backlog is a critical tool used to maintain a list of work items needed to develop and maintain a product. It serves as the source of truth for teams and is updated daily as required.

This post delves into the most efficient methods to tackle Team Backlog and reveals vital best practices that can be adopted during various phases of your learning journey. By adhering to these fundamental techniques, you can develop the competence and awareness necessary to execute effective team strategies. Nonetheless, it's crucial to recognize that Team Backlog is only a fragment of the broader context. To attain a comprehensive insight into your team's present process status, we suggest using our free agile assessment for Team Agility.

Team Backlog and The Learning Journey

At Lean Agile Intelligence, we recognize Team Backlog as the team's ability to envision success and effectively communicate it. We divided the learning journey into 4 different stages: Developing, Emerging, Adapting, and Optimizing. In the following sections, we will discuss each stage in detail as well as provide practical tips and techniques to help you extend your skills in this area. 

Source - The GO Product Roadmap

Developing

Teams that are “developing” an understanding of the value of Team Backlog and adopting the foundational techniques should focus on the following improvements

• The What: It contains all work required to be completed by the team 

  • The How: It’s important to put ALL work the team is or potentially could work on including but not limited to new features, stories, maintenance, support issues, continuous improvement items, spikes, etc.

• The What: It is actively managed and seen as a dynamic list prioritized by value
  
  
  • The How: The Team Backlog is not meant to be all the work needed to complete a project but instead an emergent list of items that is updated daily as needed but minimally per sprint. As the team gets feedback at sprint reviews from customers, stakeholders, etc; the backlog gets updated accordingly.

• The What: Easily visible and transparent to all stakeholders and team members

  • The How: Everyone inside the team and any parties interested in the team’s work should be able to see what is in the backlog. If you are using physical space, anyone visiting the team area should be able to understand team progress and updates just by Big Visible Information Radiators on the wall including but not limited to Scrum/Kanban boards, Backlog, Burn-down/Burn-up, Release Forecasts, Impediments, Metrics, etc. If you are using a digital tool, ensure key stakeholders understand your taxonomy and know where to find the above artifacts.

Emerging

Teams that are “emerging” beyond the foundational techniques of Team Backlog and are embracing it as they become more proficient, should focus on the following improvements

• The What: Only a small portion (i.e., three sprints or less) of the Team Backlog is committed

  • The How: Since backlogs are not project plans but emergent ideas and work for the team, teams commit to small batches of work and forecast beyond the commitment using the best data they have available. In Scrum, teams often using historical velocity to forecast. In Kanban, and even in Scrum, teams will often use probabilistic forecasting.

     

• The What: Committed backlog items (i.e., User Stories) have a description, order, estimate, and a clear explanation of the value they deliver
  
  • The How: In order to achieve the criteria in this “Emerging” stage, it’s a good idea to establish a working agreement called a “Definition of Ready.” A good starting point is Bill Wakes “INVEST” which stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. His original post on the topic can be found here

• The What: Calls out dependencies

• • The How: Add dependencies to your Definition of Ready. For a more in-depth reading of this topic, read this post by Robert Galen.

*   *   *   *   *   *

"Backlog refinement is a fundamental activity for any agile team."

*   *   *   *   *   *

Adapting

Teams that are “adapting” the Team Backlog practice to extract the full benefit, should focus on the following improvements

• The What: Collective ownership and real-time collaboration among all team members on backlog items (i.e., User Stories)

  • The How: Backlog items are owned by the entire team. This concept of collective ownership is often difficult for teams and organizations to adopt. Many of the Agile Manifesto authors were practitioners of a software development methodology known as “Extreme Programming” The following is a quote about collective ownership from ExtremeProgramming.com

    • “The way this works is for each developer to create unit tests for their code as it is developed. All code that is released into the source code repository includes unit tests that run at 100%. Code that is added, bugs as they are fixed, and old functionality as it is changed will be covered by automated testing. Now you can rely on the test suite to watchdog your entire code repository. Before any code is released it must pass the entire test suite at 100%.”

Source - What is Kanban? Explained for Beginners

Optimizing

Teams “optimizing” the knowledge sharing of the Team Backlog practice learnings across the enterprise should focus on the following improvements

• The What: A majority of the backlog items (i.e., User Stories) are independent items that can be delivered by one team without excessive coordination

  • The How: Backlog items should be sliced vertically containing a full stack of skills to deliver an independent piece of value. Sometimes this is not possible due to the way teams are structured. In this case, teams often slice them too small so their team can deliver part of the work and will depend on another team to finish it. It’s not realistic to think there will never be any dependencies but keeping track of dependencies is the first step to eliminating them when possible. The focus should not be to manage them but remove them entirely. This may require a shift in team structure or require growing skills on both teams over time.

*   *   *   *   *   *

"Everyone inside the team and any parties interested in the team’s work should be able to see what is in the backlog."

*   *   *   *   *   *

Conclusion

In conclusion, mastering the Team Backlog is critical to the success of any Agile team. Teams must understand the importance of the product backlog and embrace the techniques needed to use it effectively. The tips provided in this blog post can help your team develop maturity in this practice and better promote team accountability, identify areas for improvement, and ultimately deliver better products. For a thorough assessment of your team's current process status, we offer a free agile assessment for Team Agility that you can take advantage of.