Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Parallel Empirical Estimation  Parallel Empirical Estimation   Estimation Prototyping   Estimation Prototyping

Manage   »   Estimation   »   Breakdown Estimation


There is another project estimating technique called Breakdown Estimation. To arrive at an estimate using this technique we decompose the project into its constituent individual parts which are estimated and amassed to arrive at the final project estimate.

This technique is also known as bottom-up estimating. It is often said that this technique is the most accurate estimating technique as the process of project decomposition uncovers more of the exact details of the project. By uncovering more of the finer project detail it is argued that such an estimate is more accurate because there is less opportunity for surprises to occur throughout the development. Furthermore, by exposing the detail it is also argued that a deeper understanding of the impact and dependencies of a project is derived.

We have reservations about the recommendations and guidance surrounding this estimating technique. It cannot be disputed that Breakdown Estimation will likely deliver a much more representative estimate for the purposes of a project operating under a waterfall model. However, in the Toolkit we look at agile based projects and it is here where the argument in favour of Breakdown Estimation, we feel, fades somewhat.

The recommendations and guidance surrounding this estimating technique assume that the estimator looks at the very lowest detail of the project and its components. This cannot be the case though with an agile project. The agile process allows the agile team to organically and routinely change the path and focus of the delivery as it progresses and re-assesses the extent of its delivery and the relevant priority of its deliverables. Therefore, the detail of the next phase is likely to have a manifestly transformed shape and depth to the one originally planned for that phase.


It is the very crux of the benefit of an agile process that it permits and in fact encourages this level of responsiveness, adaptability and modification. This responsive behaviour means that the estimate itself needs re-evaluating and revisiting periodically. But we feel it is important to emphasise that the Breakdown Estimation technique is only relevant to agile projects, in so far as it applies to agile projects at all, at the high level of the project.

There just is not enough time to re-examine detailed almost sub atomic components with the regularity needed in your agile projects. There is really only so much detail an estimator can review, reassess and present. In this time, your project will have had time to alter and morph and move on yet again. As the project checks and readjusts itself, it does so faster than the pace of detailed estimation and the latest estimate gets quickly out of phase and the estimation process starts to play belated catch up.

This is not what you want and is more than likely a waste of very valuable time and effort. There are though instances where you will be asked to estimate in this way and almost universally it is within a service managed project. In these types of project the customer is often very large and used to being presented with detailed estimates. These are estimates the customer likes to assess and explore to see if there is wiggle room for price negotiation and manoeuvre. If you are charged to deliver such a project with such detailed estimates throughout the project, we suggest you add a weighted contingency to the overall estimate, or to the estimate for the process of estimating itself, to cover the extra resource this added detail will demand. Otherwise, our advice is to keep away from them and choose a more appropriate estimating technique.

Let us look therefore at more techniques before you decide which is the most appropriate for your project and for your estimating circumstances.

Buffer



 Parallel Empirical Estimation     Parallel Empirical Estimation   Estimation Prototyping    Estimation Prototyping



Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z


#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Breakdown Estimation






   


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
   
Topic: 111  Page: 105/444  Progress: 23.6%
 About    |    Author 
Follow @BigAgileToolkit


This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL (http://www.bigagiletoolkit.com/) and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.