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 10 + 9 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”