Everything You Need to Know About Program Backlog and Solution Backlog
A backlog is a list of items of importance that a team will have to implement in an organization. You can consider it to be a central space, where every work pending is added. These pending works can be tasks, user stories, features or epics. These are crucial elements to support the strategic plan that an organization should execute. Let us consider that an organization follows the Scaled Agile Framework. In this case, the organization will be following an organized approach. This approach will be for aligning and managing the items in the backlog to be completed. In SAFe, you will come across Program Backlog, Solution Backlog and Team Backlog. We will understand what is Program Backlog and Solution Backlog here:
Definition:
Program Backlog
The Program Backlog is a definitive and sole storehouse for all the forthcoming tasks. These tasks are expected to meet the objectives of the Agile Release Train. It basically encompasses future features meant for addressing the needs of users. It is also for delivering benefits to the business and the architectural features. These architectural features are needed for creating the Architectural Runway which is essential to host the forthcoming feature backlog.
In general, SAFe helps businesses to transform business requirements into working software. Above all, it helps with these things to happen in a repeatable and consistent way. You can consider this process as a progressive and ongoing refinement of business needs. This will continue to happen until the discrete items of value can be consented to for implementation by delivery teams. It happens using a set of transformations through operating levels of SAFe.
Solution Backlog
The Solution Backlog is the repository of forthcoming enablers and capabilities. These capabilities and enablers can spread over many Agile Release Trains. Its intent is to improve the solution and create its architectural runway. The Solution Backlog is taken care of by the Solution Management in an organization.
More details:
You can consider Program Backlog as a list of features that are ranked in a particular order. These features are to be added before the product release. The Portfolio Backlog is the source of origin for the Program Backlog. Nevertheless, features from other sources can become part of the Program Backlog straightaway. The Program Backlog is continuously constructed. Also, it works hand-in-hand with the execution of the present Program Increment or PI.
Well before the next PI Planning event, the target feature set for the forthcoming Program Increment should be kept ready. The reason is that the time and effort it will take for the next PI event will be greatly reliant on the preparedness of the feature set. Kanban board is commonly used by most teams for the construction of Program Backlog. The reason is that in Kanban, different stages of feature refinement are reflected in a series of workflow states. Here, each stage will give more information as compared to the previous stage. In this way, the final stage will have features that are ready for pulling into a program for the transformation into working software.
Importance of Backlog When Using Agile:
The basic strength of Agile is that it can deliver value to customers rapidly. With a focus on satisfying customers, fast iterations and deployment of new enhancements and features take place in Agile. Even, it becomes possible to achieve product priorities with this iteration.
Spring planning sessions depend on the backlog for slot development tasks, size, scope and references. Let us consider that backlog is not present. If this happens, it will be a struggling situation for the development team to evaluate and develop a confident schedule. As a result of this, the product development teams may complete sprint tasks faster than the expectation. For instance, specific projects might get canceled or can come to a halt. With the most accurate backlog, teams can turn competent enough to move swiftly. Thereafter, they can pay attention to following the most crucial items in the backlog. The good thing about backlog is that it can prevent the teams from staying idle. Also, it will aid teams to get some additional time on projects that are not the priority.
Further, a look into the backlog can help teams get a preview of what is forthcoming. In turn, technical teams can start thinking about how they are going to put into practice those items. Above all, they can lessen the dependencies and conflicts or advanced work needed. When a team has a well-maintained backlog, the contents of any sprint will occasionally be the initial item that the team comes across.
Know about Program and Solution Backlog:
The Program Backlog acts as a repository of forthcoming features. These features are for addressing user needs and delivering business benefits for the Agile Release Train. It also encompasses the enabler features that are required for creating the architectural runway. When you are understanding about Program Backlog, it is better to understand about Solution Backlog as well. It is the repository of upcoming enablers and capabilities. Every enabler and capability part of a Solution Backlog can span multiple Agile Release Trains. Also, each one of them is intended to improve the solution and develop its architectural runway. The solution management takes care of the Solution Backlog.
The Program Backlog in an organization is handled by the product management. The contents for both these backlogs are created from research activities. Also, they are added with active association from different stakeholders and customers. Even, they are added with the ongoing exploration done by the solution engineering/architects team. The other people to add items to the backlog are system architects, product owners, product management and business owners. Their respective solution and program Kanban systems help with managing the items in these backlogs. However, the items do not get into the backlog list with ease. Before adding every item to the backlog, they should pass through the stages of the funnel. Then, they get through proper analysis. Those items that are identified as items of high importance alone become part of the backlog. Nevertheless, they are added only after they are elaborated and approved to the fullest satisfaction. The prioritization is done based on the other items in the backlog.
To ensure success, it is crucial to effectively find, refine, prioritize and sequence the backlog items. These things should be done using the WSJF approach. This approach is expanded as Weighted Shortest Job First. With a focus on quality, speed and long-term value delivery, the capacity allocation should be used. The reason is that the backlog list often contains both enablement work and new business functionality. These are required for extending the architectural runway.
The solution and Program Backlogs are storehouses for all the forthcoming work that affects how the solution behaves. The solution and product management prioritize, keep up and develop the solution and Program Backlogs respectively. The backlogs are short-term places for holding capabilities and features. These features would have gone through their appropriate Kanban systems. Also, the items in the backlogs have already been accepted for implementation. As given in the image below, backlog items are gauged in story points:
Source: Scaled Agile
Backlog Refinement:
Solution and Agile Release Trains run a stable 8-12 week program increment shortly called PI cadence of Inspect & Adapt, demonstration, execution and planning. This systematic pattern is the soul that motivates the preparedness of backlog too. You are going to add intolerable risk to the forthcoming program increment. This will happen when you appear at PI planning or pre-PI planning without a well-explained backlog. The solution and product management will be busy during the PI planning time. The reason is that these teams will ever be in the process of polishing their backlogs when they prepare for the forthcoming PI. One of the basic motives of Solution and Program Kanbans is to make the process visible and keep the backlog ready for the forthcoming PI.
Backlog Refinement encompasses:
- Recognizing the enablers needed for underwriting fresh capabilities and features. Initiating their capacity allocation.
- Evaluating methods to divide items in the backlog into smaller blocks of incremental value.
- Working with the teams for the establishment of scope estimates and technical practicality.
- Assessing and updating the definition of items in the backlog.
- Creation of benefit hypothesis and acceptance criteria for items in the backlog.
Backlog Prioritization:
When talking about the crucial economic motivation for the solution, ranking the solution and Program Backlogs holds a key position. For successful sequencing of jobs, Solution and Product management teams employ the WSJF prioritization method. This method of sequencing translates to an easy-to-understand formula as in the picture below:
Source: Scaled Agile
Preparation for PI Planning:
When your organization prepares for PI Planning, it would be better to ensure that this is done at least a week or a couple of weeks in advance. During this time, the solution and product management should take care of the final backlog preparation. They should also socialize the backlog, work with the product owners, update the version briefings during these two weeks before the event. Further, a week or two before the event, the solution and system engineers/architects should do one thing. They should update the enabler models and definitions. Further, they should create use cases that explain how the capabilities and features work hand-in-hand for releasing value to the end-user.
Optimizing Solution Integrity and Value With Capacity Allocation:
Solution Trains and Agile Release Trains face a lot of challenges. One of them is the establishment of a balance between the backlog of business capabilities and features with the requirement to make ongoing investment in the architectural runway. To prevent the reduction of speed and to delay the requirement for wholesome replacement of elements due to technological antiquation, ARTs should do one thing. It is that the Agile Release Trains should invest continuously in the implementation of enablers of the solution. This makes the challenges of prioritizing complicated. The reason is that different people can drag the teams in their desired directions. You can understand this from the picture below:
Source: Scaled Agile
The association that happens at the time of WSJF prioritization is generally enough to communicate concerns. It is also enough to arrive at a very good balance of work. When the approach is not enough, Agile Release Trains may apply capacity allocation. During the capacity allocation, they can decide the level of total effort used for every kind of move for the forthcoming PI. Moreover, they agree on identifying how the work is done for each type of move. This can also encompass particular reserves for continuous maintenance and the reduction of any technical debt that may have gathered. The policies agreed upon can persist for some time. But, the capacity allocated should change from time to time on the basis of the context. When you take the case of an Agile Release Train, this decision can be changed when you refine your backlog.
Wait Times, Little's Law, Queues on Backlogs:
You know what is Program Backlog now. SAFe recommends taking a brief aside. You can use this brief for discussing the relationship between flow, wait time and backlog. The solution and Program Backlogs can have a considerable effect on the time of delivery and throughput. According to Little's Law, the average time to wait for an item in the backlog list is equal to the average length of the queue. You should divide this value by the average rate of processing for an item in the list. You can understand that when a queue is longer, the wait time will be higher obviously. You have guessed it right! Long queues are not good. The reason is that they can lead to a decrease in motivation. In turn, they can increase the risk as well.
Conclusion
When thinking about program and Solution Backlog, you should remember one thing. They are not queues. The reason is that some items in the backlog can jump over the other when they are needed for a quicker release. But, let us consider the items in a backlog as committed to stakeholders. In this case, the backlog items will work as queues. So, the longer the queues, the longer they will have to wait. In this case, they can lose interest. The idea here is to keep the backlogs as short as possible. Also, the teams should work faster to clear every item in the backlog. But, there should be flexibility to complete some items coming up with the highest priority.
References
- https://www.scaledagileframework.com/program-and-solution-backlogs/
- https://kendis.io/scaled-agile-framework/team-vs-program-backlog/
- https://www.solutionsiq.com/agile-glossary/program-backlog/
- https://theburndown.com/2018/01/14/program-backlog-construction/
