SAFe Release Planning- Know Your Capacity Constraints

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.