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. No | Point of Difference | Team Backlog | Program Backlog |
| 1 | What 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. |
| 2 | Owner | The 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. |
| 3 | Managed by | Team 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 |
| 4 | Addition of Stories | All members of the team can add stories to the team Backlog | Only the product management can add stories to the program Backlog |
| 5 | Addition of Features | To 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
- https://www.scaledagileframework.com/team-Backlog/
- https://www.linkedin.com/pulse/demystifying-Backlogs-safe-program-Backlog-vs-team-chinchu
