Agile Roadblocks: Predicting the Unpredictable


Agile Roadblock

In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Predicting the Unpredictable”.

One reason behind the success of agile methodologies is a new approach to estimating work.

Traditional estimations fail of at least two reasons: they are based on calendar time, and they are done for the complete project directly.

In addition, estimates are sometimes calculated by people other than the ones that will do the actual work. How's that for commitment?


Estimating in calendar time is difficult because your calendar time is not the same as mine. In addition, it is virtually impossible to predict what other things will interfere with work: meetings, unforeseen problems, illness, vacations, and so on.

When estimating in calendar time, a coefficient is often applied to adjust for the fact that people do other things (and for bad estimations). Sometimes it's called efficiency coefficient to really boost productivity.

Trying to achieve accurate estimations for a complete project during the planning phase is often futile. Things happen throughout a project affecting estimates. The cone of uncertainty illustrates this. In the beginning of a project there are simply too many unknowns for any accurate estimations to be done. 

Cone of Uncertainty: estimation accuracy increases as project evolves

Scrum advocates relative size based estimations. This works because:

  • It is easier to estimate relatively, compared to absolutely. Think about it: it's easier to estimate the speed of two cars relative to each other, than to say that one car moves in X mph and another one in Y mph.
  • Size is person independent. Usually, people can agree that one work item is bigger than another one.

When estimating relative size, you can still give estimates about when in time work will be completed. (Probably as risky and unpredictable, but still.) The time to finish is derived from a team's velocity. The difference from estimating in time directly might seem insignificant but in fact there’s a huge difference. When you estimate you keep time out of the equation. Instead, the time to finish is determined empirically as the team starts to work. Not by qualified guesses in the planning phase.

Estimating in relative size also means estimations are correct even if the team configuration changes. If velocity changes, the estimations still don't have to be adjusted. Only the finish date is affected.


  • A lot of work goes into re-planning, and to explain why the original plan failed (which everyone should have realized it would from the beginning).
  • Quality is overlooked to meet deadlines.
  • A false sense of knowing when the project will finish.
  • Team members are not committed to estimates.


  • Estimate size rather than time. If you really have to, compromise by using ideal days instead of story points.
  • Educate on why relative time estimates work, and remember that using them doesn't mean you can't predict finish dates.
  • Make sure the team members participate in estimating. Not only will it make them committed, they will likely give the most accurate estimations as well.

1 comment:

  1. Agile is more like a way of understanding things in the best possible according to what i have learn.
    agile business intelligence helps us with thinking of things in a better and more impressive way.