Agile Portfolio Management – Iterative Roadmap Grooming

Below I describe a process that grew organically, bottom up, starting with my experience as a project manager-turned scrum master. I now run the PMO for more than 250 projects per year, with close to 200 engineers, across multiple brands and locations for a $1.5B web retail company in Silicon Valley. That is not a colossal scale, but large enough to prove the concept.

This is not a theoretical methodology. Below is an overview of the solution currently in place to moderate the inherent friction between the long-range forecasting needs of C-level executives versus the schedule flexibility of our agile development teams.

Specifically, public companies forecast earnings three, six, twelve months into the future or more. Companies whose earnings depend on building software require a software development roadmap of equal range. Creating a reliable long-range development roadmap reaching several quarters into the future is a real challenge. But, reliable or not, it is essential to support the revenue forecast. If the development teams cannot provide a roadmap, executives will be forced to invent one.

The problem with an unreliable roadmap is that the reality of what’s being built quickly diverges from expectations. Trust dissolves. Friction reigns. Work sucks. Been there. Done that.

Over the years my stakeholders have required long-range development forecasts that kept getting longer and longer. But no matter how I tried, I simply could not keep the enterprise roadmap synchronized with the rapid re-planning, scope swapping, and problem solving happening within the agile teams. Turns out the solution was always right in front of me. But, like agile, it required redefining traditional roles and responsibilities.

It is worth noting, on our journey of continuous improvement, we still make the following process concessions: 1) teams don’t get to work on one project at a time, and 2) teams skills are not homogenous – not all team members can do every task.

A Familiar Process

During the first ten years of my career roadmap planning was pointless. No matter how much effort I put into its care and feeding my roadmap plans quickly became obsolete because of competing interests, ambiguous requirements, uninformed estimates, unreasonable deadlines and far too many moving parts.

Then it struck me. My large cross-­functional projects had exactly the same challenges yet I had those under control. So why couldn’t I manage a roadmap to save my life?

Then I recognized roadmaps were really just agile project plans (release plans) scaled up. Both contained chunks of work defined by scope, schedule and resources. And, the further out the work the less defined it was. The clear difference, aside from the size of the work each contained, was how they were managed. Our agile projects were managed by self-organizing teams. Roadmap planning, on the other hand, was managed by spectators.

Team Driven

Agile teams deliver projects reliably when, as a team, they continuously inspect their progress and adapt their future plan accordingly. All information flows through a single source of truth, (like a specific data space, or ideally a task board). Those doing the work capture their own progress for their own benefit. Others can view that progress for the best possible indicator of the project’s status.

Likewise, a roadmap holds together when it is captured in a common data space by the people who benefit directly from keeping it accurate. Teams size and slot projects into their own slice of the roadmap the same way they size and slot stories into a release plan. In this way, just as a project is a roll­up of hundreds of stories from different teams, our roadmap is a rollup of hundreds of projects from different roadmaps each with multiple scrum teams. In our organization we have three layers of planning in our sprint tool: sprints, projects and roadmaps. Each layer requires regular communication to keep it real.

Keeping It Real

Sprints

No change here. Sprint data is managed and shared through sprint planning meetings, individual updates, and daily stand­up meetings. Project and roadmap details require similar care and feeding – from those who know them best.

Project Steering

To create a single-source-of-truth for our project data (e.g., status, schedule, issues and risks) years ago I created a new issue type in our sprint tool called “project”. I gave this issue type fields and workflows customized for how we work. (See this post for more detail.) Just like a weekly ‘bug scrub’, teams gather weekly in their project steering meetings to scrub their projects’ statuses and details. That is, those who know best, the team leads, gather to address issues and risks, update who is working on what and for how long, then update the roadmap/resource map with the result. They define exactly what decisions they need from roadmap stakeholders and share any major issues and risks the team is facing. Here’s an important point. Roadmap stakeholders do not attend project steering meetings.

Here’s why. The teams need a place to sift through their ‘dirty laundry’ of issues and risks without fear of precipitating panic. The vast majority of project threats are managed at the team level without affecting stakeholders. When team leads gather to groom project statuses, schedules, issues and risks they are literally grooming their own slice of the larger roadmap. The groomed project information is consumed across the enterprise, but particularly at roadmap steering meetings.

