Here’s an overview of one approach to doing strategic planning in a scaled-up scrum environment. We’ll use twelve weeks as our planning horizon, though the approach works fine for shorter periods as well. We’ll start by looking at how a single team could plan for such a time horizon on their own without considering the broader organizational context, and build up from there.
Single Team Planning
We are assuming the organization’s teams are practicing scrum, kanban, or a similar framework. For an individual team to create a quarterly plan for their own work requires a refined product backlog with at least a quarter’s worth of work. The order of items in the product backlog can be optimized based on value. One way to determine this is by dividing the business value estimate of each product backlog item by its effort estimate. Items with high business value and low effort should generally be done before items with low value and high effort. Other factors such as dependencies must be considered as well. For planning to be effective, team members should be fully dedicated to a single team — move work to teams, don’t move people to work! Additionally, each team must have a known velocity, which is based on their history of completing backlog items each sprint.
Strategic Planning Velocity
When planning for longer periods of time, say 6 – 12 weeks, the team should not plan with their full velocity. Over the time period in question, unplanned work will certainly emerge. If the team starts with a plan that is full, i.e. they made a plan that uses all of their expected capacity, then that plan will break every time some new work emerges. A good rule of thumb is to plan at half velocity. If the team’s velocity is 100 points per sprint, then their strategic planning velocity should be 50 points per sprint.
Over time, a team can fine-tune their strategic planning velocity by noting how much of the work from a given strategic plan actually was completed at the end of the period (e.g. a quarter). Let’s say our example team, with a velocity of 100 points per sprint, made a quarterly plan based on a 50 point per sprint planning velocity. They put 600 points worth of backlog items (stories) in their quarterly plan. At the end of the quarter, they look back to see how many of those items were actually completed at the end of the quarter. Perhaps they find that they completed 500 points worth of the items from the plan and 700 points worth of other items that weren’t in the plan. Next quarterly planning, the team should plan for 500 points worth of work over the next quarter. Notice, the team did their usual 100 points per sprint (1200 points per quarter) worth of work. When we plan at a fraction of the usual velocity, we are not planning to be less productive; we are building in room for the inevitable emergent work that will arise during the quarter.
What we have described so far works great for individual teams. A large organization is much more than a collection of teams, each pursuing their own agendas. From here on, we’ll describe how to make a strategic plan for an organization with many teams. We’ll continue to use twelve weeks as our example planning horizon.
A strategic initiative represents a large and valuable goal for the organization. A strategic initiative generally requires many teams to plan and work in a coordinated way in order to complete the initiative. Strategic planning is the process of selecting one, or possibly more, initiative(s) for the organization to pursue in the coming quarter. In general, pursuing fewer initiatives at a time leads to initiatives being completed sooner, and thus more initiatives completed in any period of time.
Most large organizations have cross-team dependencies. That is, before team X can complete backlog item A, they need team Y to complete item B. It’s helpful to visualize those dependencies for more efficient planning. We refer to the visualization as a dependency map. This mapping can be done through a spreadsheet or your preferred visualization tool. The dependency map increases transparency about what work needs to be done, by which teams, and in what order.
A map shows the tree of dependencies lurking below a single backlog item. We’ll call the initial item the top-level item. Below the top-level item are all the items that it depends on and all the items that those items depend on. The result is an inverted tree structure. The branches of the tree connect backlog items to other items that they depend on. At the outermost edges are the leaf nodes, which are items that don’t depend on other items.
A whole initiative can be represented as a map of maps (a tree of trees). At the highest level is the initiative. Below that are the backlog items that are directly required for the initiative. Each of those items may have dependencies, and so each one is the top-level item in their own dependency map.
Using the dependency maps as input, the next step is to determine if it’s possible to resolve the dependency chain for each proposed initiative in the time available. The dependency resolution schedule will have a column for each team and a row for each sprint.
Start by placing the top-level items on the dependency chain into the last sprints of the quarter. This indicates that we need them to be completed by the last sprint, otherwise the proposed work isn’t feasible within this time period. Work backwards from there, walking the dependency maps and placing required stories into sprints, based on the teams’ planning velocities. The goal is to see if the dependency chain can be resolved in the time available.
A Return To Waterfall!?
While waterfall assumes making a plan and sticking to it, responding to change is crucial to agility. Agility doesn’t preclude making a plan, but it is not “The Plan” and we expect that it can and will change. The dependency resolution schedule is just a tool to see if resolving a given set of dependencies is feasible. Importantly, we are not using full velocity, we are using the planning velocity (typically half of full velocity). We are building in the ability to respond to change, while still giving an answer to leadership’s question: “Is this achievable?”
In order to make an informed decision about which initiative(s) to pursue, leaders will need the following information for each potential initiative:
- Estimate of the value of the initiative
- Estimate of how much work is required and by which teams
- Estimate of other costs besides labor
- Forecast of when the initiative could be completed
- Inherent risks involved in pursuing the initiative
We have described the work that teams would do to create estimates of the work and forecasts for which initiatives could feasibly be completed in the coming quarter. This data becomes important inputs to the decision process for selecting which initiative(s) to pursue.
Leaders will also need value estimates for each initiative. This video demonstrates one approach to creating value estimates and you might want to read about some of the myths about business value that get in the way of estimating it.
Each initiative, or combination of initiatives, comes with a set of risks. Perhaps there is very little wiggle room in the dependency resolution schedule. Perhaps there are dependencies on outside groups that we don’t have control or influence over. Leaders will want to consider: schedule risks, financial risks, technology risks, security risks, legal/compliance risks, and so on.
Based on consideration of these many factors, and in consultation with the various experts in the organization, leaders select the initiative(s) for the organization to pursue. Notice, this decision comes near the end of all of this work, not at the beginning! In order to pick initiatives, leaders need a lot of data from the teams about cost and feasibility.
Plan The Quarter
Based on the dependency resolution schedules, a plan for the quarter can be created. The dependency resolution schedules are the starting point. They are optimized by moving items as early in time as possible to reduce risk and increase the ability to respond to change. Teams that have available capacity will backfill their part of the plan with the most valuable items available to them, just as in the single team planning scenario.
Teams cross-check with each other to make sure all known dependencies will be resolved and that all work fits in the time available. When no issues are found, the group has a strategic plan that has a good chance at success!
- Bring our Strategic Planning For Scaled-Up Scrum workshop to your organization
- Scaling Agile – Big Room Planning
By Chris Sims and Season Hughes