Jan 9, 2008 / Should We Measure Individual Estimates Accuracy?
4 commentsIndividual estimates accuracy is another metric requested by several TargetProcess users. First of all it may be useful if and only if:
- Task estimated by one developer only (if whole team estimates tasks you can’t measure individual accuracy, only whole team accuracy).
- You are using time tracking to track all spent time for all tasks
For example, Ted subscribed to Quick Search user story. He broke down this user story to tasks, estimated each task and got 50 hrs of effort for user story. Then he implemented the user story and spent 60 hrs. It means his estimate accuracy for this task is 50 / 60 = 0.83 or 83%. In the end of iteration we can calculate all Ted’s assignments and spent time and define estimate accuracy for next iteration, let’s say it is 0.7.
OK, but how we can use this metric? Well, if Ted subscribed to 60 hrs work it means he will spend 85 hours and for 2 weeks iteration it means at least 5 hrs overtime. Ted should take this information into consideration and remove some tasks from his ToDo. This works if Ted estimate accuracy remains the same, but is that always the case? In reality Ted’s accuracy may vary from 0.5 to 0.9 and exactly for next iteration it may be 0.9 and in this case Ted will be able to do all committed work.
As you see estimate accuracy coefficient should be used as a recommendation only, but if Ted insists on his commitment Project manager/Scrum master should agree and let Ted do the job. Again we have similar problem as with individual velocity when Scrum master may demotivate developers with numbers in hands.
I see value in individual estimates accuracy, but I see some danger as well. This metric should be used by developers, not by Project managers/Scrum masters.
I think we should care about team estimates and team velocity, not about individual estimates and individual velocity. Agile development is all about jelled teams.
Labels: agile, estimate accuracy, metric
posted by Michael Dubakov @ 4:36 AM
4 Comments:
We're one customer that's asked for it. We're not quite there yet with the jelled team that is so essential. Instead, we have two groups of developers; those that want to buy in, and those that really don't get it.
I recognise that measuring individual velocity or estimate-accuracy is not the way to foster team-work!
However, we _also_ have more of a pool-of-developers arrangement instead of distinct, not-changing-very-often teams. Because we swap and change project groups fairly regularly, we think it's useful to have individual measurements. Then we'd be able to predict a bit better how different arrangements of people will work in terms of velocity and estimation-accuracy.
Maybe.
I wish we didn't work that way, but there we are.
You know what? Forget it. Give us MediaWiki, Selenium, and CruiseControl.NET integration instead ;)
I have posted a short podcast on how to size iterations and applications on my website.
http://www.softwaremetrics.com/Agile/sizeagile.html
http://www.softwaremetrics.com/Agile/sizeagile.html
David Longstreet
Software Economist
www.SoftwareMetrics.Com
For us the members of the team depend on the volume/nature of the stories and the skills required for the relevant tasks in each sprint. This must be quite common I think - particualrly for ongoing change to existing software.
We use planning poker for estimating and ask each developer to play 2 cards. One is his best or average estimate and the second is his worst case estimate. These probably equate to your 0.5 and 0.9 accuracy work.
We then calculate a buffer using standard deviation as described by Mike Cohn in his book Agile Estimating and Planning.
I've been meaning to put a blog up about this in more detail - will do soon and let you know when its there.
Here's my blog on Standard Deviation Buffers as promised.
Post a Comment
<< Home