Agile Estimating: The Secret To Delivering On Time

For decades, delivering on time has been the holy grail of software development.

I’ve been doing agile software development for quite a few years now. I’ve seen many benefits, but one of the most remarkable things of all, is how so many teams can quickly get good at delivering on time.

It’s the art – and/or science – of predicting what can be delivered in a given timeframe, even if the same team was hopeless at estimating before!

This, for me, is one of the most compelling reasons to do agile development. Here is the secret:

  1. Estimate features, rather than tasks.
  2. Keep your estimates high-level intuitive guesses (don’t analyse the details).
  3. Estimate in points to indicate the relative size of each feature.
  4. Consider estimating using a number sequence like Fibonacci. Fibonacci numbers get less precise as they get bigger, which builds a natural distribution curve into your estimates.
  5. Estimate as a team. Consider playing Planning Poker to facilitate this.
  6. At the end of your Sprint (or iteration), score the points for all features you managed to deliver. Only score points for features 100% complete, tested and potentially shippable. This is your Velocity. Count zero for incomplete features.
  7. Track your Velocity over time on a graph. You can also track your Reliability, i.e. the number of points delivered as a percentage of the number of points committed to at the start of the Sprint.
  8. At the start of each Sprint, look back at your Velocity for recent Sprints to decide how much to commit to for the coming Sprint.
  9. Don’t try to reconcile points with hours or days.
  10. Commit as a team.

Like most great things in life, it’s actually very simple. That’s really the beauty of it. It seems a bit abstract, so many people might be retiscent to give it a try. I would urge you to try it.

You’ll need to give it several Sprints before you pass judgement on it. You will find your Velocity bounces all over the place for the first 3-4 Sprints. But then it will settle down, as your team discovers its norm.

Trust me, it works. I have seen it work in many different teams, time and time again. It’s a statistical approach to estimating. And statistically, if you estimate with relativity, everything is average in the end.


Originally published on

8 Responses to “Agile Estimating: The Secret To Delivering On Time”

  1. Tim Difford... says:

    Good post Kelly. People could do worse than spending £7.70 in the DSDM Atern Estimating Pocketbook –

  2. mukund says:

    Completely agree. The only difference is that I normally like the checkpoint to be relatively short rather than a looser definition of a "sprint". Since I am in a businss of being more deterministic, I also rate features in high, medium and low to allow for re-prioritization based on velocity to be built into the plan. One more thing is I correlate velocity and points with defect reports to confirm "shippability" and coveage on committed features for larger sized projcts.

  3. Steve says:

    Pivotal Tracker has all of the above, even Fibonacci scale:


  4. Vasantha says:

    I agree with the approach and do agree it will work if we give enough sprints to establish the team's velocity. One of the challenges I face is that we don't have those few sprints before committing.. the team is formed with a timeline in mind and sometimes if we are lucky we get to play a bit with scope but, more often the timeline and general scope are fixed and we need to resort to some sort of detail estimation and planning to line them up. But, the sprints execution and tracking velocity ultimately helps us in being more proactive and determining if we can make it or need to adjust one of the three – scope, people, timeline along the way

  5. Ray Claridge says:

    Good post Kelly – This is good advice on delivering sprinted work on time.

    Would be interesting to hear your thoughts on keeping a project on track.

    In fact you've inspired me to write a post over at

  6. Frede says:

    Good article, I have some questions though on your first item in the list.

    "Estimate features, rather than tasks."

    Developers must then break the feature into tasks because a feature can be huge in scope and could takes several months to complete. Estimating a feature that is big is hard, that's why it's divided into tasks in the first place. Stuff like upgrading your development environment or changing the basic data access layers are not something that can be measured in weeks.

  7. Robert says:

    The reason it is better to estimate features rather than tasks is that you don't normally know what the tasks are until you are part way through implementing the feature. The number of features in a project tend to stay much more consistent than the number of tasks – so it is better to extrapolate against them.

  8. Tim Ottinger says:

    People think that estimating is really key to agility, but it’s not.

    Your estimates can’t be sold to end-users. Your estimates don’t make the product more useful or usable. Regardless of your estimate, the work is going to take the same amount of time. Regardless of estimates, the same amount of work (more or less) is going to be done every week.

    Yet some teams spend an inordinate amount of time trying to gain precision and accuracy in estimating, as if that would make them more competent or improve their market position.

    My secondary secret is not to take estimates so seriously. Do them if you must, but keep them loose (as Tom DeMarco said: as likely to be long as short) and don’t treat them as promises.

    My primary secret is to slice stories so thin that you can complete many of them inside of a sprint, and return the options (defer, abandon, grow, switch) to the customer/PO/whatever.

    I don’t know that becoming an expert estimator will give you any benefit over someone who delivers all the time. So you make choices.

Leave a Reply

What is 1 + 8 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)