Like it or not, estimations are a big part of professional and commercial software development. Estimations are used in most projects regardless of methodology: Waterfall or Scrum, traditional or agile, every stakeholder needs to know the numbers. Projects succeed or fail as a result of these. Unfortunately, humans, as a rule, tend to suck at estimating.
This post will compare and contrast the different estimation techniques and applications used by both agile and non-agile methodologies, and explain how to use them (and not misuse them), particularly in a Scrum project.
What is Wrong with how We Estimate?
Traditional project plans involve using calendric estimates in order to synchronize the development efforts of the team(s) by placing the work on a time line (usually, using a Gantt chart). This means that for every part of the solution, the developers must predict the when it will be ready (i.e. the delivery date). This means they need to know when they will start, how much time it will take to deliver the work, and how much time will be “wasted” on impediments (both foreseeable and unforeseeable). While knowing this makes the project planners’ work easier, obtaining this knowledge is extremely difficult; Estimating the development effort is difficult enough, but predicting the total amount of time that will be spent not developing is near impossible.
What’s worse, is that contrary to popular belief, the Law of Large Numbers does not apply to project plans! Due to the nature of dependencies, a single late dependency is enough to push the delivery date of a dependent component. On the other hand, in order for a component to be delivered early, it is necessary that all dependencies will be completed early. In short, lateness aggregates, while earliness does not.
A side effect of this is that the more complex the Gantt based project is, the more lateness is likely to be accumulated, as the project advances, and the further we are in the project, the more we run the risk of being late.
Of course, a late project means that the software is delivered at a higher cost, with less features, and / or simply later than expected and agreed. This means that a late project often becomes a failed project.
Clearly, a different method of doing things is necessary; Agile methodologists came up with different estimation techniques to reduce the chances and ramifications of failure.
Agile Estimations Are Easier to Make
The three most common agile estimations are T-Shirt Sizes, Ideal Time, and Story Points:
- T-Shirt Size estimations are coarse grained separation of requirements into buckets of small, medium, large, or very-large efforts. This estimate is of course extremely easy to make intuitively, and of course insufficient as a basis for project planning due to its low resolution, but is often sufficient for the purpose of pricing single features (example scenario might be when required to give a customer a cost estimate for some custom feature in the system).
- Ideal Time estimates are similar to calendric estimates in that they involve high resolution predictions of the effort involved in developing a feature. The difference is that ideal estimates are made while ignoring all surprises and interferences! The question that ideal estimates answer is “how much time will it take to develop a solution, assuming you work on nothing else, and nothing else disturbs you”. Taking the unknowable impediment factor out of the equation improves the accuracy of the estimates, but you can’t simply substitute ideal time for calendric time because the unknown impediments still do exist, and the fact remains that humans aren’t good at making absolute estimates, with no point of reference. In Scrum, Ideal Hours are often used to estimate the effort of completing tasks, which should be short, simple and straightforward.
- Story Points are a radically different method of estimating development effort. With story points you do not go out and say how much work something is, in and of itself, but rather state how the effort to develop one component compares to the effort of developing another. These estimates are much easier to make, and surprisingly accurate because we are much better at comparing things than estimating them. Of course, comparisons and relationships have no unit of measure, and thus can’t be used to establish a timeline. At least not in the normal sense. In Scrum, Story Points are usually used to estimate the effort of completing user stories (hence the name).
Agile Estimation Techniques Make Better Plans
While agile estimation techniques tend to end up more accurate than calendric estimates, the estimations are still guesses, and guesses still mean risk. Agile teams try to reduce this risk by reducing the amount of guesswork involved in the project plan.
Classic project plans involve estimating the time it will take to deliver each component, and add up all the estimates to create one big guess-of-a-plan. While agile project plans involve estimating the work on each component as well, that is where the similarity ends.
The agile project plan is not based on the prediction of work effort, but rather on empirical evidence! Only the team’s first iteration (ever) is planned based on a prediction. The rest are based on the measured evidence of previous iterations (or sprints, as they are often called in Scrum-shops). The team estimates that it will successfully complete as much work in the next iteration as it did in the previous iteration(s).
For example, if a team successfully completed 120 ideal hours worth of work (that is, the amount of work they did added up to what they estimated as 120 ideal hours), then they will estimate that they will do the same in the next iteration. This technique works the same with story points: A team that can complete an average of 50 story points in an iteration is likely to repeat that success in the next one. A team’s velocity, or cadence can then be measured in ideal hours per iteration or story points per sprint.
What about interruptions? Well here’s the beauty of the technique: You can consistently account for the predictable ones (e.g. vacations, repeat meetings, scheduled events) and factor those out, and you can consistently ignore the unplanned ones, as they are likely to be more or less an equal part of every iteration of the team.
Where’s the Difference?
The difference between predictive plans (classic, waterfall-ish, Gantt based) and empirical plans (Agile, Scrum) are:
- Predictive plans are based on more estimation (i.e. guesses, i.e. risk) than empirical ones
- Empirical plans have an increasingly sound statistical ground as the project progresses
- Predictive plans have an increasing chance of running late, as the project progresses
- With predictive plans the unknown factors aggregate, with empirical plans they cancel each other out.
Finally, as stated in the previous post, agile plans, being based on stories that are designed to be discrete units of business-value, with as little interdependencies as possible, agile plans further mitigate the risk of estimation failure by causing the ramification to be failure to deliver on time only the least valuable features!
To me, the agile choice is a no brainer. Agile plans are simply safer to execute, the chance of failure is lesser, and the result is less harmful. I would even go as far as to say that companies promising to deliver a non-trivial project without using an agile plan of some sorts are being less than honest – with themselves as well as the customer.
Moreover, I think it is high time that customers demand their contractors to use agile methods in order to win contracts.
Thank you, this was really helpfulReplyDelete
That is why you studied about numbers when you were still in school. Anyway, going to back, we all need to be accurate when it comes to estimating. One mistake, all will failReplyDelete
@Maxwell - I'm not sure I follow; what is the reason we studied about numbers, and why - and more importantly, how - do you think we can be more accurate when estimating?Delete
Accurate estimations really seem like an oxymoron to me, as long as I don't have a good and working crystal ball.
If your reasoning is that we need accurate estimations because that if we make one mistake all will fail, then I think you proved exactly why we shouldn't use or rely on them in the first place!
Spot on with this write-up, I really believe this web site needs aReplyDelete
lot more attention. I'll probably bbe returning to read more,
thankks for the info!
Stop by my wweb blog: Online Training Software
Αn outstannding share! І've jսst forwarded tɦisReplyDelete
onto а coworker whο was conducting а little гesearch оn thіs.
Annd he in fact bougt me lunjch ƅecause ӏ foսnԁ it
for him... lol. Ѕo let me reword thіs.... Τhanks forr the
meal!! But yeah, tҺanks for spending some time to talk аbout thios issue ɦere on youur site.
Alsо visit mү web blog; facebook
Thank you for sharing your information with us. This post is really informative and the look of your web also great.ReplyDelete
I think the high level estimates must be made before the sprint planning meeting itself. This gives product owner the ability prioritize and take decisions better and at the same time reduce time taken during sprint planning meetings on what needs to go into the sprint backlog from the product backlog ....Nice blog on Agile estimation & planning ..keep writing.ReplyDelete
Hy ... Very awesome posts here. I like this post very much. I really appreciate your hard working. Thanks for the sharing with us.ReplyDelete