You will need agile estimation units if you do an agile project [bibcite key=”citeulike:8925165″]. (Unless you have joined the #NoEstimates movement.) Agile methods tend to be based on some form of effort estimation and follow up. Scrum for instance relies on Earned Value Management [bibcite key=”citeulike:5890054″] for many of its practices.
IMHO the estimation units can be fairly arbitrary as long as they are fairly accurate, reasonably easy to estimate and are not used for secondary purposes (e.g. salary reviews).
Examples of Agile Estimation Units
Here are a few examples of estimation units I have encountered in practice:
- Thousands of lines of code (kLoC)
- Story Points (SP)
- Ideal Developer Days (IDD)
- Man Days (MD)
- Man Hours (MH)
Or why not use coffee cups? I’ve never actually heard of anyone using Coffee Cups as Agile Estimation Units but as I pointed out in a previous post, there are many advantages to using them for this purpose.
Selecting Agile Estimation Units
When you select an estimation unit for your team. Consider the following:
- How much effort is it? Would it be worth the effort? (Not the effort you’re estimating – the estimated effort to introduce a new estimation unit.)
- How much better would your estimates become?
See [bibcite key=”citeulike:8925165″] if you need a more complete checklist on what you should consider when selecting agile estimation units.