The importance of estimating

I often hear business managers reject agile processes because they cannot accept vague estimates. These same managers are usually surprised to  learn that agile estimation is far more accurate and disciplined than traditional methods.

Some of the misconceptions stem from rogue developers (or teams) who refuse to be pinned down to an estimate – often out of fear of the repercussions of getting it wrong. As a business manager – or product owner you have an absolute right to accurate estimates. You need to plan accurately, evaluate your business case and ultimately commit to spending the money. Scrum provides a solid mechanism for providing these accurate estimates.

This article makes no attempt to explain how estimation works because that is covered in lots of places. Instead it will try to provide some tips for accuracy and highlight some common pitfalls.

You can’t estimate what you don’t know.

Gut feel doesn’t work. I have often been asked to estimate a project on the basis of a one paragraph description on the basis of my experience. Sorry but I can’t do that. It doesn’t matter whether you are in an agile environment or not. Equally it is not possible to accurately estimate based on part of the requirement with the rest of the details to follow once the project is underway. If its important enough to require an accurate estimate, a business case and funding its also important enough to spend time, effort and money to establish the product backlog and get the estimates right.

Very often a major project justifies a separate initiation project to establish these. And why not! In the days when I was a consultant for a large waterfall based organisation it was fairly common to provide a quote for the specification and estimation process and only deliver the development estimate once this had been completed.Just because Scrum doesn’t require big up front design doesn’t absolve us form the responsibility of understanding what it is that needs to be done. Sometimes this is referred to as sprint zero, with the objective of this (non) sprint being to deliver the product backlog, estimates and release plan. Those who advocate the sprint zero concept generally agree that this should be shorter than a usual sprint. Great for small projects but if that’s not enough then a separate project may be warranted.

Tackle the risks early

Often we hear scrum practitioners talk about commitment based planning. In essence this means asking the team to commit to what they believe they will achieve in the first sprint and using this as the starting velocity. This can work if the team is established and the work is familiar. It is not feasible when the work is unfamiliar or we are proposing to use different technologies or platforms. The only way to establish an accurate velocity projection is by doing some of the work. This can be undertaken as part of the initiation project or sprint zero and should be planned and budgeted.

Recognise the difference between an estimate and a commitment

Failure to do so inevitably leads to padding. New requirements may emerge, external factors may change or we may simply have got it wrong (especially if we tried to short circuit the estimating and planning). Part of the Scrum process is the concept of insect and adapt. This also applies to estimates and projections. My own experience has been that by the end of sprint 3 the velocity can be established and the burn down projection is pretty accurate. It is vital to inspect and adapt after every sprint. If your velocity is way off expectations now is the time to say so. It would be foolish to believe that you can pull it back by working harder. The beauty of tracking velocity is that it is based on actual achievement, and if that is different to what you expected you should highlight and plan around this early.

This is one of the real benefits of using relative sizing and estimation based on functionality rather than activity. In traditional waterfall approaches the first activity would be specification. What does it really mean if this overruns by 50%? Do we adjust the entire project by 50%? This is not really valid because there is no relationship between the size of the specification and the rest of the project. Or do we just assume that everything else is going to work to plan. Equally if the specification is completed exactly on schedule this provides no indication of how the rest of the project will go.

If we use relative sizing we can accurately forecast the rest of the project based on current performance because the relationships remain constant.

What about contingency

This question will usually be asked by financial managers and those accustomed to projects exceeding budgets and / or schedules. Well what about it! Scrum estimates are based on how many story points the team can achieve in a given time. We know how many story points we have to get through. We know what the team can achieve per sprint and we know what the team costs to run. If the scrum disciplines are followed and we continually inspect and adapt the project should come in slightly cheaper than the original estimate. Why is this? Well, we assume the team works full time on the project. I am not suggesting that they don’t but the cost estimate may be something like this:

Cost of team per sprint (a)£5000

Number of sprints (b)26

Total Cost  (axb)£130 000

This does not take into account bank holidays, annual leave, sickness or time spent on other activities such as training, admin etc.

Remember the basics

Inspect and adpapt!

Scrum has no formal change control procedures because scrum itself is about managing change. When new requirements are added to the backlog we need to review our estimates and forecasts. Because we use a prioritised backlog to deliver the highest business value first this may be as simple as recognising that the items at the bottom of the list won’t get done. This is managed by the product owner. Sometimes this may not be possible and the time and / or costs may need to be revisited. We cannot regard the original product backlog and estimates as a contract and expect the ability to add requirements at will and have these delivered in addition to the original list at the same cost. (It’s amazing how many business managers fail to – or  choose not to – recognise this.)

Define what done means up front!

We want to avoid surprises. If the customer is expecting user documentation as part of the release and we are assuming that this will happen after we have completed our bit the product will not get released on schedule. This is just one example but one that often gets overlooked.