AgileMalta

Story Point Estimation and Hours

Filed under: Agile, Business, Teams — Aldo Cauchi Savona @ 1:09 pm

I came across this article by Tobias Mayer, a Scrum Trainer and Coach where he discusses the pros and cons of using time against estimates. He describes some of the arguments people (managers and customers usually) bring up in favour of using hours as an indicator for cost. As a Scrum Master, I have come across all the arguments in Tobias’s article can be found at his site Agile Thinking here .

In this article, I will look further into estimation problems and describe empirical reasons that affect the ability of people to provide accurate estimates in relation to teams being asked to estimate in hours or worse, converting story points into hours.

When the team estimates the size or effort it takes to build a certain piece of functionality a common answer would be “about 2 days” (a guess) or “3 hours” (a relation to a past experience). However, it is non un-common for a 4 hour story to take 12 hours. The hour estimation problem does not get better with experience.

More often than not, the team is optimistic about its situation and estimates and have a tendency to measure effort of “ideal” days. However, our work gets disturbed by emails, MSN, the occasional joke, birthday cakes, and so on. Sometimes we manage to develop at lightning speed and at other times it seems like all the gods are against us having our IDE crash, issues crop up and writing a simple piece of code would drags on.

Story estimates are should also done one or two sprints ahead where all the variables are not yet known. In some cases, I have seen teams estimate their stories before they enter the sprint. In such as situation, a direct conversion into time is possible as the team should have a good understanding of what it is getting into and the degree of error would be minimal. However, the further away a story is from implementation, the harder it will be to estimate.

One can think of estimating distance as an analogy. In general, a person is more accurate when estimating the length of a finger compared to estimating the length of a room. Then again, people are better at estimating size/distance than duration [Mike Cohn, Agile Estimating & Planning].

Our capacity for estimation is also dependent on several other cognitive faculties and conditions. Representation of time is based on memory and is generally expressed as a repetition of the past. Age, culture and successess (or failures) also have a decisive importance on our capacity for estimating duration [Géry d'. Ydewalle , et al., Cognition in human motivation and learning]. When the future and context conditions are unknown, a time estimate is more of an uncertainty estimate rather than a predictive [see Richard A. Bloc, Cognitive models of psychological time and Ricardo Valerdi (MIT), Cognitive Limits of Software Cost Estimation].

A common explanation tool used in traditional project management with regards to estimation effort is the Cone of Uncertainty. It is said that the uncertainty decreases as the project progresses towards the finish and accuracy increases. This is based on the assumption that the project domain in known up-front and most variables are fixed. In a world where “change is the only constant” (Heraclitus), this is not always the case.

Agile processes place a lot of value in the ‘human condition’ and accept people for what they are, thus creating an environment where people can perform give our de-facto constraints rather than ask people to perform tasks to a certain level of accuracy when the human mind is not built for such tasks.

While accepting the fact that estimates may not be accurate, we can still use our knowledge of how cognition works to help improve story estimates. As people are better at estimating size/distance in comparison to time, rather than ask ‘when‘, it is better to ask ‘how big‘. Also, by providing context (e.g. having a direct reference to something historical such as a similar story) helps to provoke our memory to retrieve data relevant to the current story that will improve accuracy. So a better question is ‘how big is this story compared to that story’?

When it comes to estimating the cost of software, the most common pitfall is to attempt to convert story points into hours. This is, in my opinion, a big source of a problem as the estimates are in place for getting the team’s understanding of a project’s complexity. In Agile processes, there is usually a clear distinction between people who implement the project and people who sell/own the project. When managers push for a direct conversion between the estimated points into hours, they are unknowingly pushing the burden of software cost onto the team and crossing this boundary.

Another factor which we should keep in mind is that story points are a measure or abstract time, while hours, which are a measure of concrete time [Mike Cohn, Agile Estimating & Planning]. Apart from the impossibility of such a task from a physic’s and philosophical approach (abstract can be multi-dimensional and span an infinity, while concrete is one-dimensional and finite), how would one factor in the individual factors when the estimate is a team (collective) velocity?

I would argue that the role of a Manager in an Agile process is to find ways and means to bridge the gap between points and software cost. If this role is pushed on to the developers, why have a company pay a manager’s wage?

Thanks to Dave Sammut for his input in creating this article.