Welcome to PremierAgile! Chat with our learning advisor to avail Upto 15% discount across all Scrum Alliance courses Recognised as “Best Agile Consulting and Transformation companies - 2022” by BusinessConnect Magazine Avail Zero Interest EMI No Credit Card Required Mega offer! Save upto INR 22,000 when you buy our Advanced course combo packages

PremierAgile

With an objective to enable continuous learning and progression for our learners, PremierAgile curated several learning articles. Out of a wide range of topics, you can choose to learn from the real-world experiences by practitioners in the areas of Agile, Scrum, Product Ownership, Scaling, Agile Leadership, Tools & Frameworks, latest market trends, new innovations etc.

Everything You Need to Know About Team Backlog

When it comes to the Agile world, a Product Backlog is a set of requirements. It is also a set of supported activities that are collected for the creation of the desired product. The Product Backlog can be in many forms like spikes, technical debts, User Stories, features, epics, and even bugs. Together, they are referred to as Product Backlog items. 

Let us consider that your business plans to deal with the Product Backlog items in an Agile Way. In this case, you should understand that the scope of the Backlog is variable. The reason is that at times, some items get into this Backlog list; the list evolves and some items go away from the list. These things happen all through the product development phases. The next item to be considered in the Backlog list will be decided based on what the business needs and strategic plan. You can see the Product Backlog items list as a central place of holding. It encompasses the list of items that are going to be handled one after the other by the delivery team.

Backlog Items in Scaled Agile Framework:

The good thing about Scaled Agile Framework is that it offers a very organized and structured approach. Particularly, this approach is for effective management and alignment of the work items to be completed. When you take the case of SAFe®, you should learn about different categories of Backlog items. They are listed below:

  • Team Backlog
  • Solution Backlog
  • Program Backlog
  • Portfolio Backlog

Of course, you should know about all these Backlogs in SAFe®. Nevertheless, we are here to discuss more what is a Team Backlog. 

Team Backlog – The Meaning:

When talking about Team Backlog in SAFe®, the Product Owner is responsible for this Backlog. It encompasses enablers and User Stories that come out of the Program Backlog. The stories for the team Backlog are derived from the Solution Backlog. Even, it might encompass other work items too. In short, a Team Backlog represents everything that a team should do to contribute its share to the entire system. It encompasses both enablers and User Stories. So, it is crucial to distribute volume in a method that equates investment across the needs of customers. When distributing volume, it is essential to consider both the requirements of the Agile Release Train and the team. In simple terms, Team Backlog provides a list of things that a team wants to do. However, this list does not contain the things that the team commits to doing. It will generally include a particular time committed for completing each item. It can also be the estimated time to complete.

So, you should know that the Product Owner is responsible for safeguarding the team. It means that he/she should safeguard the team against the issue of many stakeholders. The reason is that at times, different stakeholders will have different views of what is important. In team Backlog, all members of a team can add stories to the Backlog. In addition to enablers and User Stories, it also encompasses improvement stories. These are stories that grab the outcomes of the iteration retrospective of the team. 

The good thing about Team Backlog is that it comfortably conceals some of the intricacies associated with Agile at Scale. Here is a picture that shows the Team Backlog having three basic sources of input for your understanding

Source: ScaledAgile

When you take the case of Program Backlog, it encompasses forthcoming features that are intended to be released by an Agile Release Train. When they engage in PI Planning, teams split the candidate features for the PI into stories. Then, in the Team Backlog, they provisionally schedule into forthcoming iterations. Teams in the ART do not stand alone. Rather, their Backlogs will encompass stories that brace the work of other teams. Also, it will encompass the Agile Release Train’s Program Increment Objectives. These can encompass projections for studies that are needed for supporting the features estimation, epic estimation and even estimation of capabilities. Apart from the stories required to meet features, the team will have a Backlog of local stories. These local stories denote new technical debt, research, defects, refactors, and functionality. They are created as enabler stories that are given importance and estimated in a similar way as User Stories.

Improve System Health and Value Delivery with Capacity Allocation:

