Aha! Develop | Best practices for SAFe® program increment planning
If your enterprise follows just one part of the Scaled Agile Framework (SAFe), that part is program increment (PI) planning. The two-day event is an intensely focused, carefully choreographed ceremony to plan out the next 8–12 weeks.
And though PI planning takes a significant amount of preparation and collaboration, there is a real magic to it. Everyone important to the increment is together — in the same room or online — and you can answer any question that might block your plans. From budgetary issues to architectural constraints and business context — in just two days, you have a chance to fold every insight into a PI plan that sets your team up for success.
Click any of the following links to skip ahead:
Prepare for PI planning
Make sure you have everything you need for a successful PI planning session — before the session starts. Two days (2.5 days for distributed PI Planning) is not long for such an ambitious task, but you rise to your level of preparation. Use your Aha! account to bring defined features and three levels of readiness to the first day of PI planning.
The primary inputs to PI planning are business context, a product roadmap, and the top 10 features on the program backlog. Let's begin with the features. If PI planning can start with work that product teams have defined at the capability and feature level, development teams can focus on breaking features into stories, mapping dependencies between planned work, and mitigating any conflicts.
Product teams own the program backlog — but the backlog is no black box. Both product and development teams can prepare for PI planning by assigning work directly to a program increment. Product teams can provide high-level features, while development teams can focus on enablers and nonfunctional requirements. In PI planning, everything will be broken down into stories and assigned to the appropriate sprints.
While business context and product vision might come from business and product stakeholders, you do not have to wait until the first day of PI planning to infuse your teams' work with strategic context. If you have integrated Aha! Develop with Aha! Roadmaps, then product teams can provide context in four ways:
Product roadmap: A roadmap is a visualization of the product or company strategy. It needs to both communicate and inspire — as well as track progress against the plan. Product teams in Aha! Roadmaps have a wealth of options, from a high-level portfolio roadmap down to the detail of a features roadmap. The product roadmap is the perfect visual aid for the business context and product/solution vision sessions of your PI planning agenda.
Work linked directly to strategic imperatives: These are the goals and initiatives (or in SAFe terminology, strategic themes and portfolio epics) that contribute directly to product vision and roll up to company-level strategy. Any record shared with your Aha! Develop account can include this information so you can see how each record impacts higher-level strategy.
Prioritization: Whether through WSJF or the product value scorecard, product teams in Aha! Roadmaps can standardize the metrics and weighting that contribute to an objective score of a record's value, contrasted against the cost to complete it. Any record shared with your Aha! Develop account can include this score so you can rank capabilities and features by business and product value — and use this context to help determine significant dependencies across an increment.
Capacity planning: Product teams can provide an initial estimate of the effort required to complete a feature. Development teams can provide a more detailed estimate. Those estimates compared to teams' historic velocity and individual team member sprint capacity suggest the amount of work each team should commit to in each sprint — and the amount you think you can safely complete by the end of the increment.
The introductory briefings — business, product/solution vision, and architecture vision — likely need several revision cycles before they are ready. How you hone each briefing is up to you. You can mine your Aha! account for visual aids and use presentations in Aha! Roadmaps for a presentation tool. Strategic models, advanced analytics, and roadmaps in your Aha! account are all tied to real data. You can choose whether they should reflect up-to-the-minute accuracy or a static point-in-time reflection of your plans.
Whether you choose an in-person or distributed PI planning session, make sure your Aha! account is configured for your team's success. For the purposes of this article, we will focus on program increment and program board configuration.
Organize teams into team lines
Use team lines to group multiple Aha! Develop teams together. You need to be an administrator with customization privileges to do this.
Navigate to Settings ⚙️ Account Customizations Teams. If you have already created multiple teams, this page will list all teams across your Aha! Develop account.
Click Add team line to create a new team line.
Name the team line. This team line is synonymous with your agile release train (ART).
Create the record Prefix that all records created in the team line should use (e.g. ENG, DEV, ART).
Select teams to group under this team line. Once you create a sprint cadence for a program increment, each of these teams will complete sprints in the same cadence.
You cannot add teams to a program increment once it has been created, but as a workaround, you can delete all sprints in a PI. Add new teams to the team line, then generate a new PI sprint cadence to include all teams.
Click Create team line to create your new team line.
Once you have created your team line, you can choose to Edit it and add team members directly to it. While any administrator in your Aha! account can access your team line, you may choose to have a subset of owners with access to the team line — but not account-level permissions. If so, add those users here.
Create program increments
Use the team hierarchy dropdown in the upper left of your screen to navigate to your new team line. This is where you will create program increments, define sprint cadence and monitor progress against your planned work.
From the team line settings (Settings ⚙️ Team line), configure settings that the child teams can inherit. Settings like consistent terminology, custom layouts, or custom record workflows orient each team toward their work in the same way.
Navigate to Plan Program increments and click Add program increments.
Name your program increment and add a Description if you choose. This is a good place to document your objectives for the PI.
Set the Date range for the PI. Sprints will be generated automatically to fill this range, at the Sprint cadence you select.
Select a Sprint cadence. Once you click Create sprints and confirm that the sprint schedule looks appropriate, sprints will be created in each child team at the same cadence, so every team has the same rhythm of work.
Click on the Related tab of your new program increment to see all work assigned to it. You may want to customize the default Aha! Develop terminology to match standard SAFe record types:
Aha! Develop terminology
Capability (for "Large solution" implementations)
Customize program increments
Because every team in the ART is aligned around it, the program increment is a key locus for business-critical information. You can customize a program increment to track this information.
Set the Progress calculation to Calculate from sprints. Sprint progress will now roll up to PI progress.
If you have integrated your Aha! Develop account with Aha! Roadmaps, link your PI to strategic Initiatives (Portfolio epics in SAFe terminology). This allows the product team to track initiative progress against PI progress so everyone contributing to a PI knows how their work contributes to product strategy.
Add a custom field to the PI custom layout. Custom fields can capture any information critical to PI planning, progress, and successful completion.
Click the More options button and Create a new custom layout for the program increment. Custom layouts organize fields on an Aha! record so you can highlight the most important information.
Customize the program board
Now that you have created and customized the program increment, navigate to Plan Program board. Customize it to meet the needs of your PI planning session. Consider how you want the board to appear before you introduce it during planning context.
The program board shows work added to the PI in the context of sprints (columns) and teams (rows).
Click on any team's chevron to Collapse or Expand it. Collapsed teams are not deleted, just hidden. Dependency lines to and from records on a collapsed team will be hidden as well.
Click the gear icon ⚙️ on the top filters bar. By default, the program board will Show dependency lines.
You can also customize the layout of the program board's record cards. The customizations you make will be unique to you and not impact other users in your team.
Click the gear icon ⚙️, then click Customize card layout to get started.
You can customize card layouts for Epics, Features, and Requirements. (In SAFe terminology, these are capabilities, features, and user stories.) Click the appropriate record type's tab to customize it.
Click the View buttons on the right to see how the card will display in an Expanded or Collapsed view.
For features and requirements, click the toggle to show or hide the record's Parent record on the card.
Then customize the card layout:
Select the fields you want to add to the card layout. If you have a lot of available fields, use the Search at the top of the tab to find the one you need. You can also collapse Standard fields or Custom fields to just see one type of field.
Drag and drop fields onto a card to add them. Click the X beside a field to remove it.
You can drop fields next to others on the same row or beneath the bottom row of fields to create a new row on the layout.
If you have enabled risk indicators in your Aha! account, you may want to add them to cards on the program board. This will allow you to manually flag records as at-risk during PI planning and discuss them during the program risks session.
Click Reset to default to revert your changes to the default layout, Cancel to exit the modal, or Save to save your work.
Share vision and set context
Before teams break out to plan the increment, they need to know the business context, product vision, and architectural limitations. The throughline in each of these sessions is accuracy and motivation. Teams need to know why the increment matters so they are inspired to commit to ambitious achievable work.
Thanks to your organizational and content readiness, the business, product, and technical stakeholders leading these sessions should be well prepared with Aha! views, live roadmaps, and technical documentation.
Just before lunch on the first day, the release train engineer (RTE) leads a planning context session to explain the planning process and expected outcomes for the event. This is the perfect time to introduce the teams to the program board.
Navigate to Plan Program board.
Orient the teams to the board — sprints in the columns, teams in the rows.
Expand the sidebar on the left side of the program board. This sidebar, labeled Program increments, contains all work assigned to a program increment but not yet on the program board. During the team breakouts, teams will pull work from the sidebar onto the program board and add dependencies with other work cross-sprint or cross-team.
Explain the filters at the top of the program board. Teams can filter the board for just their own team if they choose.
Explain dependency lines between records on the program board. In Aha! Develop, dependencies will turn red if they are out of order.
Open an example record on the program board.
Walk through the Overview tab and any custom fields you have added to the custom layout.
Click into the Requirements tab (in SAFe terminology, this is the User stories tab) and explain how to break a feature into individual user stories.
Provide any planning context that does not involve your Aha! account. Then each team can break off into separate group sessions (after, perhaps, a refreshing lunch break).
Manage team breakouts
Individual teams will now draft their plans, including risks and dependencies. Based on your guidance during the planning context, they should have everything they need. Let's review the key functionality they will use to plan their portion of the PI.
First, they need to plan their capacity — the amount of work they can commit to each sprint and across the entire PI.
Aha! Develop tracks historical velocity at the individual and team levels. Teams should enable sprint capacity planning in their team settings (Settings ⚙️ Team Capacity planning).
In the team line ([Team line] Plan Program increments), the program increment will calculate its capacity from the individual sprint capacity.
You can also set the PI to calculate its progress from Sprints or Sprints completed as well.
Next, they are ready to manage their part of the program board ([Team line] Plan Program board):
Filter the program board: Teams can filter the program board for their specific Team or for particular Workspaces, Releases, or Types of work.
Assign work to sprints: Click and drag any record into a particular sprint and team to assign and schedule it. If you drag the record to a different sprint or a different team, the assignment or sprint schedule will update automatically.
Break down work
Record descriptions should follow INVEST to be clear, feasible, and testable — everything a team needs to break down a record into its constituent requirements (a feature, for example, into user stories). Click on an individual capability, feature, or requirement to open its drawer view.
For epics (SAFe capabilities), go to the Related tab to add features.
For features, go to the Requirements tab to add requirements (SAFe user stories).
You may have renamed Requirements to User stories.
There are three capacity planning fields that come standard on Aha! records:
Initial estimate is usually configured by product teams when they are first prioritizing a record.
Detailed estimate is usually configured by development teams based on their expert assessment of a record's difficulty to implement. Product managers in Aha! Roadmaps can compare Initial and Detailed estimates.
Actual effort is used by development teams to log effort against the Detailed estimate (or Initial estimate if Detailed was left blank).
Individual sprint capacity planning uses Detailed estimates and Actual effort to calculate capacity. If you have enabled that setting for your team, make sure to track those two fields.
If you are working closely with a product team in Aha! Roadmaps, make sure you are both using the same Estimation units — Time or Story points. Then start estimating! You can use any number of methods to estimate work (including the planning poker extension). The end result is a Detailed estimate that will be used to visualize individual and team capacity in both Aha! Roadmaps and Aha! Develop.
Parent records — such as epics (SAFe capabilities) and features — can calculate their estimates from the estimates of their child records — such as features and requirements (SAFe user stories).
Teams need to visualize dependencies across work — and across other teams in the value stream — as they schedule items and identify risks. While most thread-and-paper program boards use a red thread to symbolize dependencies, the dependency line color changes in Aha! Develop.
Grey indicates a feasible dependency. Based on the current schedule, nothing will block the dependent record during its scheduled sprint.
Red indicates a problematic dependency. The dependent record is scheduled before the record(s) it depends on.
Red dependency lines give teams a visual cue that their draft plans need adjustment. There are two ways to create dependencies between records:
From the program board: Right-click on any record card. Click Link to another record. This method is useful if a team is reviewing their PI plan as a whole and notices a missing dependency.
From the record itself: Click on the Related tab, then click + Add. This method is useful if a team is breaking down a feature into requirements (SAFe user stories) and notices a dependency with another feature.
Note: Remember to select Depends on or Is a dependency of as the dependency type.
Flag at-risk items
You can use Aha! Develop to automatically flag records as at-risk. But during PI planning, it is more likely that teams will want to manually flag records. They can report on these risks during the draft plans presentation. Management can use flagged records in aggregate to discuss PI planning risks during their evening session. If any risks cannot be addressed before the final plan review, they can be formally ROAMed during the program risks session.
To do this, the teams should:
Make sure they have added the Delivery risks field to custom layouts.
Right-click on a record card in the program board and select Flag as at risk.
Select multiple records with CMD+click / CTRL+click.
(Optional) Open the record and Add comment in the Delivery risks field to explain why they flagged the record.
You can customize record cards on your program board to indicate whether a record has been manually flagged and report on manual flags and comments. If a risk has been resolved, open the record and click Remove flag beside the manual flag.
Remove flag will also delete any comment on the manual record flag.
Scrum of scrums
During team breakouts, all scrum masters of every team in the ART meet with the RTE to review progress and mitigate potential roadblocks. The meeting is timeboxed to an hour and includes a standard set of questions:
Have you identified the capacity for each iteration in the PI?
Have you identified most of the stories for the first two iterations and begun estimating?
Have you begun resolving dependencies with other teams?
Are you discussing trade-offs and conflicting priorities with business owners?
Have you identified program risks?
Will you be ready to start writing PI objectives in the next 15 minutes?
Is there anything you need to discuss with other scrum masters? If so, stay for the meet-after.
Some of these questions can be answered from memory or with the aid of a few notes. Others could benefit significantly from a visual aid. In a pen-and-paper PI planning scrum of scrums, it would not be feasible to show a work-in-progress program board. But multiple people can access the Aha! Develop program board simultaneously. This means that teams can keep working while their scrum masters reference the board during the scrum of scrums.
Individual users can apply their own filters to the program board without affecting other users. Multiple users can even edit the program board at the same time. This keeps the program board contextual for each audience and ensures that work can move forward collaboratively.
Teams present their plans to the larger ART twice during PI planning — on day 1 as drafts and on day 2 as final drafts, just before program risks. The program board creates a shared context around each team's plan. Teams can customize it mid-presentation to highlight different insights:
Filter the program board by Team (or collapse other teams) to focus on one team's planned work.
Use a record's Dependency map to highlight a significant dependency. To do this, open a record, click the Related tab, and click Visualize in the Linked records section.
If teams see too many dependencies in their plan, it is a good opportunity for further conversation. While it is always good to document known dependencies, too much "red thread" on the program board may indicate a value stream network that is not well configured. This may be something for management to address during their management review and problem-solving session.
In addition to scoping work and tracking dependencies, the ART spends a significant time during PI planning cataloging and addressing risks. Any risk the ART can plan against here saves the trouble later when the PI is actually in progress.
Remember, anyone can flag an individual record as at-risk and comment on why it might miss its planned delivery date.
Teams, scrum masters, and management can review a report of manually flagged records.
Aha! Develop includes a ROAM board as a whiteboard template. Use it to collect program risks throughout PI Planning, then ROAM each risk during the program risks session. Anyone with access to the whiteboard can add a risk they have noticed — or vote on a documented risk to emphasize it.
Complete planning retrospective
The last step in PI planning is a retrospective. At this point, everyone in the ART is likely excited about the plans they have created — but tired after two days of intensive work. The retrospective is a critical last step before moving forward, so it is important to structure it correctly.
Do not wait until the planning retrospective and moving forward session begins to start collecting feedback. Aha! Develop includes a PI planning retrospective board as a whiteboard template. Create it early and invite everyone to contribute to it as soon as they notice something that did or did not go well. As with the ROAM board, people can vote on each retrospective item.
During the actual retrospective, you can review the observations, tally votes, and discuss action plans. Then congratulate the ART! You have all accomplished something wonderful together.
Track ongoing PI progress
PI planning is over and the program board is now a centralized authority on your plans for the increment. You do not need to transfer your PI plans to a development tool or update the program board manually. As teams complete records on your board, you can track their progress in real time.
Save your view of the program board to share it with stakeholders in your Aha! account. Anyone who accesses your saved link will see the filtered view of the board you configured.
Open any record on the board to see more details or comment on the record with questions or observations.
Adjust your plans as needed to keep the PI on track. Add or remove dependencies, flag at-risk work, or adjust the scope.
You can also chart, analyze, and visualize critical dependencies using Aha! reports and roadmaps. Use the [Record type] record links and Linked [record type] tables to visualize and analyze linked records.
PI planning started your increment with an ambitious, nuanced plan. The program board is key to keeping everyone in the ART on track throughout the increment. When the next PI planning comes around, you will be ready for the next set of challenges.
Aha! is a trademark of Aha! Labs Inc. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. All other company and product names may be trademarks of the respective companies with which they are associated.