Roadmap Steering

During roadmap steering meetings stakeholders review a roll­up of teams’ project statuses and make trade­off decisions required by the teams. This is where decisions occur about which projects to greenlight, which to drop, which new projects to investigate, etc. Roadmap meetings serve as the change control board for a given roadmap. Any change to a roadmap must go through this team whether stakeholders can do anything about it or not.

Meeting cycles to review the single-source-of-truth then become the conduit for any number of agile teams to collaborate with any number of stakeholders up and down the organizational stack. Everyone uses the same single­-source­-of­-truth to create, read, update and delete projects’ schedule and status on their various roadmaps.

Regular meetings where data is updated in real-time during the meeting itself help provide for a living roadmap/resource map. Management teams and stakeholders inspect and adapt their long-range roadmaps in the same way sprint teams inspect and adapt their sprint tasks and release plans.

Roadmap Grooming

A product owner (PO) shares a project idea with their scrum team(s) similar to introducing a new story into a groomed backlog. The teams roughly size the project and, accounting for their current commitments in their resource map, propose a broad window of time in which the project could potentially ship – a project “ready window.” When the project spans multiple scrum teams the teams collaborate to align their respective resource maps. The business then chooses to greenlight the plan or not. If greenlit, teams update their respective roadmaps and resource maps with the staffing plan the business selected and they themselves crafted. In this way, many contributing teams can book their sub-­projects as necessary to deliver an overall program while fully negotiating every trade­off with their respective stakeholders. In the example below, three teams collaborate on a project totaling 42 days of work between them.

The graphic above shows the general idea.

1. The business shares a project idea with the teams as some kind of ‘idea doc’.
2. The teams size the idea and share out any trade­offs necessary against existing roadmap projects.
3. Scope Check #1: Stakeholders assess if the value of the project justifies the effort and trade-offs presented by the team(s). If accepted, teams update their roadmaps and attach the original ‘idea doc’ to the project ticket to later compare against the detailed project stories yet to be written.
4. To accommodate a margin of error in the rough description and estimates, teams share a project “ready window” of time in which they expect to ship. The leading edge of the ‘ready window’ is a best case scenario. The trailing edge is worst case. This ‘ready window’ allows the business to move forward with its multi-quarter revenue and marketing plans, and is something teams keep a close eye on when grooming their roadmaps.
5. Scope Check #2: When the time comes, teams break down the initial “idea doc” into epics and stories. This creates an inherent check­point for the teams to *compare the original idea doc with the resulting project description (story backlog). They are also able to confirm the ‘ready window’ is still reasonable. We hit our ‘ready windows’ because the project teams work collaboratively with stakeholders to manage projects into the ‘time box’ they created – the same time box the business approved. This second check­point was entirely missing before.
6. Teams begin construction, measuring their progress delivering the project backlog.
7. The total size of the backlog, in points, divided by how many points the team delivers (and discovers) per sprint reveals the actual duration of the project.
8. Scope Check #3: The duration of the project is depicted in the project level burndown (aka burn-up). **Teams cross-check the completion date from their burndown with the ‘ready window’ given earlier and adjust as necessary. This may include negotiating scope, schedule and resources with stakeholders through the meeting cycles described above.

Steps

Use your favorite three­-letter acronym to describe the list of must-­have features for the project (FRM, BRD, PRD, SOW, Epics…). Teams should be able to agree on the format and granularity. The goal is to provide detail where necessary but don’t sweat the obvious yet. This represents an agreement between stakeholders, product and development about what the project encompasses. Everyone has a vested interest in getting this right.

Review the idea doc with the author to roughly assess the duration of the effort required. In this example teams got together and collectively assessed they would need 42 days across three teams to deliver the project.

This is where agile teams manage their slice of the roadmap. Once sized by the teams involved, the various roadmap stakeholders assess the impact the work will have on their respective roadmaps and greenlight the change (or not). Once greenlit, the scrum master for each team updates the roadmap/resource map for his/her team to reflect the staffing scenario that was greenlit. The decision is formally captured in the teams’ weekly roadmap steering meetings which serve as a change control for a roadmap.

