In Scrum, what to do when story points and task hours don't roughly correlate?

Question

Our development team is pretty new to the scrum process, so I would like to help refine our methods to make better use of it. In particular, I noticed that the correlation between story points and task hours is not very good. That is, we often have stories of lesser points decomposed into a total task hours greater than stories of higher points.

Now, I am aware that these are two separate estimation processes and that we should use the hours to estimate only the remaining work for a sprint while using the story points to compute a velocity and be able to predict the length of the release cycle or the amount of features we will be able to address. However, it seems to me that if sprint points and task hours don't correlate well, then we must be doing a bad job at estimating either one or both of these.

Since we only adjust the remaining work hours as opposed to recording the time spent, I can't easily tell if the problem is the initial task hour break-down or the story point estimates.

So, my question is whether we should deal with this and how? I can think of several ways to start dealing with this:

• Record time spent in a task and use this information as feedback to help refine our estimation process by retrospectively identifying user stories which we under/over estimated. But I am not convinced that we want to record this information and I anticipate resistance to it.
• At the planning phase, identify outliers after the task hour break-down process and look at these further. This way we could try to identify whether we misjudged the complexity of the story or if the task breakdown is missing some efforts or over-estimating the length of simple tasks. However, I'm afraid this would couple the two estimation efforts, which doesn't seem as the right thing to do either... This also assumes we would have decomposed all stories in the planning phase, otherwise we won't be able do much about stories which were misjudged.
• Another method to approach this would be to try to independently incorporate methods to enhance the estimation process and raise the team consciousness about the importance of estimation. Then just keep monitoring the correlation between story points and initial task hour break-down as an indicator of how we are doing and whether we need to keep working at it. I'm inclined to think that this is the best approach, but less pro-active.

What is the best way to approach this issue and/or what other suggestions are there for enhancing the estimation process in this context?

Answer 1

They don't really collerate well because as you said, they are used for different purposes.

With time, your team will do better estimates and you'll get more accurate velocity per story point.

My comments about your solutions:

Record time spent in a task and use this information as feedback to help refine our estimation process by retrospectively identifying user stories which we under/over estimated.

Velocity was designed to adjust developer's estimation against reality. When properly used, velocity will "adjust" those uncertainties in 3 or 4 sprints on average.

At the planning phase, identify outliers after the task hour break-down process and look at these further. This way we could try to identify whether we misjudged the complexity of the story or if the task breakdown is missing some efforts or over-estimating the length of simple tasks.

Again "misjudge" is adjusted with time and experience gained from sprint to sprint.

Another method to approach this would be to try to independently incorporate methods to enhance the estimation process and raise the team consciousness about the importance of estimation. Then just keep monitoring the correlation between story points and initial task hour break-down as an indicator of how we are doing and whether we need to keep working at it.

That is done with time too. Planning poker sessions will become more and more productive with experience.

Answer 2

Coming from the developer point of view, I cant estimate time for the life of me. I can estimate how hard something will be fairly well.

With that said, when I give an estimate in story points, its basically me saying it's hard or easy work. SP are to give you (the PM) an idea that this is a hard task, so leave me alone when Im working on it so that I can finish it fast, or Im doing mind numbing task, so, if you have a question, swing on by.

Also, you know your devs and there skill level, so if you have a junior dev, dont give him the 3's, but the 1's so that he does not drown.

Now, here are some examples:

easy (1sp): refactor a function time: this could take 10min - 2hr's depending on the language and if its used as an magic function. Then there is testing, ect.

hard (3sp): set up a deployment server time: If its a custom deployment system, a day or more.

so, in theory, I can do 3sp a day, but 3 refactor functions that take 10min each - 30 min of work? As for time management, the idea of SP does not translate to a gant chart, so get time estimates too if you need them.

Answer 3

The important thing is to first of all understand whether you actually have a problem or not.

• Story Points are used to determine how much your team can fit in a sprint
• Task Hours are used to determine the health of a sprint

So, a priori there is no reason to worry about this. In practice though, on the first day of an iteration, both the task hours left and the story points are correlated to the whole sprint length—giving you a point which you can use to measure some form of correlation.

I would consider the following points:

1. Are you on track with the sprints? In other words, is your team committing to the right number of points (not too little, not too much)?
2. Is there any indication that one-iteration-worth of points is different or not correlated to one-iteration-worth of hours?
3. Points are less precise than hours by design. Are you simply witnessing a refinement?
4. Is your team simply not very good (yet) at estimating stories?

Answer 4

What would I do? Wait for the retrospective, than speak openly with the team about this problem.

Figure out do we really need to track task hours? Aren't we able to estimate the average velocity and have a good guess at how much we should commit from a sprint to another? Because after all this is all that really matter.