Agile Planning Part 2 — An Agile Planning Framework in Action

Photo by Startup Stock Photos from Pexels

In my last post I introduced a simple, scalable agile planning process. I’ve used variants of this with success across my time at AWS and now Coalition with organizations up to several hundred developers. In this post, I will show an example planning period using our current implementation at Coalition.

Let’s first recap briefly. We want to go through a planning activity where we agree on the set of roadmap epics we will deliver over our planning period. Our planning periods at Coalition are something close to calendar quarters. We map epics to teams so that we know which teams have work to complete to deliver the epic. Teams estimate their epics along with their capacity so that we know what fits and what doesn’t. We are finished with planning when the set of epics fits within available capacity across all teams and each epic is fully funded by all required teams.

Part 1 — Setting up

The process should be fairly straightforward to implement on any change management system. We implemented using JIRA at Coalition (and we suffered through it on SIM while at AWS — Amazonians will understand ☺). In JIRA, we use a project specific to the planning activity called ROADMAP with these fields. Some are JIRA standards whereas others are created as custom fields.

• Planning Period — this should be a select field with values that correspond to however you want to refer to your periods. We follow this pattern: 2021-Q1, 2021-Q2, 2021-Q3, etc.
• Rank — this is a numeric field for the epic priority. We use 1–100 as the range where 1 is highest priority.
• Component — each team should have a corresponding component created. We use a team::<team_name> convention.
• estimate-<team_name> — this is a series of custom fields, one per team that is part of your planning activity.
• Investment Category — this one is optional, but can be useful to track buckets for different investment types. We use things like RUN, IMPROVE, DELIGHT, GROWTH, PAPERCUT.

For the estimate fields, we enter small JSON snippets of the form:

{ “wag” : <wag-value> }

For example:

{ “wag” : 2.0 }

means a wag estimate of 2 developer-months. These same estimate fields are later used to carry the spent and remaining work fields that track burndown across the planning period. A fully populated estimate field during the period might look like this:

{ “wag” : 2.0, “spent” : 1.0, “remaining” : 1.0 }

Note that there is no requirement for spent plus remaining to equal the original wag estimate — in fact, it’s useful to notice when they diverge! The wag estimate is set at planning time and rarely changes whereas spent and remaining should always reflect the team’s best estimate of work spent and work remaining.

Next, we need a system to consume the data from JIRA and produce the views that we want for planning and period execution. At Coalition, our data stack is built around Fivetran for data ingest, DBT for ELT, a Snowflake data warehouse, and Looker for analytics and dashboards.. Within Looker, we implemented two views — one for planning, and one for burn down tracking. We then created a series of standard dashboards for anyone on the team to use. Examples of the views and dashboards are below.

Part 2 — Example Period Planning for “SocialApp”

In this section, we get to see the process in action. Here’s our hypothetical scenario. Our product team has built a simple social media app — think something akin to a hybrid of twitter and slack. They have been scaling up the dev team to keep up with growth and traction and decided to try the planning process.

The dev team is now grouped into four squads — the App, APIs, backend, and a platform team. While I would never recommend a planning period this short, to keep this example simple it is a 4-week planning period, labeled 2021-P4.

Each team has provided their capacity in ideal dev-months for our 4-week period as shown in this table.

You can see that each team has held back some of their theoretical capacity. This way there is a capacity allocation for all of the non-roadmap related activities that are inevitable for any team (e.g. on-call, support, time off, meetings, etc.).

Next, the Product Management (PM) team has prepared a list of candidate epics that they would like to consider for planning as shown here. This list is sorted in order of increasing epic rank (recall that lower rank = higher priority). This view is the left half of our main planning dashboard in Looker.

The other half of that same dashboard view shows the estimates that the teams provided. The rows in this table correspond to the same seven epics above.

Let’s look at one of the epics in detail. SOCIAL-7 (row 4) was estimated at 0.5 dev-months for team::apis, 0.25 dev-months for team::app and 1.0 dev-months for team::backend. The corresponding utilization column for each team shows a running total of the amount of capacity consumed for that team. In this case, team::apis is now at 63%, team::app is now at 120%, and team::backend is at 89%.

This is where that special backlog grooming activity comes into play that I described in the first post. Recall that the plan is not valid until all teams have a set of epics that fit within their available capacity and all in-plan epics are fully funded across required teams. In this case, we have both epics that are already out for all teams (ex. SOCIAL-5) and epics like SOCIAL-7 that are in for some teams and out for others. We adopted the name ‘grass cutting’ for the activity as homage to the green formatting in the utilization column. Anywhere you see a blade of green ‘grass’ in your plan, it needs to be cut so that capacity is only planned to at (or very close to) 100%.