An example of a project where two teams (all names changed) have time boxed their resource maps to deliver one project I’ve renamed ‘Foo’. The example above shows 10 day (2 wk) sprints by project, by scrum team, then team member. The values shown are months. A 10 day sprint shows as 0.5 months. The teams reserved 24.25 months to deliver Foo. This 24.25 months represents the net investment stakeholders have justified for project Foo. During construction stakeholders remain informed of how this 24.25 month investment is changing and continuously sanction or stop material scope changes before they happen.

With the project greenlit, the project sits in the roadmap/resource map, its time reservations protected while waiting for construction to begin. An unfortunate lag occurs between sizing and construction which burdens the team with context switching. I argue the alternative is even more costly. Again, business leadership simply must have a 6-­12 month outlook. If we don’t provide it they will be forced to invent it.

Construction begins with the initial idea doc being decomposed into a detailed backlog of stories and epics. In the process the team quickly gets a notion of whether or not the detailed work agrees with the time­box they created in their resource map. The team self­-corrects by comparing the detailed backlog with the initial idea doc to keep the work and features in line with expectations.

During construction the team closely monitors the rate at which it delivers points, i.e., velocity.

A key component of duration, one that I find to be overlooked regularly, is what I call the ‘discovery rate’. During construction and demos, the team learns things about the project they could not possibly have predicted at the start. This work is added to the backlog. Equal to measuring story points accepted in a sprint, it’s critical to measure the rate at which the backlog grows during each sprint. While agile tools typically highlight and report the error rate on engineers’ time estimates (sometimes calling it ‘estimate accuracy’, which I find unfortunate) I’ve not seen any that trend the growth rate of points in the backlog.

It’s a profound mistake to declare “We have 100 points in our backlog today. We deliver 20 points per sprint. We will be done in 5 sprints.” And we can do better than to say “We’re adding one buffer sprint.” That makes me ask, “Why just one? Should it be two? What’s missing is this insight: “…we also discover 4 points per sprint on average, so over the course of 5 sprints we expect to discover another 20 points of work. That brings our total backlog to 120 points, or 6 sprints.”

The burndown is a graphical representation of the backlog being reduced over time. When fed properly its trendline points to the completion date of the project backlog. At this stage the team will cross­check that the actual project burndown is pointing to a date inside the ‘ready window’ they provided months earlier. If it isn’t, the issue comes up in the project steering meeting. Any number of solutions could be put in place. If the problem is beyond the team’s control they craft a list of available trade­offs for stakeholders to use to realign the roadmap with reality. They can add resources, cut scope, push out later projects, etc.

In this way, our teams slot projects into their roadmaps months in advance, share ‘ready windows’ for each, and actually ship within those windows at a remarkable rate. For those that don’t, teams renegotiate schedules with stakeholders well in advance of missing expectations.

Conclusion

This approach reconciles the need for long term roadmap forecasting with the inherent flexibility of agile development teams. Roadmap stakeholders gain awareness of changes relevant to them and are given the opportunity to review, stop and/or sanction material changes before they happen. Agile team members gain oversight of their roadmap commitments coupled with a strong sense of ownership for the roadmap – their roadmap! This process yields a living resource map because teams need to track who’s-doing-what to ensure their own team, and partnering teams, have enough people and time to deliver. This process transformed my roadmaps from dangerously deceptive ornaments into the foundation of our enterprise-wide software portfolio management and hiring plan.

The roadmap is not maintained by a handful of spectators. It is captured and updated by the scrum masters in each team through the course of their regular planning efforts. As the chief consumer of this data I am aware the resource map changes in miniscule ways almost daily as teams exchange scope with each other, discover work, drop work, and adjust schedule agreements with partner teams.

The vast majority of these updates do not impact final delivery and therefore do not surface in roadmap steering meetings. The teams themselves require the detail to understand what future work they can accept into their their slice of the roadmap, just as they need to understand what work can fit into their sprints and release plans. When a change does impact a roadmap level commitment the local team is the first to know. In their weekly project steering meeting the team scrubs their impact assessment and menu of trade-off decisions for stakeholders. A negotiation between the team and stakeholders ensues. Stakeholders select a trade-off which is then captured in both the roadmap steering meeting and project steering meeting minutes. Teams update their slice of the roadmap accordingly.

And the roadmap lives on.

Name(required)

Email(required)

Website

Comment(required)

Submit

Δ