Updating User Story Points after completing User Stories

Question

As User Stories are completed throughout a Sprint, the amount of actual work required can be tracked as a metric. In some cases, the amount of actual work will be either greater or smaller than the original user story point estimate.

In those cases, the developer will require to enter a number that is either above or below the original estimate.

During planning, teams use a User Story Point scale (Fibonacci or similar) to measure the amount of effort for each User Story. Common estimating methods include powers of 2 (1, 2, 4, 8), the Fibonacci sequence (1, 2, 3, 5, 8, etc.), or similar.

The purpose of this scales is to reflect the level of uncertainty associated with estimating how much effort will the task take, as tasks become bigger. For example, for a small task, such as reading an email, you can have a very accurate estimate of how long will it take you to read it; the level of uncertainty is small. But as the size of a task increases, i.e. reply to 50 different emails, it's more difficult to know exactly how much effort will it take; the level of uncertainty on your estimates will grow exponentially.

I have been reading and browsing for a while, trying to answer the following question without much success:

After completing a User Story, the amount of actual work required is different from the original estimate. Since uncertainty is gone now, should the amount of actual work reflect a value in the User Story Point scale? Or, on the other hand, is there freedom to use more accurate values? now that the implementor knows exactly how much effort he required to complete the User Story.

My reasoning behind this is that, by tracking actual work with more accurate values than those provided by the scale (Fibonacci or others), the team will get a more accurate metric, that will later impact their velocity on the mid/long term.

Answer 1

Story points are an arbitrary measure of the relative effort required to complete stories. Their usefulness is that they feed in to velocity, which in turn can be used as a guide to how much work can be brought in to future sprints.

When a team estimates for a story they are not looking at the number of hours or days it will take to complete the work. They are instead comparing to stories they have done in the past. This comparison includes factors such as perceived complexity, experience they have with the technologies involved and difficulty in testing. In many cases a team will increase the points they give a story because they perceive it as risky.

Now consider the following example.

A team sizes a story that appears very similar to dozens of similar stories they have done in the past. They give it 3 points. But when they do the development they discover there was an unexpected problem that results in a lot more time and effort being needed than they had expected. After the work is done they re-size the story to 8 points.

In the same sprint, the team sizes a similar story to the one mentioned above. They also gave it 3 points. This time, a developer realises they have written some identical code a few years back. They recover the old code and the story is completed in minutes. They re-size the story to 1 point.

In the next sprint a similar story occurs again. What number of story points should they give it? 1 or 8?

The story sizing is measuring the perceived size of stories. Sometimes there will be variations. It is questionable whether you gain any value by re-sizing them after the work is done. What you should do, however, is talk about the variations in your retrospectives. Perhaps the team needs to get better at reviewing the risk of stories? Perhaps it needs to get better at checking for existing code before doing the estimates?

Answer 2

Estimations of a User story can not be changed within a sprint.

1. If there is minor difference in actual & estimated story points then we ignore it completely.
2. If there is a major or noticeable difference in actual & estimated story points then we should discuss it in retrospective & improve as team. Team should be more accurate in future estimations.

All these differences are learnings. We should improve as a team as and when these kind of differences happen.

This all lies in inspect & adapt for estimations also. After 3-5 sprints team will be more accurate in their estimates & will improve their Velocity as well.