In planning events, the Program Board is intended to be an information radiator for the timing, dependencies, and risks in the program. It shows complexity around dependencies, risks to meeting milestones, teams who have too much on their plate, and dependencies that have not been accepted and committed to yet.

Challenges

The Program Board is the heart of any program increment planning event. Planning events are one of the great practices of SAFe®. However, creating the Program Board manually, as is typically done, has several challenges. Here are the greatest challenges we see.

• Challenge 1: Physical boards are not very effective when some teams are remote. The idea of the Program Board is to create visibility for the entire ART. But not having everyone in the room limits its value.
• Challenge 2: Creating a physical Program Board creates a bottle neck and detracts from the essence of the planning event. Once a planning event gets underway many people come up to the front of the room and get in each other’s way. Those wanting to add strings interfere with each other as well as making the information harder to see. Creating and maintaining the board becomes a significant burden that slows down and detracts from the essential aspects of the event.
• Challenge 3: Structural changes to physical boards can be prohibitively difficult during the planning event. Teams will often find it desirable to split into sub-teams and want to have their PBIs split across two rows. A physical board makes this prohibitively expensive.
• Challenge 4: You can’t see the forest for the trees. So much information ends up on the board that you can’t really see the details you need.
• Challenge 5: Teams have to chose between duplication of effort or not really seeing real time dependencies at the team level. If teams put their dependencies on the board and not keep them at their own table they don’t have real time dependency information while doing their planning. If they track the dependencies in both places they are not only wasting time with the duplication of effort, but run the risk of the dependencies at the team boards and Program Board being out of sync.
• Challenge 6: Teams that are constraints to other teams have a difficult time deferring commitment. Ideally, constraining teams (such as shared services and DevOps) would like to defer commitment until they can see what the overall demand for their services are. But in practice, they will make commitments on a first-come, first served basis and only make adjustments when critical.
• Challenge 7: Physical Program Boards are hard to move and maintain after the planning event. And finally, after planning is done, the Program Board should continue functioning as an information radiator by representing the latest known information on timing, dependencies, and risks to the program. With a physical board, however, moving it and keeping it updated after initial creating is extremely cumbersome, if not entirely time-prohibitive.

The bottom line is that while building a Program Board takes time and adds to the frenzy of the event, that is not the only problem. It prevents many good practices that would be alleviated with an automated board.

The Net Objectives Program Board Builder

The Net Objectives Program Board Builder removes all of these challenges and the constraints imposed by these challenges, allowing groups to focus on creating, updating, and responding to the plan quickly and efficiently, both during and after the planning event.

This page describes both why and how to use the Program Board Builder to help run effective planning events. The Program Board Builder has the overall purpose of improving the program increment planning event. It does this by both building the Program Board with little effort as well as by enabling things not possible without the tool.

• Benefits of the tool
• Using the Program Board Builder
• Using the Board to see only one team’s work
• Using the Program Board Builder in a Planning Event
• Running a Lean Planning Event
• Benefits of using the Program Board Builder
  • The Program Board Builder automates what is now done manually
  • The Program Board Builder enables new capabilities
  • Running remote or semi-remote Planning Events

Benefits of the tool

These benefits are described in more detail after explaining how the tool works. This overview is completed to give a sense of the value of the tool.

• Reduces cost of building the Program Board, especially moving stickies and strings after they have been put on the board
• Use of different line styles enables people to actually see dependencies clearly, not just a bunch of crisscrossing yarn
• Tracks dependencies uncovered but not committed to. This ensures a conversation takes place to get to committed dates, improving collaboration between teams while making the plan more robust
• Improves collaboration and dependency management with increased clarity
• Enables remote events by allowing remote participants to help build the board collaboratively.
• Intelligently filters PBIs so a team can see just their PBIs and the PBIs that they are collaborating on
• Enables deferring commitments of a team that has insufficient capacity until they have sufficient information to make them, with virtually no cost to rearrange the board.

The tool effectively turns the Program Board from being merely an output to being a tool that improves the quality of the event itself. Consider this, what is the cost of a Program Board where it is not easy to see the dependencies as a whole?

Using the Program Board Builder

The Program Board Builder is as simple to use as entering information into a spreadsheet. In fact, that’s all you do (a Jira and VSTS integration module is in the works). The board operates on a CSV file that is generated from a shared document such as an Excel Sheet or a Google sheet. Read more about how to run the Program Board Builder.

We will run through using the board in the following example. Figure 2 shows the board after a single entry. In this case, MBI “M6” (rightmost column) is dependent upon story “S17” (“Mocking Birds Sprint 3). The red borders indicate that the dependency has been noted but not committed to.

Showing agreements

The bold border indicates that we do not have a commitment from the team building the dependency for the date. For example, the Finches team may have just told the Sparrows team that they need S1 by the third sprint, but until Finches agrees to complete it in a specific sprint, it should remain uncommitted, allowing us to easily track this for resolution and to highlight plan risks. However, in the event that Sparrows are not able to commit to completing it by sprint three, negotiation should ensue to resolve priority conflicts as necessary. Once negotiations have been completed, this should be entered into the input sheet and the red borders are removed, indicating a commitment to the dependency as shown:

Completing the board

Continue this process, entering stories and dependencies and making agreements, until you create the finished board such as shown in Figure 4.

Using the board to see only one team’s work

A challenge with the Program Board is that it captures so much information. While an overall sense of how interconnected PBIs are, there are usually so many strings present that it is difficult for any team to see what they need to manage their dependencies and what depends on them.

