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.
Know more about safe core values.
Release Planning – Agile Team:
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.
Program Increment in SAFe
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.,
Why PI Planning?
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).
PI Planning Meeting
Image Source
Let us look briefly at the sequence of activities that are involved in the 2-day Program Increment event.
- Pre-work:
- Epics broken down into Features
- Value (outcome) identified for each feature, analysed and prioritized (example using WSJF)
- Approximately top 10 features identified for the upcoming PI
- Day 1 Agenda:
- Business context set by the business owner
- Product solution goals set by the product management team
- Technical/Development goals set by the technical architect team
- RTE setting the Planning context and agenda
- Teams breakout to break the features into stories, estimate (story point sizing), determine capacity and load for each iteration, identify risks and dependencies within & across ART(s) and submit draft plan for review
- Management review and problem solving
- Day 2 Agenda:
- Based on the management meeting outcome on day 1, any changes required are discussed.
- Teams breakout to make any modifications in the scope and replan. Teams bring the PI objectives to the program board.
- Business owners assign business value against the PI objective(s).
- Final plan is reviewed.
- Program risks and dependencies are updated in the program board. Teams discuss and decide on the ROAM (Resolved, Owned, Accepted and Mitigated) to see if they can overcome the risk.
- Confidence vote is taken with respect to the overall planning and commitment.
- Retrospective is held with respect to the entire PI planning event and any improvement items is taken up for the next PI planning event. This is facilitated and owned by Release Train Engineer (RTE).
Principles of Program Increment
- Why, What and How?
- Requirements are rather discovered with the entire Agile Release Train(s) or ARTs that includes the development teams, Product Owners and other stakeholders collaborating on “why” the product/solution is being built.
- The teams get to know the customer needs better and decide on “what” needs to be built by prioritization. Cross teams within an ART and cross ART dependencies are discussed.
- Architectural runway - which is the existing code, components and technical infrastructure needed to implement the near-term features without excessive redesign – paves the way for the ART development teams to discuss alternatives, risks and any unknowns to create a view of “How” the increment will be addressed.
- There are multiple time-boxed activities within this two-day event that allow the teams in the ART(s) to breakout and have a focussed interaction. This approach fosters focus on just enough detail and allows the “spacing effect” and time for reflection
- The central principle of release planning is the capacity constraint. We will discuss this in the next section.
Become a project management expert with best PMP courses. Elevate your career and confidently lead successful projects.
Knowing your capacity constraints during Program Increment Planning
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: - Normalizing Story Point estimation across the Agile Release Train
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.
- Feature capacity
- Component capacity
- Other BAU activities the team may need to perform
- Focus Factor
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, SAFe training, Discussion with SME , etc
Situation with example
How do we apply normalized story points for Agile Release Trains? Here is an example.
- Assume a two-week sprint has 10 days.
- For every full-time person on the team allocate 8 Story Points. (Adjust for part-time). Exclude the Product Owner and Scrum Master.
- The 8 points is derived from 1 point per day, for 10 days in a 2-week sprint, at 80% capacity
- Subtract one point for every team member vacation day, public holiday, training day etc.
- Find a small story and give 1 story point to it.
- Estimate every other story relative to that one.
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 |
|---|
| Feature 1 | 70 | 20 | 10 | 19.0 |
| Feature 2 | 60 | 10 | 0 | 12.0 |
| Feature 3 | 75 | 15 | 5 | 6.8 |
| Feature 4 | 65 | 0 | 10 | 15 |
| Feature 5 | 90 | 0 | 5 | 11.5 |
| Feature 6 | 120 | 10 | 0 | 8 |
| Feature 7 | 190 | 0 | 5 | 7 |
| Arch 1 | 0 | 25 | 25 | 10 |
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.
- Feature 1 = 100 SP
- Feature 4 = 75 SP
- Feature 2 = 70 SP
- Feature 5 = 95 SP
- Arch 1 = 50 SP
- Feature 6 = 120 SP
Conclusion
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.
