The Time Dilation of an Ideal Day

Ideal Day, Story Points, Load Factor, Velocity... Lots of concepts for a simple goal : predicting the amount of work that will get done for a given date. Anybody who went through this kind of measurement system probably tried to grasp its validity. Dave Churchville wonders "How long is an ideal day ?" in calendar time. Ed Gibbs rebounds on the difficulty that people have with story points when time units come more naturally.

I'm no exception. I used plain story points for a while but I recently started to trick this tool to get (I hope) a better matching between the developer estimates and the amount of work units.
Estimating in story points relative sizes is not easy because you quickly loses the connection with calendar time. A developer will provide much more consistent estimates with time units : "I can do that in a couple of hours", "It will take two or three days". These estimates might not indeed be accurate. On one hand, developers are sometimes optimistic because they underestimate the time needed to write the full range of tests, because they forget that some documentation has to be updated, ... On the other hand, developers can be pessimistic : a difficult task can be seen as a huge amount of work, a tedious one might look like lasting forever, ...
The estimates might not be accurate but they will probably be consistent. When someone asks you such a figure, you quickly imagine the size of the code you need to write and you transform this size into your own time unit system. As a consequence, the same task will be given the same figure in time units.

Now, the question is : is there a linear transformation between the developer personal ideal day (DPID) and a "standardized" ideal day?
I assume that this transformation is not linear. I have no evidence for this assumption but, in my current environment, I often get the feeling that short tasks tend to be underestimated and long tasks tend to be overestimated. I think I need some logarithmic transformation.

Actually, I prefer to have a transformation from DPID to story points. The reason is simple. I think that story points are better for a planning game. When you mention a ratio between "ideal" days and calendar days, there is always someone to make it known that the developers are lazy if this ratio is less than 1. The story point is a much more neutral unit because it looks like the cost is inherent to the work unit.

I proposed the following scale to the team and we started to test it:


Basically, the developer has to decide if the work unit:







Developer Personal Ideal HoursPoints
will take one hour or so11
is between one hour and one day (more or less half a day)42
will take one day or so83
is between one day and one week (more or less half a week)205
will take one week or so408
is really longer than a week (about two weeks)8013


I found out that the Fibonacci numbers (which are sometimes used for story points) were perfectly fitting this model. The idea is that we can try to adress the "relative sizes" dilemma by assuming that a 1 hour task + a half day task (in the developer own time system) will actually take as long as a one day task in the same system. Same thing for a 1 day task + a half week task matching a 1 week task.

These figures lead to the following graph. A short period of time represents more points than a longer one.


I don't know if this model will provide better results in terms of stability of the velocity but I hope it will help to remove the potential mismatchs between an iteration full of small tasks and another one containing a few big ones.
Anyway, time (dilated or not) will tell...
Avangel
I really like this way of estimating with story points from your own time estimates.

The scale you propose is really interesting, for the reasons you explained, and in my opinion because we naturally think with those ranges : about an hour or two, half a day, one day, half a week, a week, or more.

We know that such estimates are not really accurate, but the story points are tolerant to small variations, while providing a reliable basis for planning iterations. I think there is too many factors that we can't predict, that can alterate your estimates; so let's take a small uncertainty in estimates, that allows us to face such events without breaking drastically our plans.
oaz
"We know that such estimates are not really accurate"
And, anyway, most of the time we are not able to provide more accurate ones !
oaz 23 novembre 2006 - 22:22

Fil des commentaires de ce billet

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.