Roadmapping & Budgeting w/ Rapid Estimation

Organizations tend to do strategy top down and they tend to do that uninformed about organizational capacity and dependencies. A primary cause of an organization’s lack of predictability, lack of quality, all the problems they have, is the inability to balance capacity and demand. Another is the inability to identify and manage dependencies. The portfolio team has to be able to participate in this discussion: What is the capacity of my system? What is the performance of my system? And how big is this piece of work? To be able to answer those questions, we have to be able to very quickly tell them about how big something is from an org capacity standpoint. Importantly, we have to be able to do that without redirecting the whole org to create an estimate. We have to get good at taking ambiguous requirements and translating them into chunks that we can meaningfully size, even though we have very little info — rapid estimation. Then we have to help the business make decisions about what big things to push into our capacity.

When the business can’t reason about the capacity of the system and the size of work in the same units of measure, they just shove stuff into the system and make commitments without any reliable indication of the system’s ability to deliver on that commitment.

What Doesn’t Work

Some organizations deal with this by disrupting current work to pull bunches of people into estimating these big chunks of work. That may get them an estimate of the demand, but they still don’t have a good means of understanding or reserving capacity. The estimate is only half the equation, and the approach is disruptive to the flow of current work. It worsens the lack of predictability by interfering with near term commitments.

What Does Work

To combat this, we can design organizations around capabilities or products. This makes the capacity and demand conversation more effective. If my org is designed around products or capabilities or platforms, and my demand and strategy are mapped to products or capabilities or platforms (i.e. the same way), it is a much easier conversation to have. The idea is to create capable cross-functional teams with everything they need to deliver working-tested-remediated business value. And we dedicate a product manager to this team or small set of teams.

The unit of measure is a team-sprint, or maybe a team-month. Not, so many hours of Fred, this many hours of Sue, that many hours of Jack, and on and on; a jigsaw puzzle of people partially allocated to lots of projects. We want to form capable teams so that we can give the team, or a small number of teams, a whole epic. We want to schedule work to completion, limiting a team’s WIP to one epic at a time. We want to be able to say it will take that team 2 months, or 3 sprints, to implement this epic. The whole team. Not 70% of Fred, Sue and 50% of Bonnie. If an epic is always 1, 2 or 3 team-months, reserving capacity on the roadmap is easy.

Who Can Do This?

The skillset we need up front is someone with the ability to rapidly translate ambiguous requirements into some sort of a forecast or a budget, expressed in terms of consumption of team capacity, in that whole-team unit of measure. This individual (a tech lead perhaps) and the product manager needs to have a few conversations about the problem being solved and what the solution space looks like. Additionally, they need to capture valid thinking on approaches, at an appropriate level of fidelity, for how the org is managing optionality. This is the time to draw some initial visual specifications. (And this is the time to identify dependencies.)

Therefore, this skillset is some sort of technical leader on the team or in the organization. This person has to understand the internals of the application and architecture. He has to know the team well enough to be able to say “yeah, I think it’s going to take the team two months to do this epic.” He can think through the work that will need to be done and estimate relative to other epics. Sometimes I’ll call this rapid estimation a SWAG. For this to work, teams have to be stable and predictable. Of course, these big chunks of work have to be reasonably sized. They can’t take ten teams and six months. These Epics need to be split into something more like 1 to 3 months.

How Do They Work Together

At this point, the product manager might say she doesn’t want to spend that much. Then she and this tech lead will discuss options and how to constrain the solution to fit within an acceptable budget. BUDGET instead of ESTIMATE at the roadmap level. Your estimate BECOMES your budget. Make an estimate as best as you can, comparing relative sizes of epics and historical data. Then commit to that. This product owner team has to manage scope and options to stay within that budget. Yes, they are committing to work and schedules on behalf of the delivery team, but it’s evidence-based (given the stable team’s stable velocity). Also, the idea is not to hold the delivery team’s feet to the fire, but for the product owner team to manage to their budget.

Instead, we must first understand capacity and demand and then make good economic choices. We converge on our budget. We converge on a solution (scope) that is within the budget that meets the original concept (but likely not 100% of the exact original details).

For this to work, the tech lead and product manager on this product owner team need to know each other well and work closely together. And they have to know the delivery team very well. You may need other people on this product owner team, like SMEs and project managers. The tech lead must evaluate and improve his rapid estimation skill. Feedback comes as soon as the epic is decomposed into stories which are estimated in points. An epic SWAGed at two team months that turns into 60 points of stories with a team velocity of 20 was SWAGGed about right and leaves some wiggle room.

Tracking The Promises

We want to be able to track the things we’ve promised and reserve the org capacity for that thing. A roadmap works well for this. The roadmap should reflect your planning and commitment horizon. For some, that might be six months, for others, it might be 18. Once given the rapid estimate, we can slot the epic on the roadmap. This rapid estimation is a key aspect of the product owner team’s responsibility to balance capacity and demand. That’s the only way an epic should get onto the roadmap. That’s the only way to make a promise that can be kept.

Now we can have conversations like “I don’t have the capacity to build all of that stuff that you want there, but within three months I could … is it worth building more capacity for this?”

The question to ask is how ‘predictable’ you need to be, not how ‘Agile’ you need to be. Agility comes from being able to change direction when needed, not making it up as you go.