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.