Some months back, I wrote a mail to you guys about the easiness and the usefulness of using points system in a story instead of calculating its size in days or hours. I thought that I should blog this discussion now as I think that it might be useful for others too.

For calculating the effort involved in a story we now use days as the unit. By days we actually mean “ideal” days.
That is, we smartly ignore other work related things a developer does in a typical day and calculate only the amount of time s/he has to spend on the story.
We have calculated an ideal day to be 60 % of the developers’ typical day. In other words, it is 4.8 hrs or let us say 5 hours to approximate.

I think that this ideal day system for measuring the effort or size of a story brings in some unnecessary ambiguity into our calculations.
To understand what I mean, let us go back and ponder on what estimation means to us?

What are we trying to do in the estimating meetings?
The answer I think is, during the estimation meetings we are trying to define the size of each user story. In other words, we are trying to categorize each user story based on our previous experience and calculate the effort involved to put these stories into sizes or points like S, XS, M, L and XL or 1,2,3,5, and 8 respectively.

Great, so why do you use “ideal” days?
Well, I think that we use ideal days because we somehow wanted to relate time to effort so that we can know how many actual days a story is going to take or taken. Also, it becomes easy to express the status in number of days to the stakeholders rather than with an abstract entity called points. Yepp, true…but I think, this creates ambiguity to a very large extent when practised. For instance, an ideal day for person A need not be the same as the ideal day for Person B. So I think this system is highly subjective. It does not make sense to me to use a system that varies a lot between individuals.

If we wanted to measure how long a story is going to take, we should instead use the team velocity and perhaps create baselines using Burn down charts.
These two measures together can give a better approximate estimate in time for a story.

Let me add some weight to my argument with Mike Cohn’s thoughts on estimation

Choosing between story points and ideal days
With Agile methods, it is perfectly okay to use either points or ideal days as the measure of the size of a user story.
But I think that the points system is more advantageous and complete. Read on…to know why?

According to Mike (and I totally agree with him of course), below are the key advantages of using a points system
a) My ideal days are not your ideal days
b) Points estimate do not decay
c) Points are pure measures of size
d) Points estimation are usually clearer and thus faster

a) My ideal days are not your ideal days
Let us say, two runners one fast and one slow are standing at the start of a trial. Each can see the whole track of the trial and can easily agree that the track is one kilometre long. They either come to the agreement because of their previous experience or by comparing it with another track. Either way the process is easy and intuitive. Tracking the length of the trial is similar to the points system. That is, one simply measures the size.

Now, let us bring in some ambiguity by adding more parameters…
Suppose instead of discussing the length of the track, the runners wanted to calculate the time it takes to run the trial. Obviously, the time taken by the fast runner will always be lesser than the slower one. It is going to be difficult for these runners now to come to a consensus. Both of them with different numbers are correct from their point of view. They probably will never agree as to how long it will take to run the trial.

There is another thing that we need to pay attention too. An Ideal day between developers differ a lot because they are constantly involved with something else other than the story development. Things like support issues, big maintenance bug fixes, investigation, design for future projects all takes time.

So as said, the ideal days system is too subjective to be a standard.

b) Points estimate do not decay
An estimate in points has a longer life span than estimates in ideal days. It is simply because the point estimate only takes into account one parameter and that is the size.

Let me explain this with an example. Let’s say that we are to use ideal days to estimate a story that has to use a new technology like flex. We know that none of the developers have worked with it before and we have to do a lot of investigation and learning to produce the story feature. So, let us assume that the developer estimates it will take 13 ideal days to complete the story. Great!

Now, let us fast forward a few sprints and ask the same developer how long another similar flex story will take to do. Obviously, the estimate will be lesser, let’s say s/he says 3 ideal days. Bingo! we got a problem here. Similar stories take different amount of days to implement.

Many teams tend to ignore this as a problem because they think it is only logical that the amount of ideal days decreased, because the developer knows more about the technology now than before. They also argue that measuring team velocity over time would even out this difference. But it actually won’t in reality.

Because…we will see that using ideal days, the team velocity always remains the same even though developers do more work. See, the developer now after a few sprints produces the same feature in 3 ideal days, where the first time it took 13 ideal days. In other words, in 13 days the developer is now capable of producing 4 such stories (4 stories X 3 ideal days = 12 ideal days). But with ideal days the developer’s velocity is always 13 even though s/he can complete 4 such 13 days stories in 13 days. So ideal days do not reflect the actual team velocity in this case. (logically, after a few months the team velocity should have gone up)

With the points system, we do not take time into account…we just calculate the size. For instance, we say that the flex story is about 8 points or XL large and then after a few months, the team velocity is calculated, now we see that the velocity goes up because the team is now able to complete X number of more XL stories than they did previously.

c) Points are pure measures of size
As said earlier, points are pure measures of size and ideal days are not. Of course, ideal days can be used as a measure of size, but with deficiencies. As in the above example, points remain the same but ideal days tend to vary depending on the developers expertise.

Story points being pure measure of size has a couple of advantages. First of all, story points allow the team to estimate stories with analogies. It makes the estimation easy and more fun as we are only talking about “this story is like the other one” and hence should be for example an L or 5 points. When we estimate in ideal days, we can use the same analogy approach, but the problem is that we tend to bring in the calendar days and measure how long a story will take to execute instead of looking at how big a story is. As said, “how long” approach has hidden problems!

Secondly, a story being an abstract measure of size escapes the temptation to correlate it with reality or time. Less is more!
Ideal days has an inherent comparison built in :-) That is, we tend to always end up comparing actual vs ideal time.
Then this pondering eventually ends up with questions like, “how the heck we ‘only’ did 8 ideal days of work in a 14 day iteration?” You know more often than not, many teams put the blame on some bully. :-)

d) Points estimation are usually clearer and thus faster
Yes, to me it sounds obvious that it should be really easy to estimate a story on just the size. We skip detailed level of discussion and it makes things easy.
So in estimation meetings, we got to decide only if a story is an XL or M?…Then arises suggestions like we got to do these and these things. Further the last time we worked on that piece of code we found that we had to re-factor it etc. We can also use our previous stories as analogies. Perhaps a similar story that was an XL involves lesser effort this time?! Maybe maybe not…that’s what we decide in estimation meetings.

My point here is that it is easy to talk on higher level and skip going into the details.
Of course, we got to break down the story into smaller tasks. But that has nothing to do with estimating a story size.

Finally, I think that estimation in ideal days has some advantages. But I unfortunately can see only one obvious thing.
Stakeholders want to know when a story will be finished. Is it by Aug 1 or Aug 15? Calculating ideal days might be easier
to get to the date the stakeholder wants to know. But it is like a shortcut and it creates a lot of side effects for the team members.

So I think we gotta stick to the best practises that agile gurus suggest. That is points for a story size and velocity based on points for the team! Just as Ez as it can be :-)