Here are the major decisions the teams decide to make after a few rounds of discussion

• The 2 lowest ranked epics, SOCIAL-2 and SOCIAL-5, are dropped as they are already over capacity for most teams (NOTE: team::apis had capacity to do some portion of the work on SOCIAL-2)
• Since team::app is the one without enough capacity to finish SOCIAL-7 (Add friend recommendations), they decide to scope it to API support only. Thus, team::app untags from the epic and removes their Wag estimate. This seems reasonable as the most complex part of this feature is the friend match algorithm anyway. The team is confident they will be able to deliver early in the next planning period.
• The teams also reach agreement that team::apis can take some of the team::backend work on SOCIAL-6. Those Wag estimates were updated accordingly

The updated plan view on your planning dashboard now looks like this:

Notice that we do not have any more green in the utilization columns — the grass is cut ☺! In practice, nothing ever works out to be this “tidy” of course. We generally strive to hit 100% plus/minus a few percentage points, realizing that the estimates are rarely that precise anyway.

Part 3 — Example Period Execution for ‘SocialApp’

With the plan in good shape, the teams start their dev sprints. Over this period teams update their estimates fields once per week to reflect their best estimate of spent and remaining effort. This happens in conjunction with a scrum-of-scrums like session where plan progress is reviewed.

To facilitate the plan review scrum, we have a Burn down Dashboard in Looker. Here are a few of the most important tiles. First, this is an aggregate summary of overall progress for the period:

The light green line represents the ideal linear burn down over the period. The magenta line represents the actual burn down achieved for the period in question. Notice that the org actually starts slightly ahead after the first week but starts to trend a bit off track by week three. While, this view gives you a sense of the overall progress across all teams, this next tile tends to be more insightful.

This table shows week-by-week progress of each team as a delta percent between their ideal and actual burn down. Using this view you can easily see that both team::app and team::apis have trended somewhat off track. From here, there is one more dashboard that drills down to team-level details. Here’s what that dashboard shows for team::apis after week three.

The upper table shows the current state of spent and remaining estimates along with a scope change column that indicates where the actual effort on an epic has trended differently than the initial Wag estimate. Recall that we avoid updating the Wag estimate after planning is finished. The lower set of tiles highlights various key stats about how the team is progressing through the period. Notably, the Finish Gap tiles show how far the team has trended off track in both Wag terms and in weeks. The Accel. Needed value shows how much the team needs to accelerate Wag completion to be able to complete the period successfully.

At this point, the team is only projected to be 0.6 weeks = 3 days late which isn’t too bad. When a team trends significantly off track, though, it should trigger a conversation about what sort of mitigation is appropriate. If an epic only requires work from the team that is behind, then that epic could potentially be pushed to the next period or rescoped to reduce the effort required. If an epic has dependencies across teams, then teams will need to come together to decide on the best course of action. Regardless of the outcome, the sooner this conversation and decision happens the better. Having a realistic picture of what will deliver and what will not minimizes in-flight work and drives better stakeholder communication.

Part 4 — Closing the Period

Here’s what the final burndown looks like for our example planning period.

The team didn’t quite finish SOCIAL-6 so they decided to create a new ‘spillover’ epic that they will plan at the highest priority in the next period. This is visible in the drop of the ‘blue’ total WAG line on the graph. They also run a retrospective and try to identify one or two areas for improvement along with an action. Overall, though, they shipped 4 of 5 epics in the period and feel great about the progress!

Conclusion

Hopefully this post has helped you to understand the agile planning process that I introduced last time. The top benefit I see time and again is that it drives alignment and visibility to organization and company priorities. Exiting the planning conversation, all stakeholders have had the opportunity to disagree and then commit to the plan. The priorities are inherent in the plan and visible for everyone in the organization at all times.

As I noted before, mastering the process takes some practice and experience with your team. Remember the important tenet that perfection is not the goal here. Whatever variant of this or other planning process you might adopt, it’s much more important to set high standards and then drive for continuous improvement over time.

I have one more post to go in the series. In number three, I’ll show how tracking the planning process over time yields some really nice insight into organization capacity and velocity. As always, I hope this was helpful and would love to engage around more of the nuances here with those that are interested.