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


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.



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.

SizedReview 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.


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.

Agile PMO


  • Scrum teams suffer when the businesses roadmap expectations are false exactly as they would suffer from false project and/or sprint expectations.
  • Scrum teams have the most accurate knowledge of their own progress and availability
  • When folded into the agile process, scrum masters maintain an extremely accurate roadmap plan (resource map) exactly as they manage project plans and sprint plans.
  • When captured in a common database, the resource maps from any number of scrum masters can be aggregated into an enterprise-wide map suitable for reporting capitalizable labor, capacity analysis, portfolio trade-off decisions, and others. This paper presents just a few examples.

Agile development has improved the ability of development teams to deliver software predictably. Yet, for all of agile’s success at the team level, there’s been no equivalent prescription for how to instill the same predictability, reliability and transparency at the program and roadmap level.


I’ve been a project manager since 1992, delivering enterprise level projects since 1997, a scrum master since 2005, and a PMO director since 2007. Over the last four years I have pursued the challenge of mapping the core elements of agile development into roadmap management. The result has been an Agile PMO process that yields a continuously accurate roadmap and resource map suitable for making enterprise-wide trade-off decisions. This process delivered the annual roadmaps for a start-up company until its successful acquisition and has since been adopted and scaled across the billion dollar acquiring company.

Specifically, in the course of tracking project and program status, the agile PMO process yields a continuously updated resource map reflecting engineering capacity spent, committed and planned for the year, per project, down to the level of each developer per month. Surprisingly, the added effort to keep the resource map accurate is negligible because the data is updated only when it changes, and the work is broadly distributed across the many individuals who are already tracking teams’ progress at the most detailed level: the scrum masters.

The core of the agile PMO process is to empower the scrum masters, those most familiar with teams’ progress and availability, to track, update and broadcast the roadmap obligations for their teams. Each scrum master manages the resource data for his/her team only. When aggregated the data rolls up into an accurate enterprise-wide view of the enterprise roadmap.


Agile teams already engage in three levels of planning. From most to least detailed these are 1) daily scrum planning, 2) sprint planning and 3) project level (release) planning. The agile PMO adds a fourth level of planning: roadmap planning. With all levels of planning co-located inside the team there is instant awareness when a conflict occurs. For example, a project given three months of development time on the top-down roadmap may elaborate into a six month, highly detailed bottoms-up release plan. Knowing this violates their downstream roadmap obligations the team quickly surfaces the three month overdraft in the form of a trade-off decision for the business to reduce scope by an equal amount in either the current project, future roadmap projects, both, and/or secure additional resources. The team then updates their resource map/roadmap based on the business decision.

In this way the roadmap is a living document that team’s rely on to manage their delivery expectations for the year. As a by product, when aggregated, team’s resource plans provide the enterprise with the most accurate portfolio view possible. It’s important to stress that, in the agile PMO, teams rely on resource maps for their own success.

The agile PMO revolves around a very popular, economical, software development tracking tool with a customized workflow and fields able to display data in real-time across the enterprise wiki. In this way, the various meetings to scrutinize roadmap information are certain to review live data and, when making updates in a meeting, share the updates instantly across the enterprise.

The figure below shows how a single project appears on screen to the team managing it. Note the status is ‘RED’ because the team requires intervention from stakeholders. Specifically, the detailed project work breakdown has exceeded the time allocated for the project on the roadmap requiring the roadmap stakeholders to make a scope trade-off between this project and the remaining roadmap.

tracking ticket

Tracking ticket in the “PMO” project

The data captured in the tracking ticket above shows the who, what, when and how long of the project. Filter and export fields to wiki pages for specialized meetings that focus on certain projects. For example, only projects with status yellow or red, as in the example below.


For enterprise-wide reporting, we access JIRA’s native APIs to trigger a saved query that stores its contents locally for reporting. (The fastest hack is to display the necessary data as a table on a wiki page using the ‘jiraissues’ macro, then use the ‘get external data’ function in MSExcel to fetch that table’s contents for reporting in Excel.)


Any number of reports become possible. This example uses MS Excel. The examples below show different views of the roadmap for only one department of many, composed of several teams with a total annual capacity of 294 person months. The reports that follow show different views of the departments resource map which all sum to 294 person months.

Resources By Dept




Scrum Monsters

One reason I hate traditional PMO is because they got in the way (notice this is past tense ;) They would sporadically insert themselves into the deeply complex conversations about what’s really going on, assume to understand it, then send some garbled message to higher-ups that only further burdens the Dev teams with the task of unwinding it. Painful.

As a process guy the logical observation was to just cut-out the middle man, which I have done. On my team I dont have 3 layers of “governance”: scrum master, project mgr and PMO. I fold all that into one role I call the Scrum Monster. Those who know best manage the distant roadmap projects for just their team(s) in a collaborative data space, not some outsider with unrealistic dates. In this way I get a living resource map, rolled up enterprise-wide, from those who know best.

Traditional scrum masters engage in 3 layers of planning: daily scrums, sprints and release plans. I add one more layer: the roadmap for their team. Scrum Monsters manage the roadmap expectations of their teams exactly as they manage expectations for projects and sprints.

Rule Your Roadmap – No Matter How Much It Moves

Here’s Atlassian’s video of my talk at their 2011 International Summit where I describe how v1.0 of how to capture your roadmap data in JIRA and the kind of collaboration required to keep that data sufficiently accurate to support project and resource trade-off decisions. (We’ve come a long way since then and are still kicking it!)

I’m really interested to know if this is transferable and I’d love to help people try.