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 how to set up the Program Board, this blog will look at the Program Board’s use during PI Planning.
Use During PI Planning
How to represent value
During the Team Breakout sessions of PI Planning the teams take Features, create the stories to realise the value requested in the Feature, estimate those stories and sequence them into the available iterations. Once the team know when they think they’re going to complete a Feature then it can be represented on the Program Board in the iteration where the value is going to be delivered.
Figure 1: Feature Planning
From a practical perspective tickets are transferred from the Program Backlog onto the Program Board. The advantage of this is that the central roles, e.g. Product Manager or Release Train Engineer, have written the tickets, in their best handwriting, so that they are readable. The tickets can also contain other relevant information such as the identifier used by any online backlog management tooling. If the teams create the tickets then it requires a lot of discipline from the teams to remember to use words and information that connect the ticket back to the underlying information in any backlog management tooling.
That said, it isn’t simply moving the ticket from Backlog to Board, the whole of PI Planning is one giant negotiation. if the negotiation changes scope then the ticket should be annotated to indicate what that change of scope is, to make it transparent to everyone in the train about what is being delivered; the backlog management tooling can be updated after the event by the Product Management team to reflect the scope changes.
Linking to milestones
Link the Features needed for a Milestone to the Milestone with a piece of string. It’s a simple little thing but it allows everyone to see what is contributing to a Milestone by tracing the string back to the Features.
Figure 2: Linking To Milestones
How to represent collaborations
The one rule of the program board is that teams are only allowed to put tickets into their own row on the Program board.
If Team A needs to collaborate with another Team B then Team A has to walk across the room and negotiate with Team B. Typically this involves helping Team B to create work in Team B’s backlog. Team B plots the work into sprints and the set of work is summarised on whatever colour ticket is being used to represent collaborations, typically Red. Team B transfers the Red ticket that summarises the work they are doing into their row on Program Board in the Sprint in which the collaboration is going to be realised. Team A can then use string to link Team B’s work to their Team A’s work.
Figure 3: Representing Collaborations
It may seem like going the long way around, but negotiating with the other team, getting them to represent the work as a ticket and then linking to that ensures that the other team knows there is work to be done. If teams just start sticking collaboration tickets into another Team’s row on the Program Board then there is no guarantee that the receiving team even knows they have work to do. The whole planning process should be about negotiation and agreeing as a team-of-teams about what can be done, that the process encourages those negotiations is a good thing.
As well as being represented on the Program Board, the collaboration should also be represented in the objectives of the team being collaborated with. Collaborations are one of the places that Objectives originate from, as described in the article on Writing Good Objectives.
No Feature to Feature Collaborations
Features are independent, therefore there should never be Feature to Feature collaborations. If you need something from another Feature it’s never the whole feature just part of it; separate that part out, represent it as a red ticket and link to that. This helps teams think about what needs to be separated out and delivered early in order to support the other teams rather than assuming that it all has to be delivered as one monolithic lump. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”Agile Manifesto Principle #3.
Figure 4: No Feature To Feature Collaborations
The one rule of the program board is that teams are only allowed to put tickets into their own row on the Program board, but with the External collaborations there is no team present to put tickets into the row.
External collaborations tend to be known about in advance, “We can’t do Feature X until we’ve received an update from our database supplier”, they are not the same as the collaborations that emerge through PI Planning. As part of preparing the Features for PI Planning the central roles of Product Management and System Architect, with appropriate support where necessary, should be looking at the upcoming features and identifying if there are any external dependencies. The negotiations about those external dependencies often need to be set in motion early, the aim being to negotiate a date for when the dependency will be resolved. At planning a ticket can be added to the Program Board in the External Dependencies row to represent that delivery so that the teams on the train can sequence their work around the delivery of that dependency.
Whoever owns the contract and relationship to the external supplier should be present during planning to represent what is expected from the supplier.
Collaborations with other trains
The other trains should be planning at the same time as this train: SAFe Principle #7: Apply cadence, synchronise with cross-domain planning. Therefore if teams on this train need to collaborate with teams on another train they should be able to call that train and negotiate with them directly. Once the work has been negotiated then it can be represented on the Program Board.
In a similar manner to External Dependencies we will have to break our rule about placing tickets on the Program Board because the other trains aren’t physically there to do it. What’s important is that the ticket only goes onto the Program Board after it has been negotiated.
How to represent incremental delivery
Some Features are large, they are the end-state that the Customers and Product Management dream of, they could be delivered incrementally.
Those increments, partial deliveries that are complete and releasable in their own right but not yet the dreamt of end-state, can be represented on the Program Board as Red Post-It’s. Such increments are powerful because they allow the system to be evaluated early and the results of the evaluation can be used to steer future development on the feature towards success. Making those increments visible allows everyone to see and plan the evaluations, either as an explicit demo of just this piece of functionality or as part of the end-of-sprint System Demo.
Figure 5: Incremental Delivery
Halfway through PI Planning process the senior staff on the Agile Release Train gather together for a Management Review. During the Management Review the Program Board helps the senior staff on the train answer the question “Is the work being done right?”
- Is the work hitting the milestones?
- Are there bottlenecks?
- Are there structural issues with the teams?
There are a series of articles here that describe an approach for facilitating the Management review. Part 2 of the series describes the use of Program Board during the Management Review and provides practical advice of what to look for and examples of real-world scenarios that have been observed in the past.
Lots of videos and images show grinning facilitators leaning against ladders showing off “The Worlds Largest Program Board”. This isn’t necessarily a good thing…
If you have to attendeded the Health & Safety course on Working At Heights, just to get Post-Its® onto the Program Board then that’s an indicator that your Agile Release Train is too big!
Beware of Infinite Whiteboards in the virtual world, if you have to scroll forever through the Program Board just to get to a team’s row, then that’s also an indicator that your Agile Release Train is too big!
The Program Board is a key artefact to construct during PI Planning; this article has described some sensible, practical steps to ensure that the construction of the Program Board supports empowering the teams to build their own plan whilst simultaneously letting the team-of-teams visualise the results of negotiations around the cross-team collaborations.
The next post will explore how the Program Board is used during PI Execution.
More Great Agile Content from Ivar Jacobson International:
- How Many Features do you need for PI Planning
- WSJF & Feature Slicing
- All about the PI Planning Management Review & Problem Solving
- Secrets of Dispersed PI Planning
- Estimating in Story Points