One of the cornerstones of agile methods is delivering value – “working software over comprehensive documentation”, “production or it didn’t happen”.
To achieve this, when decomposing stories it is important to keep them independently valuable. Stories are only really finished when they are usable by the end customer.
To focus on progressing stories to completion, you want to minimise work in progress and you want to use a strict stack rank of work – 1st , 2nd, 3rd, etc. (Rather that general priority such as high/medium/low, where you have 20 high priority stories, none of them finished.)
However a stack rank doesn’t scale – if number 1 project in your stack rank has 100 week long tasks, you can’t assign 100 people to the project and have it done in 1 week.
The solution is the proven strategy of divide-and-conquer. If project number 1 can accommodate 20 people, then you assign it 20 people (and probably need to split that into 2 teams), then project 2 might have 10, project 3 has 15 people, and so on.
This means multiple agile teams, that need to co-ordinate, while keeping the overall organisation agile.
The Scaled Agile Framework for Enterprise (SAFe) has an approach that coordinates multiple teams towards common goals, leaves individual teams enough room to be agile, and manages planning horizons to preserve the ability to respond to change.
First we will take a look at the planning process for teams, and how SAFe scales to multiple teams using Program Increments, then we will look at plans vs roadmaps, and preserving team agility.
Agile planning
Team process
Iterative processes, and in particular agile processes such as Scrum, have a fair amount of planning built into the process.
During a Scrum sprint there are actually two parallel streams of work being done -- you are not just working for the current sprint (sprint planning, delivering stories, sprint demo, retrospective), but also have regular backlog refinement sessions where you and looking at stories for future sprints.
Refinement is done in a just-in-time manner, where the focus is by the end of a sprint you need to have enough stories refined for the next sprint.
This is what allows a process to be agile, pivoting each iteration to a potential different direction based on events.
Even when the majority of focus is on the upcoming sprint, there is also long term discussion of epics and longer planning horizons.
It is difficult for a single team to scale larger than 10 people and maintain coordinated delivery, minimising work in progress, of a single backlog of stack ranked stories.
Teams should be capable of completing stories end-to-end, and so require cross-functional members. Hand off between teams should be minimised (hand offs have a high cost of knowledge loss).
Similarly, individuals should only be part of a single team, so it is clear what the next highest rank story is (if they were in two teams, they would have two backlogs, with two 1st items).
To scale larger than a single team we can use the same just-in-time approach, but taking different planning horizons into account.
Scaled Agile Framework (SAFe)
SAFe (https://www.scaledagileframework.com/) is a popular approach to scaling agile, by synchronising multiple teams across a program around Program Increments around 10 weeks (5 sprints) long. The process is documented in the book “SAFe Distilled”, by Richard Knaster and Dean Leffingwell, as well as through numerous articles on the scaled agile website.
With SAFe, there is a program backlog (stack ranked) of higher level features that are refined by teams into stories, along with team-specific stories. Each team then uses an agile process, such as Scrum, to deliver their team backlog.
Program increments, like sprints, are time-boxed, so teams prioritise stories and implement as much as they can. The iterative nature means velocity can be used to guide how much work to plan, and teams can always pull more features from the program backlog if needed.
Each team has their own journey, within the broad direction set by the program increment, with synchronisation (e.g. system demo) every sprint, and then collaborative inspection and planning across teams at the end of the increment.
Maintaining the program feature backlog
Similar to individual sprints in Scrum, during a Program Increment in SAFe, teams, particularly the program leadership, are involved in both current program increment activities and planning for the next program increment.
Current PI activities include the system demo (mentioned above), as well as PI planning, scrum-of-scrums, and inspect & adapt workshops.
Parallel activities focus on refinement of the program backlog of features, ensuring that it is ready for the next program increment planning, and allowing the entire project to pivot at each PI.
Having the regular program increment cadence, along with a focus on just-in-time planning for the implementation in the next program increment keeps the planning horizon reasonable. Generally you can have a fairly good idea of what will happen in the next 10-20 weeks, or the next business quarter.
One danger is still spending too much time on refinement up front. You need to leave enough options open at the feature level so that detailed refinement is done during sprints, close in time to implementation, not 10 weeks in advance when the details will quickly get out of date.
A way to manage this is using physical index cards and a physical board for features -- there are only so many cards you can fit, and only so much space available to write on them, avoiding the possibility of too much detailed analysis.
For more information, see https://www.scaledagileframework.com/enterprise-backlog-structure-and-management/
Scaling even larger
For endeavours larger than one group (50 - 125 people), SAFe scales up from a program backlog to a solution backlog (large solution) or portfolio backlog (portfolio of multiple value streams). A full SAFe implementation can include both.
In these cases the scope is wider, however the time frame is still focused on just-in-time refinement and preparation for the next program increment. This keeps the planning horizon within a reasonable length (one PI).
The backlog refinement needs to be continually undertaken within that parallel planning horizon. With a small scale implementation the refinement consists of program epics to features to high-level starter stories. In a full framework implementation the refinement will cover solution epics and portfolio epics to capabilities, then to features and start stories, but still all within one program increment.
Roadmaps, not plans
There is still longer term strategy, in the form of the portfolio vision and portfolio roadmap, however it needs to be understood that in order to change and be agile, the roadmap will also need to continually be revised and also change.
By definition, if you are following a rigid preset plan, then you are not being agile. A portfolio roadmap need to be treated as different from a plan; it contains best estimate forecasts, not commitments.
It is also important to limit future portfolio and solution epics to a roadmap, and keep plans to just-in-time for the next Program Increment, to avoid turning the roadmap into a queue. https://www.scaledagileframework.com/roadmap/
This involves balancing the benefits of stack ranking against the appropriate planning horizon – while it is important to rank items 1, 2, 3, spending time trying to rank items 201, 202, and 203, is not valuable.
A effective technique for managing different levels of planning is to use different time horizons, where short term plans are have more detail, and longer term roadmaps are at a higher level. Items 201, 202, and 203 remain unrefined and grouped, until they enter the relevant horizon.
SAFe has several different horizons for plans and roadmaps:
| Daily Plan | 1 day |
| Iteration Plan | 1 – 2 weeks |
| Program Increment Plan | 8 – 12 weeks |
| Program Increment Roadmap | 6 – 9 months |
| Solution Roadmap | 1 – 3+ years |
| Portfolio Roadmap | 1 – 3+ years |
Note that plans only extend out to the next Program Increment, around 3 months, and only at the feature (not story) level. Beyond that, SAFe uses roadmaps. This is similar to other iterative project management frameworks, e.g. PRINCE2 recommends a maximum planning horizon of 6 months, with methods like Unified Process (UP) and Crystal limiting detailed planning to 3 months.
Like using index cards, roadmaps are not extensive documents; limiting a roadmap to a single graphic keeps things open to respond to change. Future periods should have plenty of room to accommodate changes.
Balancing central initiatives with local input
While the solution backlog and portfolio backlog for larger scale implementations are a source of features in the program backlog, they need to be balanced with locally decided features.
Again, if you pre-plan 100% of the stories from the higher level backlogs then, by definition, you can’t be agile.
The split between local features, enablers, maintenance, and portfolio or solution epics can be managed by capacity allocation among the areas. For example one group may allocate 60% of their time to portfolio epics, whilst another only 35% (with a much higher percentage of local features).
When undertaking Program Increment planning and assigning features derived from portfolio (or solution) epics, the capacity allocation can be used to determine how many can be allocated from epics versus capacity for local features. https://www.scaledagileframework.com/simple-tool-for-planning-portfolio-work/
The capacity allocation can also be used for forecasting an epic’s duration by taking into account not only the historical velocity of the group, but also what percentage of that is allocated to portfolio or solution epics compared to local initiates. https://www.scaledagileframework.com/epic/
Implementation of SAFe
Even if you are not using SAFe, the principles and practices it implements are still relevant for scaling agile projects beyond a single team.
- Focus on delivering value; decomposing high level features into individually valuable stories, that are only complete when they are usable by the end customer.
- Maintain a stack ranked backlogs of stories. Also use stack ranks to prioritise features, capabilities, and higher level work items.
- Use a cross-functional structure, so that teams can deliver stories end-to-end and minimise hand offs.
- Use divide-and-conquer to allocate (as independent as possible) higher level features and capabilities across teams.
- Take into account planning horizons, to remain agile – beyond 3 months are only roadmaps; beyond a few weeks are only higher level features.
- Don’t assign 100% of capacity to higher level roadmaps; balance stories and features taken from higher level capabilities and epics with stories and features from the local team.