Tell me more ×
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.
up vote 12 down vote favorite
3

We have started using Agile/Scrum in a team of 4 developers. We did our story estimations and ordered the stories Primed stories in the product backlog.

We started with the point based estimation on the complexity from 1 to 5, instead of usual 1,2,3,5,8,13.... and so on

After working on a couple of the stories we felt that some of the stories that was estimated at 4 point should only be 2 while the other which were estimated at 2 are a lot more complex and should have been estimated as 5. I would like to know:

  • Is it Ok to change our story estimates in the middle of the iteration?
  • Is it Ok to use the current estimation points from 1 to 5, instead of usual 1,2,3,5,8,13.... and so on

Although I personally feel that it should be no for both the cases but I need to back myself up as my own understanding is not very clear.(Any good ref material would be good though!)

share|improve this question
4  
Ask yourselves: what's the benefit of spending time re-estimating mid-sprint? What's the benefit of spending more time 'arguing' over fine grained 3 vs. 4 vs. 5 compared to a rough 3 vs. 5? – Hugo Oct 19 '11 at 8:44

migrated from stackoverflow.com Oct 19 '11 at 8:19

2 Answers

up vote 12 down vote

Is it Ok to change our story estimates in the middle of the iteration?

Absolutely not. We expect that to happen. And we expect the errors to balance themselves out over time. We only really adjust estimates where it is clear that a certain category (e.g. new web pages) is always going to be more complex than we had thought when we estimated them all.

As an Epic story is broken down into smaller stories (which should happen long before the sprint), we might appear to adjust the original estimate, but I would call it refining rather than reestimating. That's because we have a clearer view at that time.

Mike Cohn's Agile Estimating and Planning is a good book on the subject. I would warn against using it (or any "Agile" book) as a bible, but it's a good start point from which to refine your process.

He talks about the way erroneous estimates balance out as "magic", but stresses that he has seen it work over and over and over.

Is it Ok to use the current estimation points from 1 to 5, instead of usual 1,2,3,5,8,13.... and so on

The use of the Fibonacci series of points estimation is an acceptance that the bigger a story is, the less accurate our estimate is (see my earlier comment about Epics).

But, if it doesn't work for you, particularly if you keep all your jobs small, then don't use it. It's a guideline, not a rule.

T-shirt sizing (S M L XL XXL) is also popular and that is essentially no different from (1 2 3 4 5).

share|improve this answer
+1: Discuss this during your retrospective. Re-estimate when you re-prioritize at the beginning of the next spring. That's why you have sprints. No management overhead during the sprint -- just make code. – S.Lott Oct 19 '11 at 9:56
About the use of fabonacci series use, Say you know that a story is going to take almost 3 days and the no. of tasks to do the story are A,B,C. You also feel that it is not very complex but each of these tasks are going to take 1 day each. What estimate would you give to the story? – tintin Oct 20 '11 at 11:09
@tintin: The reason for using points is to avoid saying things like "you know that a story is going to take almost 3 days." Points are relatively arbitrary, each job is based on complexity compared to other jobs (obviously you should avoid using misestimated jobs as baselines). But, you avoid the missing numbers, to account for uncertainty. So if job B is twice as complex as job A and job A was marked as 2 points, you mark job B as 5 points. – pdr Oct 20 '11 at 16:04
up vote 0 down vote

Is it Ok to change our story estimates in the middle of the iteration?

Absolutely yes - if it will affect current or future spring planning. The point of agile is to base your actions on information that is as current and correct as possible.

If an estimate turns out to be so wrong that the current sprint can't be finished in its timebox, you need to act on the revised estimate, so you'll probably want to change it. If you base new estimates on old ones (and actually look at those rather than relying on memory/experience) you need them to be correct.

On the other hand, there isn't really any value per se in an estimate being correct. Don't waste time on prettying up some meaningless statistic.

share|improve this answer
In our case the initial estimate was a big one, and the work for that turn out to be far less. So it is not that our current sprint is not finishd in time but we have extra time. So the manager is suggesting to lower the estimate. – tintin Oct 19 '11 at 12:30
@Michael, this answer may be true for some agile processes but the question relates to Scrum. In Scrum, it is not recommended to change the story points after sprint planning because the team Velocity metric could be compromised. – GuyR Oct 20 '11 at 13:22
Failed estimates carry a benefit in that you can use them to adjust any future estimates accordingly. If you estimate too long, it's as much of a failure as estimating too short, because the result is underutilized resources. The value in correct estimates is that you know that you are likely to be hitting your release targets, and your team is fully utilized. Therefore, you always base future estimates on your past experiences, adjusting according to what you learn about your estimates along the way. – S.Robins Jan 31 '12 at 7:30

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.