Similar to Agile Release Trains, every Agile Team faces issues when balancing the Backlog of works that face inwards, technical debt, refactors, and maintenance. They balance these things with fresh User Stories that can release more immediate value to the business. Paying attention mainly to business processes may work for some time. Even, it can provide quick appeasement to the market. Nevertheless, this satisfaction will be for a short period. The reason is that the value of technical debt increases, thereby slowing down the speed at which development is achieved. To alleviate this, teams make ongoing investments in improving the architecture of the solution. Even, they spend as much as required to keep the present customers satisfied. They do this by providing enhancements and bug fixes to the existing product users. In turn, the requirement for the substitution of the entire system because of technological antiquation is avoided.

Achieving a balance of these varied kinds of work will complicate the dispute of prioritization. The reason is that the Product Owner will look for ways to collate the worth of unlike things. Examples of these things are fresh User Stories, technology upgrades, redesigns, refactors, and defects. Also, there is no higher-level restriction to the request for any of these things. Similar to what they do with the Product Backlog, teams apply capacity allocation to the Team Backlog as well. They do this for identifying the level of entire effort that can be employed for each kind of work in a given timebox. You can understand the same from the following picture:


Source: ScaledAgile

Product Owner in association with a team will choose the items in the Backlog with the highest priority. This selection is done for each slice of the capacity allocation to a device in an iteration. For stories that are perpetrated to the program, the progress is determined in advance by PI Planning Commitments. Nevertheless, for the local stories of a particular team, the Product Owner can determine the order of those using size/value considerations. Otherwise, the Product Owner can use full weighted shortest job first, where it is advantageous. Further, to bring a balance between value delivery and long-term product health,  it is possible to adjust the allocation of each kind over time. This can be done typically at the boundaries of the Program Increment.

Refinement of Backlog:

The team Backlog should always encompass stories that are prepared for implementation. This happens without any considerable surprise or risk. To keep up this Backlog preparedness, Agile teams follow a flow-based approach. They do this by having a minimum of one team Backlog refinement episode per iteration. At times, they typically have at least one episode per week. The good thing about the Backlog Refinement is that it goes through the forthcoming stories. This is done for estimating, discussing, and establishing a first-hand understanding of the acceptance criteria. Here, teams have the option to apply development based on behavior. They use particular examples for clarifying stories.

Your team should remember that Backlog Refinement should be done as an ongoing process. Teams have the option to revisit a particular story several times before they finalize and commit it to iteration Planning. Also, the organization should remember that as many teams engage in Backlog refinement, there are chances of new dependencies, issues, and stories to show up. In this way, Backlog refinement aids with surface issues with the present plan. These issues should be taken for discussion at the time of Agile Release Train Sync events.

Difference Between Team and Program Backlog:

Understanding the difference between team and program Backlog will help you plan things accordingly. Here is a table to understand how they are different from each other.


S. NoPoint of DifferenceTeam Backlog

Program Backlog


1What is included?Encompasses enablers and User Stories for each team of the Agile Release Train that should be completed in an iteration.Encompasses enablers and features that should be put into practice by the Agile Release Train for delivering value in a PI.
2OwnerThe product owner is the owner of User Stories out of the program Backlog. During PI planning, the split-up of features to the User Story level takes place.The Program Backlog is owned by the product management of the program.
3Managed byTeam Backlog can be managed either using Scrum or Kanban board as per the desire of the team.Kanban system is used for managing the program Backlog
4Addition of StoriesAll members of the team can add stories to the team BacklogOnly the product management can add stories to the program Backlog
5Addition of FeaturesTo attain clarity on User Stories, teams follow behavior-driven development.Extensive research followed by discussion is done with system architects, product owners, business owners and even customers for the creation of features.


Conclusion

Having a couple of different yet dependent Backlogs like a Team and Program Backlog will help. The reason is that it will aid with the management of expectations and work more effectively than ever before. It is even more important in SAFe® as the presence of two Backlogs separately will have a huge impact on the progress and visibility of the work in progress. In turn, alignment, transparency, and predictability become possible to help teams achieve their goals.

References
  1. https://www.scaledagileframework.com/team-Backlog/
  2. https://www.linkedin.com/pulse/demystifying-Backlogs-safe-program-Backlog-vs-team-chinchu



Author

Paula

Is a passionate learner and blogger on Agile, Scrum and Scaling areas. She has been following and practicing these areas for several years and now converting those experiences into useful articles for your continuous learning.