I have seen a number of interesting articles (links below) about scrum and how they talk about the need to avoid using Time completely and instead use “another measure” when estimating sprints. As any scrummager will almost certainly know, it tends to be much easier to estimate unit(s) of work in an abstract way; whether this be points, units of beers, breeds of dogs or bananas.
However, in light of this, I think it’s important to not loose sight of the fact that at some point along the chain, your unit of abstraction will get converted back to a unit of time and that in turn to a $ value. There tends to be a direct correlation between how long a project takes and the final cost to the client; hence time is almost always the first yardstick the client uses when prioritising the estimated stories. Telling him or her that a piece of work will take 5 points, 5 pints or 5 bananas will almost certainly provoke the response “Ok so how long does it take to do 1 banana ?”. Answer that question with “well it depends on the velocity” and you could find that the clients eyes start turning a shade of red (especially if you then go on explain that velocity could be higher or lower depending on who is working on the sprint !).
Now, I can already hear the scrum masters shouting “but a developer shouldn’t need to be distracted with whatever gets communicated to the client”, and to this I do plead no contest; it may well be best to firewall the developers at one end of the pipe from the client at the other. However it surely can’t be bad for even the developers to keep note of the actual cost associated with whatever unit of abstraction is used; first in terms time and then dollar amounts. After all, when the developers decide that
“JIRA 1234 is estimated as 3 bananas”,
your client is about to get told …
“yep to move that combobox from the right to the left and add ‘unknown’ as an item is going to cost you $2,500″
Someone, somewhere has the job of converting 1 bannana back into $1
Related articles :
– Story points: Why are they better than hours ? (http://scrum NULL.jeffsutherland NULL.com/2010/04/story-points-why-are-they-better-than NULL.html )
– Why you should not estimate in hours or days (http://www NULL.dzone NULL.com/links/r/why_you_should_not_estimate_in_hours_or_days NULL.html )
– Why I’m done with scrum (http://www NULL.dzone NULL.com/links/r/why_im_done_with_scrum NULL.html )