Program Board

A key asset used in Agile-at-scale programs, the Program Board offers a visual summary of 1) what development teams have in their implementation pipeline during an upcoming sprint as well as 2) the cross-team dependencies that could impact their implementation and delivery. Its primary purpose is to encourage team collaboration and prevent bottlenecks.

The Program Board is a critical component of PI Planning. And per SAFe guidelines, a Program Increment (PI) is composed of five two-week sprints, where the second sprint is almost entirely dedicated to innovation and planning. This is one of the main reasons why a Program Board consists of six columns: one for each of the upcoming sprints, plus one additional column dedicated to items that will cross over into the next Program Increment.

The first row of the Program Board is used to highlight key milestones (events and deadlines) that can influence program planning and organization. Below this are individual rows dedicated to each team involved in some part of the program.

The goal here is to help all teams involved see the “big picture” at a quick glance. There are two primary benefits to this approach:

1. It helps identify potential cross-team dependencies impacting delivery.
2. It helps coordinate how teams implement their plans in relation to one another.

The Program Board is typically prepared by the Release Train Engineer (RTE)—in coordination with the Scrum Master for each of the development teams involved—before the PI Planning session and then completed during the session itself. To maintain cross-team synchronicity as much as possible between two PI Planning sessions, it is a best practice for RTEs and Scrum Masters to meet every two weeks to update the Program Board and immediately identify any potential deviations from the initial plan.

From an operational perspective, the identified dependencies between teams are highlighted by red sticky-notes along with red lines that connect them to the features or user stories that they are dependent upon. It’s worth noting that dependencies can come in the form of both features or user stories. This is because program managers typically operate at the feature level while development teams often manage their roadmaps at the user story level.

As a starting point, fill in the first row with all of the key milestones (events or deadlines) that can influence the roadmap. Then, add the relevant features to implement in each column—which, as you may remember from above, each of the columns 1-5 represents a two-week sprint, with the sixth column left blank for notes and other comments.

Also, don’t forget to leave the fifth column empty to ensure that the development teams set aside ample time to ideate, innovate, and begin planning for the next Program Increment.

Finally, it’s time to identify dependencies between features—in other words, the features whose implementation is directly dependent on the successful implementation of other features—by labeling them with red sticky-notes connected together by red lines.

You can also highlight “enablers” with sticky notes in a different color (i.e. work items that are not a feature but can nonetheless enable the project to move forward).