Should you ever re-estimate user stories?

My current project is having a 'discussion' which is split down the middle- "this story is more complex than we originally thought, we should re-estimate" vs "you should never re-estimate as you only ever estimate up and never down".

Can anyone shed some light on whether you ever should re-estimate?

IMHO I'd imagine you could bring up an entirely new card for a new requirement or story, but going back and re-estimating on backlog items seems to skew the concept of relative sizing and will only ever 'inflate' your backlog.

• Estimates have a certain value, but they are based on a the information you have at a certain time. An early estimate is no less valid than a later estimate on the face, but the later estimate is probably more relevant. Like others have said, if it makes sense, and it adds value to your process, do it; if however, revised estimates are for your own limited use..would the revision add value and not interfere with making future estimates? Nov 2, 2012 at 6:54
• is your estimation in "days" or in "function-points"? if it is in function points you can downgrad your velocety.
– k3b
Nov 2, 2012 at 12:36
• Your current estimates are 'wrong'. But your future estimates will be just as wrong, because they will be made under the same circumstances. If you revise esimates then you have effectively changed the circumstances, and you're no longer comparing equal things in velocity estimation. Nov 2, 2012 at 20:01
• @k3b - Our estimations are in relative size... Fibonacci numbers. Nov 5, 2012 at 1:17

A core part of estimating stories in one team I worked on was the idea of a story which was 'too big' to estimate. That is - the workload implied by the story was beyond the scope of a single sprint.

As more information came to hand, or the team got a better grasp on what at first seemed a single beast of a story, we would often re-estimate the story down. In most cases, this might involve breaking the 'too big' story into smaller, achieveable stories and estimating those instead.

These 'too big' stories never went into sizing numbers or burn down charts.

As well, we might come back to a story down the track and with a better understanding of the requirements, we could re-estimate. You should not re-estimate a story simply because it has become easier to achieve (e.g; after building up a bunch of framework libraries, a dependant piece of work will be easier to achieve), because the whole idea is that as you become 'better', the team can achieve more in a sprint, but certainly I think it is valid to re-estimate stories if your understanding of them changes.

The following was going to be a comment but I got carried away...

Don't forget to distinguish between size and complexity in your estimating. You should estimate on size only, not complexity or difficulty. For example - adding a button to a screen should always be a '1', in that as far as the user is concerned, they are getting a button - size is very low. It doesn't matter if you actually implement it in C# (low complexity, very easy) or Assembly (high complexity, very difficult); the user story has the same size.

So, when I say that it's worthwhile re-estimating when understanding changes, it's not that your understanding of how to implement the feature has changed, it's your understanding of what the feature is which has changed.

So, "I want a button" is easy, but later you realise the user means "I want a clickable button, which turns green and pops up a message to the user, is now a more complex story, and so should be re-estimated.

Update; as requested, I'll try to elaborate on what I mean by estimating on 'size' rather than complexity.

I think it easiest to consider this distinction in terms of a new product. Your team is tasked with building a multi-screen system, where everything is new. Amongst your user stories, you have a series of stories like;

1) I want a button on Screen A, which when clicked will show an error to unauthorised users. 2) I want a button on Screen B, which when clicked will show a message if the current day is a weekend. 3) I want a menu oiption on Screen C, which when clicked will make the screen flash every 5 minutes.

Now, when the team estimates these stories, they agree that they are all roughly the same size, and estimate each one as a 'small' story, worth 5 points on their sprint velocity scale.

The sprints kick off, and for the first sprint, the team achieve none of these stories, because they spend the whole cycle setting up projects, infrastructure, core libraries, etc. And there's a new guy on the team who is still learning.

A few sprints in, and the team puts together a screen which fulfills Story #1 - happy days, they've now achieved 5 points of velocity. (With an average of say, 1 point per sprint, due to the unproductive sprints at the start).

Now, for the next sprint, the infrastructure is in place, the team has a screen template to re-use and the new guy is getting his head around things, and this sprint, the team knock off Story #2 & #3.

Now, they have achieved 10 points in a sprint, for an average of about 4 points per sprint. This shows that team productivity is improving over time, which is entirely expected, as the project evolves, the team upskills, core code is reused (not rewritten).

This to me, is the ideal. Well estimated stories, demonstrating an icnrease in velocity over time (which, eventually will plateau you would assume, unless something major changes - like a new team member, etc).

On the other hand, if right at the start, the team looked at those stories and estimated them based on complexity, they would find that Story #1 is a BIG story, as they are factoring in all the ramp-up effort, plus the new guy needing training. Story #2 is a MEDIUM, because they figure they'll be at least on the way by then, and it should be easier. And finally, story #3 is a SMALL, because it'll be easy once #1 & #2 are done.

Now, what you've ended up with in this model is simply an obfuscated estimate of TIME; the estimates are factoring in how hard it will be and how long it will take to get a piece of work done, and as we know, this is difficult at best. In this model, velocity is evened out from the start, and you'll never be able to demonstrate an improvement in team performance. If you estimate on time, then you'll only ever be able to achieve 40 hours of work in a week. And you'd be silly to plan a sprint with any more or less work. If the team improves its capabilities, you can still only book 40 hours of work. You will only ever achieve 40 hours of work.

Hence, why I noted that a job in C# is easier than a job in Assembly (less complexity), but that the 'size' of the task should be estimated equivalently. That way, you can see that the choice to move languages, improvements in capability, (or adjustments to some other team dynamic) has a direct impact on velocity.

