Tips for using a SAFe program board

The Scaled Agile Framework® (SAFe) is a set of procedures and practices that large organizations use to scale Agile methodologies across the enterprise. SAFe is designed to unify multiple cross-functional groups for better collaboration, increased flexibility, and aligning project strategies and goals.

Program Increment (PI) planning sessions are important SAFe events that bring diverse teams together to work toward the same goal. And the SAFe program board is one of the key outputs that come from the PI planning sessions.

Learn more about how a SAFe program board works and how you can use one effectively.

What is a SAFe program board?

The SAFe program board is a living, visual document that teams can manage and update as work in the PI moves forward. Specifically, the board lets team members visualize:

• What features, dependencies, and milestones are planned for the current PI
• What is being/needs to be worked on
• Who (which team) is responsible for completing specific work
• When the work will be completed

Traditionally, program boards have been physical boards mounted to a wall. Teams place a series of color-coded sticky notes to represent features, dependencies, and milestones. Red string is used to connect dependencies to features and milestones. 

A physical board can work well for smaller companies where it is easier to get everybody in the same room for PI planning. However, there are digital solutions available for creating and managing program boards, so these program boards can be shared and easily accessed by all participating teams, no matter where team members are physically located. 

Digital program boards work better for large enterprises or dispersed teams who cannot get all team members together in the same room. Even smaller teams may want to go digital in order to keep a better record of their PI planning sessions.

What is the purpose of a program board?

The program board helps large companies with globally distributed teams within the Agile Release Train (ART) to visualize, track, and manage features and dependencies.

The purpose of the SAFe program board is to streamline the coordination of the work that needs to be done across multiple teams. It’s a single source of truth that keeps everybody focused on what needs to be done to successfully complete the PI.

What is found on a SAFe program board?

Because the program board is a high-level visual overview, it usually does not include a lot of details. Instead, the layout and organization should let you quickly and easily see the answers to following questions:

• What work is being done?
• Who is doing the work?
• When will the work be done?

The program board’s layout should not be overly complex. What you typically will find on a program board is:

• Columns: Add columns to represent each iteration planned for the PI. You can add an extra column to the right of the board to hold items to be moved to the next PI.
• Rows: Include a row with a label representing every participating team. The top row is for milestones and events and does not have a team name attached to it.
• Sticky notes: Color-coded sticky notes are placed in the columns and rows to represent events and milestones, features, and dependencies. 
• Connectors: On a physical board, string or yarn is used to connect dependencies to features and milestones. On a digital program board, lines are drawn to make the connections.

How to set up your SAFe program board

Teams set up the SAFe program board during the scheduled PI planning breakout sessions. In the breakout sessions, teams discuss and define the features, dependencies, and milestones that should be included in the PI.

After you have set up your columns and rows, you can start populating your program board with the work you hope to accomplish in the PI. Here are a few tips to help you put together your SAFe program board.

1. Start with the features

Teams determine which features will be included in the PI based on business context and a shared mission. The teams place a sticky note on the board to represent each feature. The sticky note’s placement indicates which team will work on it and when it is expected to be completed.

2. Look for dependencies

Teams look at the features and determine where they might have some dependencies. Dependencies are represented by a sticky note on the board with a connector between the feature and the dependency.

For example, Team A discovers that they can’t develop a feature to be completed in Iteration 1.3 until Team C has developed an API. So Team A simply needs to place a dependency on Iteration 1.2 in Team C’s row, right? 

Wrong.

Team A does not know Team C’s workload and should not be able to dictate when their work should be completed. Instead, the two teams need to talk with each other to find a solution that works for everybody. This is why the PI planning meetings often happen face-to-face (or at least over a video call)—you want open communication and collaboration among all teams.

After both teams reach an agreement, they place a dependency on the board to ensure that both teams are clear on the acceptance of the dependency and agree on when it will be resolved.

3. Set milestones or events

A milestone is a visual indicator of progress made toward a specific goal, such as making a drop to another team or a client, having specific features ready to demo at a trade show, or completing the final product release.

Milestones have dependencies on different sets of features that need to be completed before the milestone is met. Sticky notes representing milestones are placed in the top row in the column for the iteration when it is expected to be met.

Tips for streamlining the process

Now you’ve got the basic steps down—but meeting with your team to collaborate and put the SAFe program board together isn’t always as easy as 1, 2, 3. Try these tips to simplify that process.

Color-code your sticky notes

Use a color-coded scheme with your sticky notes so that team members can instantly identify features, dependencies, and milestones. There is not a set standard of colors that should be assigned to specific elements. Many companies use red for dependencies, blue for features, yellow for milestones, and red string (or red curved lines) for the connectors.

The colors you choose do not matter as long as the entire enterprise adopts these same colors. The consistency will keep teams from wasting time explaining what the colors mean to them.

Don’t forget shared services

Shared services teams such as UX, architecture, and security, provide service for many different teams who are not necessarily participating in your PI. Make sure shared services teams know about the work they need to do, have the capacity to do the work, and can complete the work for a specified iteration.

Keep it simple

You want the program board to be easy to read and understand. A messy board with multiple connectors crisscrossing each other and long dependency chains can be hard to read.

For example, if there are too many dependencies associated with a feature, you may not be ready to address that feature in this PI. Or if you find a dependency that is scheduled to be resolved after the feature that depends on it is completed, you might have a problem.

These types of issues can be escalated to the management review meeting at the end of the first day of the PI planning sessions. The management team will discuss the problem and ask questions like: 

• How important that feature is to this PI? 
• Can we move it to the next PI? Will delaying it give teams enough time to resolve the dependencies?
• Can the dependencies be distributed to other teams who have the capacity to work on them for this iteration?
• Does the feature need to be scrapped completely?  

The management team will make a decision so that you can move forward with the project. 

Should your SAFe program board be analog or digital?

You may be able to successfully complete a PI using an analog program board, but you will have to jump through a lot of hoops to do it.

Physical boards, like a whiteboard in a conference room, are not portable. What happens to the board when the PI planning sessions are over? You can take a picture of the board and email it to everybody, but what happens when the board needs to be updated?

Digital program boards have many advantages over analog boards because:

• They are portable and easy to reference later during the PI.
• They scale easily to accommodate any number of teams participating in the PI.
• They can be stored in and shared from a centralized location, allowing 24/7 access no matter where your teams are located.
• They encourage collaboration as teams manage and update the board in virtual face-to-face meetings.
• They can be created in platforms like Lucidchart that seamlessly integrate with tools you are already using (such as Jira).
• They allow you to include more details as metadata. Lucidchart lets you link detailed data stored in other documents to the board. When that data is updated in the source, it is automatically updated in the visual program board as well.

A lot of planning and work goes into creating and managing SAFe program boards. The information they give you is valuable and keeps teams aligned and focused. After taking the time to create the board, don’t let your teams ignore or forget about it. Refer to the board often to ensure a successful PI.