Visualisation Technique for Constructing & Understanding SAFe Program Backlogs
I was recently asked to help facilitate and to act as coach at a multi-day kick-off event for a new Agile Release Train (ART). The agenda initially looked a lot like that of the SAFe Program Increment (PI) Planning event, but there were immediate differences, the main one being a restricted attendee list due to ongoing team recruitment. The people in the room consisted largely of the SAFe Program level: Release Train Engineer (RTE), Product Management, Product Owner, Architecture, and a few Subject Matter Experts.
There existed a draft Roadmap that had been given a fair amount of thought and had at least a notional priority order, as Program Epics and Features were organised into four groups of decreasing priority. As an RTE or Agile Coach launching a new ART, one of the most pressing questions to ask yourself at the kick off of the new Program is this:
What needs to happen before we can plan our first Program Increment?
- Is the team in place?
- Is the Program Backlog ready for planning?
Clearly in the case of this ART, the Agile Teams were being recruited, but if you have a full Program team, as they did, then you can still prepare the Backlog. So how do you establish whether or not the Program Backlog is good enough for PI Planning, and if it isn’t then what techniques could you use to facilitate further preparation?
Preparing the Program Backlog
The Roadmap, as I mentioned above, did exist and the Product Management team had applied a best-guess set of priorities. The Architecture team had produced documents showing system breakdowns and interactions, so clearly a lot of thinking had already gone into articulating the Vision from various different viewpoints. What still needed to be established was whether or not the entire Program team had the same understanding of the Features on the Roadmap, whether or not the Features had been right-sized, and whether or not the priorities were correct.
Does the Program Team Understand the Features?
Simply asking a group of people if they understand a written statement, such as a Feature description, is usually insufficient if you want to know that the entire group has the same understanding of that Feature. I’ve found that one of the most effective ways to quickly figure out if there is a shared understanding is to start prioritising the work.
SAFe recommends a method for prioritisation called the Weighted Shortest Job First (WSJF). This method uses four measures to apply a weighting to the items on a backlog:
- Business Value
- Time Criticality
- Opportunity Enablement/Risk Reduction
- Duration (Size)
I won’t go into any more detail here regarding WSJF; the point of listing the criteria used by this weighting method is that asking the team to agree these measures can help you to establish whether or not there is a shared understanding of the Features on the Backlog.
To begin with I asked the team to select what they thought was the smallest Feature. What I intended was for them to relatively Size each of the Features in priority group 1. With the simple question, “Is this Feature bigger or smaller than the others?”, it very quickly became clear, as they tried to do this, that their shared understanding, beyond a superficial level, was very patchy.
There’s a chance when you’re doing this that everybody agrees on relative sizes and that the act of sizing the Backlog doesn’t draw out the right conversations to show any gaps in understanding. This is why I like the full set of measures used for WSJF; if discussions on Size don’t draw out any gaps, maybe discussions around Business Value will, or Time Criticality.
When using this method as a way to establish whether or not a team has a shared understanding, alarm bells should ring in your head when there is a lot of drawn out discussion, debate, or disparity across the group when it comes to agreeing on relative measures. Discussion is good and allowing it to unfold can get you to a shared understanding pretty quickly. However sometimes there can be just too much Backlog to go through, and the mood in the room becomes desperate as more and more complexity is unearthed.
Don’t draw the process out for too long. When it becomes obvious that relative measures are causing stress, then the Backlog is probably not well enough understood. Stop what you’re doing and start clarifying!
Mapping out your Features
The team I was coaching had a Program Backlog with roughly 60+ Features already articulated. Some of those Features were better understood than others and some were placeholders, where the requirements – many of which were regulatory - were well defined, but the Feature or Features themselves were not yet validated.
While there was a set of priority groups, it was largely the best-guess of the Product Manager and he was keen for the Program team to help validate this order.
After attempting to prioritise the Features, it quickly became obvious that the team’s shared understanding of the Backlog had many gaps, we consequently clarified the objective of the kick-off event to be: Validate and gain a shared understanding of the goals and priorities for the Program team leading up to the first PI Planning event.
Inspired by techniques such as Story Mapping, as described by Jeff Patton in his book “User Story Mapping”, and other activity modelling methods, we set about visualising the backlog by mapping out what each Feature looked like in terms of how we imagined the system being used. The key purpose being, build a shared understanding of the behaviours that the system should exhibit by focusing on Feature flow, avoiding discussions that might be more focused on how the system should be constructed. As RTE or coach, it is important here as in all things to make sure the teams do just enough work to meet the objectives. It’s possible with any Mapping technique to get into a great deal of detail; the point of this whole exercise is to understand and prioritise the Features, not to facilitate any big, up-front elicitation. Let the teams map out the User Stories during PI Planning.
Feature Mapping Technique
So what did we actually do?
What we did not do was to start from a blank sheet of paper. You can do this, especially with a new system, but so much thinking had already gone into what the Roadmap should look like that the very idea of starting again would have lost the room. Besides that, the list of Features already present was a great way to frame the Feature Mapping session.
Here is how it went:
We took each Feature in turn, starting with the highest priorities as defined by the product manager.
- Using a blue Post-it, the team wrote a short description of the Feature and placed it on the wall (top-left felt like a good place to start the Map!)
- The entire Program team self-organised around the discussion, which allowed different people to take a lead in those discussions, depending on who knew most about the Feature being discussed.
- The team was asked to consider each of the steps taken by the user (which could be another system) when carrying out the specific activity summarised by the Feature, write a brief description of each step on a yellow Post-it and stick them underneath the Feature in the order of flow from top to bottom.
Each step in the flow of the Feature was discussed just enough that everybody in the room was comfortable that they understood it, with their own concerns at the forefront of their minds.
- The Product Manager would be mainly concerned with it meeting Business Goals in the right way, while the Architects were concerned with the implications it has on the Technology Solution.
- Anything drawn from the conversation that needed to be recorded was captured on a green Post-it and added to the wall. Program dependencies and risks were key aspects, as well as any spikes required in order to facilitate a better understanding of the Feature.
This is where you need to watch out for team going into too much detail: Keep the focus on doing just enough to understand the goal of the Feature and the relative priority; this is not about up-front elicitation.
- The four priority groups on the original roadmap represented Business Milestones. After some discussion it was decided that only two Milestones were in fact required; these were illustrated on the Map by slicing the wall vertically. In this way a first pass at validating the roadmap could be achieved by asking, which Features have to go on the left hand side of each Milestone?
Alas I could not take any photographs of what we ended up with, because camera equipment (including my phone) was not permitted in the area in which the event took place. Figure 1 shows an illustration of roughly what this looked like as it took shape across the wall.
Understanding the flow allowed the team to get a good feel for how many larger Features were hiding multiple user activities, and in this way they were able to slice them into multiple smaller, right-sized Features.
Ultimately this changed the shape of the Backlog. New Features sprang out of the details of existing Features, and other Features were even dropped. It took time, but the team got into a sustained rhythm over several hours and were actually quite difficult to stop, once they got going. A very good sign of a valuable session!
For many programs, it will not be necessary to do as much work as we did in this session. Going through the majority of the Backlog was only necessary because it represented a brand new system for which there was a lack of shared understanding of the system as a whole, and a lack of confidence in the priorities. As your backlog matures and you get into Flow, the teams will carry out this work and generate their plans Just-In-Time. By discussing and building a shared understanding of their very first Features using WSJF and Feature Mapping, the Program team had much more confidence and achieved consensus over the backlog priorities and their Feature scope.
Starting out with a set of Features and Program Epics in a new Program for which there was limited shared understanding amongst the Program team, no real idea as to whether or not they were right-sized, and a priority order that had no consensus, in less than two days we’d achieved a Roadmap that tied into the Business Milestones and a set of Features that were right-sized, prioritised well enough to get started on the top priorities, and articulated well enough that the entire Program team shared an understanding of what they meant to the user, what implications they had for Technology, and how they achieved Business Value.
The goal of the Program kick-off event was to Validate and gain a shared understanding of the goals and priorities for the Program team leading up to the first PI Planning event. The value of this Feature Mapping technique in helping to frame and facilitate the discussions that led to this outcome cannot be over stated.