As for prioritisation, I believe this is a separate discussion to sizing/estimating. You don't prioritise the queue simply on the estimates of a story, else we would only ever do small jobs, and never the bigger, [possibly] more imporant, ones. In a team I led, we routinely had conversations about complexity when managing a sprint queue. The PO would be given to understand that, whilst some task is a "SMALL" task (in story points), it might be difficult to achieve because of X,Y,Z. At times, the team's velocity would take a hit, in order to implement some of these more complex stories. Other times, the PO would say "well, I'd rather have 5 other things this sprint, so we will put off the more complex jobs".

If we simply estimated stories in difficulty, then that would be hiding the velocity. Difficult or time-consuming tasks would always be given more weighting, in order to make velocity average out. As I noted before, this is just a different form of time-estimating, and there's no point tracking velocity if this is your estimation method, as you always have a fixed duration for a sprint, so your "velocity" would only change if you estimated incorrectly (e.g; an 8hour task took 1hour).

Hope that clears it up a liitle?

• We've certainly got our '13' or 'infinity' cards for things that are far too big to tell... However if we've sized something a 3 originally relative to everything else, and then we move that to an 8 at a later date - not because of a requirements change but because we've decided it's more complex than originally thought - doesn't that skew all your metrics? Especially since you never really estimate down... Wouldn't you take a hit in that iteration, and then it will work out over time when you close off fives that should actually have been twos? Nov 2, 2012 at 2:49
• I've updated my response with clarification on what I mean by 'increased understanding' Nov 2, 2012 at 3:34
• Care to elaborate a bit on your C#/assembly example? I'd think that if a "button in C#" gets 1 point then "button in assembly" should get 10 at least. How can the PO possibly prioritize between these two stories if they are both 1 point in size (but one is actually lot more complex)? Nov 4, 2012 at 9:22
• @MartinWickman - have elaborated with an update. Now looks like an essay on sprint estimating... :-P Nov 4, 2012 at 21:40
• But hey, it's a good essay... Nov 5, 2012 at 1:17

The main reason I don't repoint is that it destroys the usefulness of your velocity. Consider a hypothetical scrum team who estimates every story as 1 point. They complete approximately 10 stories every iteration, for an average velocity of 10.

During a retrospective, a team member argues that in hindsight, when you look back at pretty much every iteration, one of the stories really should have been a 5 pointer, so they should repoint it to "fix" their velocity. That brings their velocity up to 14.

The next planning, the velocity suggests they can take on four more stories. They are pretty sure that can't be right, because chances are good that one of the future stories they estimated is really a 5 pointer. Unfortunately, they have no idea which one. Suddenly, they have a velocity figure that is absolutely useless for planning.

The thing is, if they had kept their velocity at 10, that takes into consideration their estimation skills. If 10% of their stories in previous iterations were really 5 pointers, then odds are 10% of their stories in future iterations are similarly underestimated. Over a long period of time, it all comes out in the wash.

Remember velocity has no units. A higher number is not better than an accurate and useful one. If you want bragging rights just multiply everything by 1000 :-)

• I feel that it will all come out in the wash too, but a member of my team challenges me on this and says in his experience, it never does; you simply have 'bad' iterations which affects morale because you get 3 points done when actually you know it should have been 10 if you'd re-estimated. I feel that's more of an issue with the team's mindset (must always achieve X points) than anything else, but I find it hard to argue with his own experience. Nov 5, 2012 at 1:20
• So, repoint if it helps morale. Just use the original figures in your velocity. Nov 5, 2012 at 13:16
• I would add that you can always re-estimate outside of whatever tools you're using; so you can keep the original estimate and have the re-estimate alongside it and see which one is more accurate after the task is complete
– user7433
Feb 1, 2017 at 15:01

Short answer: the product owner can do anything he or she wants to a story--until the sprint where the team commits to complete it.

So, if the team wants to re-estimate a story for a future sprint, go nuts.

Once you're in the sprint, the work (and the estimate) is fixed.

I've worked this way on numerous projects and it works just fine. If you're doing a burn-down for the product backlog, be sure to either back-update the estimate or at least visually make it clear that the change is not a case of burn-up.

It seems like in this case, if the estimate was wildly wrong, that you would cancel the sprint and start over. This would, of course, be up to the scrum master and the owner. When there's no way to deliver anywhere close to the estimate we need to be honest with the boss and tell them sooner so decisions can be made.

• Yep... I agree you have to raise it, and raise it as soon as possible. I'm just not sure you should change the numbers. Nov 2, 2012 at 2:50

There is no problem re-estimating backlog items, up or down. Development is a learning process, so it's expected that some future backlog items became simpler or more complex depending on the knowledge gained in past sprints.

Maybe the 'velocity' (if used by the team/company as a metric) could not be exactly measured in the event of a huge re-estimation, but the most important thing is that re-estimation exercises would sharp the team own estimates in future. The key to be predictable is to use the most update information, not restrained to an early estimate.

• I know it’s an old uestion but was thinking about answering it similar to this “sure, if you take it out of the sprint”. No need to know that I see your answer. Feb 7, 2019 at 4:36
• For each "simple answer", there would be a bunch of hidden repercussions. The original questions does not refer to an ongoing sprint, so it is more about backlog grooming meetings. Jun 29, 2023 at 14:12