High-Level Estimation

28 ap-high-level-estimation

Agile portfolio management requires new lightweight approaches to work estimation and capacity forecasting so that intelligent Go/No-Go Decisions can be made without costly planning exercises.

Explore More.

Related Mindset:

Lean-Agile

Segment:

Agile Portfolio

Inputs:

Portfolio epics and team capacity assessment

Outputs:

Size and capacity assessment for Go/No-Go Decision

Successful organizations have portfolio management procedures in place to ensure that large new work items, represented by Epics, are properly evaluated before being selected for implementation by one of the Portfolio's Programs.

Among the criteria needed to make a Go/No-Go Decision on an Epic are a rough estimate of the work involved, and a high-level implementation plan including an assessment of teams’ capacity for doing the work.

In the past, estimating new work often meant exhaustive requirements analysis and story decomposition, with team-level sizing exercises that could take days or weeks. This level of estimation is overkill if the goal is only to determine whether a particular Epic’s value proposition is sufficient to send it to teams for implementation. Is a particular Epic something that can be done with existing teams in a month? A quarter? Or is it a year-long effort that might require substantially new staffing?

A better way to answer these questions is to use relative “t-shirt sizing” to compare Epics against each other for the purpose of prioritization using Weighted Shortest Job First or similar methodologies. The same way Story Point estimation allows for capacity planning at the Sprint level without requiring detailed work breakdown estimates, relative point sizing can be done at the portfolio level to help provide guidance on level of effort.

As with teams at the Sprint level, relative size metrics like points are not necessarily helpful unless they can be correlated with a particular capacity metric like velocity. At a program or portfolio level, historical velocity data can also be used to determine how long an Epic with a particular t-shirt size might take for a team of a given size, by rolling up stories and features from past Epics to come up with rough guidelines for new Epics.1

For information about high-level estimation within the Scaled Agile Framework®, review the following abstracts:

Common Pitfalls

Organizations can encounter a number of problems with using High-level Estimates to guide decisions:

  • Holding teams accountable to High-level Estimates: T-shirt sizing and roll-up exercises create the risk of an unintended point-solution waterfall mindset wherein executives hold teams accountable to the estimates made at the Portfolio or Program level.
  • Decomposing Epics too soon: Epics at the Portfolio level represent the outermost reaches of the Cone of Uncertainty thus are not yet sufficiently decomposed for meaningful point-based size estimation. For this reason, it’s tempting to invest in initial story decomposition during the estimation process. This may end up being wasted effort if the Epic turns out to receive a No-Go Decision later.
  • Assuming that teams are interchangeable for estimation purposes: Just because one team has been able to deliver a “Medium” sized Epic in a given amount of time in the past doesn’t mean that a different team could do the same in the future. When taking historical velocity into account during estimation, it’s important to consider variables like team cohesion and experience levels that may differ if a different team took on the work.

Tools

There are multiple tools that can be used to track estimates and provide historical velocity figures. At Universal Mind, we would recommend the following tools:

References