As an Agile Coach in a Scaled Agile Framework® (SAFe®) implementation environment, I have, to the best of my knowledge, explained about the capacity constraints that need to be considered during the Program Increment Planning.
In this article let us focus on how the key event in Scaled Agile Framework (SAFe), known as Program Increment (PI) is conducted and understand how recognizing the underlying capacity constraints helps the team plan and commit better.
Release planning is a process where the Agile team along with Scrum Master, Product Owner and key stakeholders collaborate to deliver a product increment at regular intervals - typically 2 to 3 months. The Product Owner shares the vision to the team along with a prioritized list of Features that he/she feels can be included in the release. The Agile team works together in splitting the Features to User Stories, estimating Size, and discussing issues & concerns with the Product Owner. They highlight risks, tentatively park the stories across iterations based on the historical velocity that the team can achieve and then arrive at & commit to the release schedule.
Release Planning in Scaled Agile Framework is a two-day timeboxed event and is called a Program Increment.
“Program Increment (PI) Planning is a cadence-based event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision. PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe” – Scaled Agile Inc.,
This focussed and dedicated two-day event brings together the entire Agile Release Train(s) into a common forum and more importantly imforms every individual in the train towards the alignment of development to business goals with the business context, program objectives and to understand the direction of the business. The PI planning event corroborates multiple teams within and across ART(s) to discuss, empathize and structure the flow of work that can be taken up for the upcoming PI duration (typically 8 to 12 weeks).
PI planning establishes face to face communication of all the team members and stakeholders and also matches demand to capacity by eliminating excess Work in Progress(WIP).
Let us look briefly at the sequence of activities that are involved in the 2-day Program Increment event.
Creating a stable and high performing Agile team within an ART depends on how well the team or ART self-manages the capacity constraint. The reason I say self-manage is because this no longer involves resource levelling or critical path techniques that any seasoned project manager would apply.
In Scaled Agile, it is just not about the team capacity, it is about the capacity of the Agile Release Train(s). At the team level, one way to determine the capacity to allocate stories in the sprint is by calculating the velocity – that is how many story points can a team deliver during an iteration. Simple way to calculate velocity is to take an average of the story points that were accepted in the previous 6 to 10 iterations/sprints.
The capacity is arrived based on the following:
In standard Scrum, each team’s velocity is independent of other teams. It is of no concern when one agile team has a velocity of 100 SP per iteration and another agile team has a velocity of 30 SP per iteration. However, in Scaled Agile Framework, when entire Agile Release Train(s) are involved in planning for the PI duration, it is important that the normalized story point estimation is use.
Need to consider focus factor for anything that cannot be planned like any unplanned time loss keeping in mind the daily time off, adhoc unplanned meetings, other official activities, training, Discussion with SME etc
How do we apply normalized story points for Agile Release Trains? Here is an example.
In a similar fashion, all agile teams in the train estimate the size of work.
Situation: The product management team of an ecommerce division has prioritized a list of Features/Capabilities that are potential candidates for the upcoming PI. Let us assume that the deliverables are not just the features, but there are some components as well that need to be developed to support those features.
The following table represents the capacity constraints for the features/components with the WSJF prioritization
|Feature||Front End||M/W Component||B/E Component||WSJF|
Assuming the Agile Release Train(s) capacity is 500 Story Points(where the focus factor, holidays, BAU activities are considered), let us look at what the ART can deliver for the PI based on the above table:
Total capacity for ART = 500 SP
Based on the above table considering the WSJF, the ART(s) can consider the following to be taken up for the PI.
Agile Release Train(s) always find it challenging when it comes to commitment based on the capacity constraints during every Program Increment, especially if the train(s) are involved in planning for the first time. However, irrespective of whether teams in the Agile Release Train(s) are composed of feature or component teams, if the capacity constraints are carefully evaluated and on loading the iterations accordingly as mentioned in this article, the teams can be confident of committing to the product management team on what work will be completed during the Program Increment.
Your email address will not be published. Required fields are marked *
As Mike Cohn puts it:“The Scrum product owner is... Read More
Who is the target audience for Certified Scrum Mas... Read More