Program Board - Executing The PI

In a recent training course that my colleague and co-trainer Keith DeMendonca was running he was asked about documentation on how the Program Board within SAFe works, after a brief search the answer turned out to be that there’s very little information on what it’s for, how to set it up and how it is utilized both in PI Planning and beyond. Even the Scaled Agile material itself just shows a picture of the Program Board with a couple of lines of description of what it is; but no more detail than that. The training material has a few slides scattered between the various courses but is similarly scarce.

Keith and I talk about the program board extensively in the trainings that we do together, so it’s not as if there isn’t a body of knowledge and experience out there about how to utilize the Program Board, it’s just that nobody appears to have written it down. These articles aim to rectify that and provide a permanent record for future reference.

Previous blogs looked at the setup of the Program Board and how Teams utilise it during PI Planning, this blog will look at how the Program Board is used during PI Execution.

Use During Execution of the PI


Every few days during the execution of the Program Increment the Scrum Masters from the teams gather together to maintain alignment between the teams at a Scrum-of-Scrums. Which teams need to collaborate between now and the next Scrum-of-Scrums? Are there any issues that need to be raised that impact the Agile Release Train?

The best place to conduct these discussions is in front of the Program Board which can be used to facilitate the discussions: “Team A, Team B the board shows you are collaborating, is it happening?” The teams are accountable for the actual collaboration and the detail of the collaboration, the central point is checking that they are honouring the commitments they made to each other at PI Planning. Decentralise, but close the accountability loop.

Adjustments to the plan are issues that impact the Agile Release Train as a whole, these can be raised at the Scrum-of-Scrums but dealing with the impacts of the adjustments is handled in discussions outside of the Scrum-of-scrums. Treat Scrum-of-Scrums as a planning event, once you’ve identified that a bigger discussion is needed plan for that discussion in the scrum-of-scrums, don’t get sucked into big discussions in the Scrum-of-Scrums.

Visualising progress

The Program Board can be used to visualise progress through the Program Increment and it provides a different perspective on progress compared to visualising Features on the Program Kanban or tracking Objective completion. It allows the Agile Release Train to see at any given point within the Program Increment which Team should be working on which Features and it can be augmented with live information from execution to help visualise what’s actually happening.

Visualising Progress

Figure 1: Visualising Progress

There are many ways of visualising progress; our preference is that as a team starts to work on a ticket a line is drawn diagonally across the bottom left corner of the ticket to indicate that it is in Progress. One the work represented by the ticket has been completed a second line is drawn diagonally up through the ticket to create a tick to indicate that it has been done.

Evolution Of The Plan

Figure 2: Evolution Of The Plan

The plan will change, those changes can be reflected on the Program Board. However, be careful not to destroy the baseline, otherwise it becomes difficult to measure how much change has occured. Our preference would be to annotate the Program Board to indicate the changes. If the completion date of a piece of work is changing then the team responsible can draw an arrow to the revised completion date. The team, in collaboration with the other teams in the Agile Release Train can then assess the impact. Trace through the collaboration strings, are any other teams going to be impacted and need to make adjustments.

The adjustments must come from the teams, not be imposed upon the teams. Those adjustments may well involve discussion between teams; the central point, the Scrum-of-Scrums, identifies that adjustment is needed but the detail of the adjustment is decentralised out to the teams involved.

Managing Change

Inevitably at some point during the 10 to 12 weeks of Program Increment someone is going to want to try and introduce new work. Teams tend to leave a little bit of slack in the plan to accommodate revisions to estimates and changes to the plan, if the new work is small then it might be able to consume some of the slack in the plan. If the new work is bigger than the slack can accommodate then the change will need to be managed properly.

  1. “Is the new work more important than the work already on the Program Board?”
    No : then it goes onto the backlog and through the WSJF prioritisation it will get into PI Planning at an appropriate time.
    Yes : then in order to get something in you need to take something out, this is a fixed capacity machine.

  2. “What do you want to remove?”
    The stakeholder that wants to introduce the new work will most likely suggest another stakeholder’s piece of work rather than their own, so this question can’t really be answered in isolation it needs to be asked to the set of stakeholders as a whole. You can also check with the group that “Is the new work more important than the work already on the Program Board?” rather than just rely on the word of the stakeholder that want’s the new work.

  3. The work removed has to be of equivalent effort to the new work, so the new work will need an estimate from the engineering staff, the System Architect usually arranges this.
    The annotations made to the Program Board help with deciding the work to remove. If a piece of work has a cross through it it’s complete, the effort has been expended and the value delivered. If a piece of work has a line through it then the work is In-Progress, it could be removed but it won’t be possible to recover the whole effort involved and the effort that has been expended may potentially become waste. If a piece of work doesn’t have a line through it then it hasn’t been started and the whole effort is available. Check back through the collaboration strings, any collaborations that have been started and completed could become potential waste, anything collaborations that haven’t been started can be removed if they are no longer needed.

  4. The teams will need to create a new objective for the incoming work. The stakeholders/business owners will need to score that objective. The new objective would be categorised as uncommitted since they didn’t commit to it at PI Planning, that doesn’t imply that it’s optional it’s just that they didn’t commit to it at planning because it didn’t exist at planning. The objective for the removed work will most likely score 0 when assessed at the end but score for the new objective will counteract this so a team can still be highly predictable in meeting their objectives even when the plan is changing.

Final Words

Utilised correctly, the Program Board is a key tool for visualising the interactions between the teams and anticipated value delivery, but for that to happen it has to be created by the teams through negotiation. Through this series of blogs I’ve tried to practical aspects of how the Program Board is created and to have highlighted the behaviours that contribute to it beem a useful tool for the benefit of the Teams within the Agile Release Train.

A Centralised Tool for Coordinating Decentralisation

Henrik Knieberg

My thanks to Keith De Mendonca for observing the gap in the published material in the first place, and for reviewing the blogs. I also need to acknowledge my colleagues at IJI and our clients who, over the years, have provided a rich pool of examples to draw upon as illustration.


More Great Agile Content from Ivar Jacobson International:


Contact Us