Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Nov 6 '11 at 9:12

This question came from our site for professional and enthusiast programmers.

1  
What statistics are you tracking and why? Is tracking task hours important for you? why? –  Martin Wickman Nov 6 '11 at 14:46
    
We use Rally, so the information is there and I compared our initial estimated hours remaining to story points. It is not important to track this information. What I feel is important is to estimate work load appropriately. The data that I have suggests that we are not estimating well enough. That and the fact that we are not accomplishing our commitments, of course. –  miguelf Nov 6 '11 at 15:57

4 Answers 4

up vote 1 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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?
share|improve this answer
    
I'm aware of the different context where each is used. That is why I don't want to couple the two nor over-react to the issue. However, in general we are failing our commitments and one thing that seems out of place is our estimation. I found Mike Cohn's blog describing the issue well. I would expect larger points to require longer hours with more variance towards larger stories and some overlap, but certainly a correlation. The question would be when is it worth addressing and how. –  miguelf Nov 6 '11 at 15:53

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.

share|improve this answer
    
Right, but that is only true if our estimation is good enough. I've given some more details in answers above, but I guess that the retrospective is a good start. –  miguelf Nov 6 '11 at 15:58
    
As you said, recording everything will get you resistance. Just ask everyone what tasks took longer than they initially though. can the team identify a pattern between the stories that take longer, like learning a new technology, or solving integration issues? And then discuss about possible actions on those kind of tasks, like for example pair programming –  xsace Nov 6 '11 at 17:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.