Agile Estimation Challenges: Real but not insurmountable
Estimation is a paradoxical challenge for Agile at all levels, team, grouping, portfolio, organization. If you take a step back, agile’s fundamental benefit is reducing the timebox for planning and execution to the iteration (1 to 2 weeks typically). By reducing the timebox to such an increment, forecast predictability (estimation fidelity) is increased because the breadth of knowledge required by team for the SCOPE to plan and execute is reduced. \
Furthermore the team, leverages expertise as a group to estimate through the backlog refinement and iteration planning team events. The scale is small and it is intentional because the agile team boundary size (5 to 10) and timebox boundary constraints (10 days) are small.
Necessarily though, organizations have to plan and forecast on larger bodies of scope and longer timelines for many valid reasons including alignment, collaboration, competitive performance and so forth. So how do you estimate and forecast work for tens or hundreds of agile teams for 3 to 9 or 12 months at a time?
At the team level, the benefits of using of Story points are well established. They are called Story points because they are about a SMALL user story that is being looked at by a team of individuals for a short time frame of 2 weeks.
So how do you estimate a feature that takes say 12 weeks or three months? The real process question is WHO is doing the estimating.
If the feature is being estimated by the SAME team that will do the eventual user stories, you can make the case that the local knowledge of the scope and team’s capabilities will intelligently inform the estimation therefore using story points is defensible.
If the feature is being estimated by persons OTHER than the team that will do the work THEN that is when the process breaks down. Now you are violating a key agile principle that people closest to the work estimate the work.
Can’t you establish a corporate wide standard that an XL Feature is say 75 points and a Small Feature is 20 points? Well you could but it would be meaningless. This “standard” assumes that everyone everywhere estimates differing scopes in the same way without regard to team demographics. That is bad assumption.
So how does Product Management size a 12 month roadmap with 10 Epics, 45 features? There are NO user stories to size. There are no TEAMs yet assigned. That is a difficult question and each organization has to settle on what works for them.
The most “agile” way to do that is to use planning interval (PI) timebox boundaries as your relative sizing end points. If your Feature takes an entire PI to complete, based on Product Management team knowledge, it is appropriate to set that as extra large (xl) or large (s).
If your Feature takes an entire Iteration to complete, based on Product Management team estimation, it is appropriate to set that as extra small (xs) or small (s). All other features can then be relatively sized by the Product Management team
But this “estimation” is more forecast than estimate and should be considered as a TEMPORARY INITIAL input to PI planning.
At PI Planning, the tension between unlimited marketplace demand and limited capacity is addressed as teams and trains meet to take FORECASTS and turn them into actual estimates for the near-term 12 weeks. The results of PI planning ripple upward to the Product Management Team and helps them refine the roadmap sizing with ACTUAL informed estimates because the teams are now doing user story sizing and estimation focusing on committing to work within a timebox.
In the end, using Story points for estimation features is viable but only in limited scenarios.
Tony Timbol
Tony.Timbol@agileready.net
Try the FreeSolo Plus One free subscription, full functionality available at