A team wants to see their own PBIs and any PBI they are dependent upon and what those dependent PBIs are dependent upon. A team also wants to see what is depending upon them and any teams they may to work with to meet that dependency. For example, if you were on the “Crows” team, here is what you want to see. you want to see the following PBIs:

• All PBIs on the “Crows'” row
• All PBIs the “Crows” depend on and PBIs that they depend on all the way down the line
• All PBIs dependent upon the “Crows” all the way to the end so that the “Crows” can see the value they are working towards
• Any PBIs that are also needed by any PBI depending on the “Crows.” These are shown in case the “Crows” need to coordinate with them when meeting their commitment (S8 in the example below).

When run with the “Crows” filter on, the display will look like that shown in Figure 5.

Using the Program Board Builder in a Planning Event

Using the tool in a planning event can be done one of two ways. If you want to emulate the planning board being built at the front of the room simply have a computer there that people come up to and enter onto the sheet instead of putting things on the board. This computer can display the board with a projector after each entry. However, with shared files, it’s usually preferable for each team to have its own computer in addition to the “room” machine displaying the board. In this case, a person from one team would go to the other team, have a discussion and then update the PBIs involved on one of the teams’ machines. The “room” computer would then just update the display based on this new information.

Running a Lean Planning Event

In any organization big enough to use SAFe there will almost certainly be some teams that will represent bottlenecks to development. A key tenet of Lean is to defer commitment until you have sufficient information to make a good decision. The challenge in planning events is that teams often make commitments to other teams when they have only received some of the requests they are going to get. While it is possible to change a manual board, the expense of doing so often precludes it from happening.

It is suggested that the tool be used to discover all dependencies and put them into the tool without commitment on the first day. Then, once most (more dependencies will certainly be found) dependencies are known teams can make promises with the big picture in mind.

Benefits of using the Program Board Builder

Some of the benefits of the Program Board Builder are simply speeding up building the board. This allows for teams to focus on their work and improve collaboration. But when automation is available, other benefits arise that would be too costly if done manually.

The Program Board Builder automates what is now done manually

The Program Board Builder facilitates activities program increment planning events require. Here are some of the important activities it facilitates.

• Faster and easier building of the Program Board. It takes just a few seconds to “put up a string.”
• Ease of changing any dependency strings. Moving a string simply involves moving the name of the PBI on the spreadsheet.
• Clarity on what is connected to what. By using different colors and dash types, seeing what is connected to what is much easier.
• Team release dates. SAFe works with the model “develop on cadence, release on demand.” When a team can release something on their own, it’s good to mark this. While this may not be part of the standard program increment planning event you don’t need a tool to put a star on the board.

Note that these last two are not discussed in SAFe documentation but can easily be done without the tool. If a team is dependent upon another team and that team has not agreed to the date, the stickies for those PBIs should not go on the board. But sometimes they do anyway. In this case, mark both stickies as “tentative” when putting them on the board. Marking release dates by individual teams (when they occur) can be done by easily have a special sticky that indicates when the release will occur.

The Program Board Builder enables new capabilities

The Program Board Builder creates and manages new information and opportunities. Here are some of the new capabilities.

• Running remote or semi-remote planning events. One great thing about planning events are that they greatly contribute to collaboration and people getting face-to-face time. But getting everyone together is often difficult and/or expensive. By having an easy way to build a Program Board, it is possible to run a program increment planning event without everyone being together. While getting people together should still be the goal, the Program Board Builder offers an alternative when the realities of budgets have to be attended to.
• Seeing only those PBIs that affect a particular team: their PBIs plus any items upon which they depend. The Program Board sometimes hides the forest because of the trees. It is so busy that a team cannot get a good view at all its dependencies and who is depending upon them. A filter allows for a team to see only those PBIs in which it is involved in, directly or indirectly.
• If a team needs to make a change to a commitment they can easily see who they have committed to at their own table. Imagine you are a team that needs to re-negotiate a commitment with other teams because a story has to be moved. If each team hasn’t been tracking what
• Automatic indication of dependencies where dates have not been committed to. Although nothing is supposed to be put on board without agreement from both teams, we all know that, “In theory, theory and practice are the same. But in practice, they are different.” In any event, sometimes teams commit to something only to later discover that they should not have committed to the date they committed to.
• Making it easy to see when there is a suspiciously long cycle time. On a manually created board, it is very difficult to see long strings as everything blends together. The clarity of the board built by the Program Board Builder enables easily seeing long times between a dependency being completed and when the item depending upon it is completed. This long cycle time is not necessarily a bad thing but should be investigated.
• Deferring commitments until the appropriate time. Teams that have more requests than they will be able to fulfill (such as shared services) should make decisions on when to commit to items only after seeing a certain amount of the big picture. Making commitments in the order in which they are requested is not an effective method. Unfortunately, with manually built boards it is the only practical method because changing the board is time-consuming. By being able to change the board easily, teams that are known to be bottlenecks can defer making commitments until they have more information. This enables them to service those teams that are more important.
• Enabling splitting or merging swim lanes. This sometimes happens as we see how teams are going to work with each other.
• Adding another column to the board. This is as very easy to do to the input sheet, but would be very difficult once the planning event has started with a manual board.

It is usually desirable to have participants in the same room; however, this is often not possible. Very often, Planning Events require participants from remote locations. Giving these people situational awareness of the board goes a long way to making them feel like they are involved.

As shown in Figure 6, the Program Board Builder allows remote workers to interact with the Planning Board in real time. While is it possible to not even have representatives of the team at the event, it is highly recommended that someone from the team is physically in the room during the planning event. This at least partially offsets the loss of collaboration from the event now being partially remote.