This scenario happens to almost every team at some point in time. A user story is estimated to a relatively small value e.g. 1 Story Point. It is added to the Sprint Backlog during Spring Planning. When a developer starts working on it, it becomes obvious that the user story is bigger than 1 SP. Should the estimate be updated?
Do not update a story estimate if the story is in progress
The rule is simple - do not change the estimate for the story that is being worked on. Why? Because it is wrong. Simple as that. I hope you are not satisfied with such answer. Probably you expect some explanation. So here it is.
What are Story Points?
There many definitions on the internet of Story Points which are different to each other or even distinctive. I could not find an official one but I agree with Derek Davidson on his definition:
"A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements"
For the sake of this article, I would like to emphasise one part - it is a measure of estimated effort. It is important that it is estimated not a real one. There is a big difference from the application perspective. Estimated effort is used for planning. Everybody knows that it is not accurate and can be different than the real effort. That is why we use relative measure - Story Points not absolute units like mandays.
Planning projects
When we gather historical data, we can calculate team's velocity (how many Story Points the team completes every sprint - in average). It allows us to plan current and future projects' duration. See how it works.
There are two projects in the backlog: Venus and Mars. Both are split to stories and total estimated effort of each one is 100 SP. The Venus project started first. It took 10 sprints for the team to complete it. Some stories appeared to be bigger than expected but nobody has changed the estimates of them. After completing the project, the team's velocity was calculated to 100 SP/10 sprints = 10 SP/sprint. How long will the Mars project take? The most probable duration is 10 sprints because it is Mars estimated effort divided by the team's velocity. 100 SP / (10 SP/sprint) = 10 sprints.
It seems reasonable, right? Both projects seemed to require the same effort at the beginning. What if the team agreed to update stories estimates when working on them?
Again, both projects were initially estimated to 100 SP each. The Venus project took 10 sprints as previously but the team updated some estimates when working on them so Venus estimates of user stories were summed up at the end of the project and the result was 120 SP (not 100 SP as initially). It means that at the beginning the team thought the effort of Venus project was 100 SP but after completing it - 120 SP whatever that means. The team's velocity is 120 SP/10 sprints = 12 SP/sprints. Wow, the team is the same but it is 20% more effective? See what happens next. How long does Mars project is expected to take? Total estimate divided by the velocity = 100 SP / (12 SP/sprint) = 8.3 sprint.
The same team and the same project but two methods give different expected duration of Mars project. I hope you agree with me that the first method provides more reliable result as both projects seem to require similar amount of effort.
Read more
When we discuss estimating, I have to remind you - do not estimate bugs in Scrum!
My blog contains much more articles related to Scrum.