How to Use the Program Board Builder

This page describes how to use the Program Board Builder. To see the benefits of using the tool go to The Net Objectives Program Board Builder page. If you are interested in learning how to license the Program Board Builder, please contact Mike Shalloway.

How the Program Board Builder works

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. To use the tool requires creating a spreadsheet and entering information into it.

Setting up the input sheet

The board can manage any type of PBIs – Epics, Features, Stories. In the examples used here we use MBIs, Features and Stories. But this is an easy attribute file to change.

The first step is to create the input file. Let’s assume we’re using a shared Excel file. The person setting up the tool just makes an Excell file, adds the sprint labels desired and the team names. The sprint labels can be anything you want. For example, if you are doing SAFe, you might name these “Sprint 1.1”, “Sprint 1.2”, … as SAFe. Or you can enter dates of the sprint as shown in the examples.  You simply type in the labels you want in the first row of the sheet. Setting up the team names is just as simple, enter them in the first column of the sheet. This is shown in Figure 1.

Figure 1: Set up of input screen

Running the Tool

The tool takes the CSV file generated from the spreadsheet and creates the board. Specifying which file to use is done through a simple interface as shown in Figure 2:

Figure 2. Running the Program Board Builder.

In the above case, it is running from a CSV file called PBB_DS_1.csv

When program runs on this input sheet it will generate the board. At this point, there is no information on the board so it would look  like that shown in Figure 3. Note how a legend is automatically added.

Figure 3. Initial spreadsheet with teams

 

 

 

Entering stories and dependencies

Entering stories is just as easy. Enter the PBIs with dependencies on the spreadsheet that has the names of the teams and the labels or dates of the sprints. To “put up a string between two PBIs” is a two step process. First, you put up the PBI that has the dependency followed by what it is dependent upon in parenthesis. For example, if you have an MBI called M1 that is dependent upon a story called S1 you merely enter M1(S1) on the row of the team doing M1 and in the column representing the sprint it will be completed in. Then you enter S1 in the column it must be completed in.

For example, in the fourth sprint the Finches team have a PBI called M1 that depends upon story S1 which will be done in the third sprint by the Sparrows team. M1(S1) would be entered into the fourth sprint column and Finches row and S1 would be entered into the third sprint column and Sparrows. This is shown in Figure 4. The input screen is always the spreadsheet, the output is generated by running the Program Board Builder tool in another window.

Figure 4. Entering dependent stories

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, both Sparrows and Finches will need to indicate M1 and S1 in the correct sprints while the agreement is indicated by adding an asterisk after the dependent PBI, M1(S1*). This is shown in Figure 5.

Figure 5. Showing agreements

Completing the board

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

Figure 6: Nearly completed board

Using the board to see only one team’s work

To see all of the cards associated with a team, you just enter the team you want to see on the run screen. as shown in Figure 8 for the “Crows” team.

Figure 8: Showing PBIs related to the “Crows”

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

Figure 8. Program board filtered for ‘Crows’

Using the Program Board Builder in a planning event

There is no limitation on how the Program Board Builder can be used, but here are a couple of ways it can be done:

Emulating a phyiscal board

In this case a computer connected to a projector uses the Program Board Builder to create the display. As in current planning events, the space near the board becomes where agreements are validated before putting on the board.

Recommended use – all people present

In this case there is still a computer generating a virtual board on a wall. But now each team has their own instance of running the tool.  They enter the data and the virtual board machine updates it on a regularl cadence. The team can also run the display at their machine but most likely has it set to seeing just the cards that relate to them.

Recommended use – remote teams

This works the same as when people are all present.  All the teams, remote or otherwise, are connected to the tool. In this case they likely run two versions of the display – one for their team and one for the entire program.