Should story points be re-estimated when rolling un-finished stories into next sprint?

Question

We plan our sprint capacity in story points - so for example we have 20 points available when planning a sprint.

When we have stories which were not completed in the previous sprint, we generally roll them over. But what was originally a 5 point story might be almost complete. If we simply move it across then it takes up 5 points, when it might now only represent 1 point, which throws off the planning.

So we looked at re-estimating the story points when rolling over the story - but now we are changing the story points which will (we assume) lead to inaccuracies in the historic sprint metrics.

Is there a general best practice and anything specific to Azure DevOps' implementation to help us with this scenario?

Answer 1

I think if there is any lesson to take away from scrum and agile as a whole its "Don't waste time worrying about estimates not being right"

If you didn't finish the 5pt task in the last sprint then you only achieved 15pts and you should reduce your expected points per sprint accordingly, say down to 19pts

If you move the task into the following sprint and add another 14pts, but there was only a little bit extra to do, then you will overachieve in the following sprint and move your average up again accordingly. If there was loads left to do you will underperform again and reduce the points per sprint further.

Over time everything should average out, no need to re-estimate.

However! You should also not have tasks that take longer than a day to do. If this problem occurs regularly then you need to split your tasks up more.

Answer 2

The practice that I usually follow is

• The published story-points on a story do not change once work has started on a story. At that point, the estimate for the amount of work is "locked in".
• When a story is unfinished at the end of an iteration and rolls over to the next iteration, the remaining effort on the story is estimated and and used for calculating how much work can be put into the new iteration. This can lead to a situation that the apparent capacity of the team (the sum of all published points for the stories in an iteration) is higher than the actual capacity. That is a price you pay for rolling over a story.
• When a story is unfinished at the end of an iteration and goes back to the backlog, then the original amount of story points remains on it. The work already done is essentially wasted.

Answer 3

Capacity and feasibility of a sprint is not dictated by the amount of point in it but by the team itself. The amount of point compared to the velocity is just a tool.

Personally I would advocate to keep the point as is to "level" the story points done across sprints and not falsify the velocity. If sprint N you plan 50 points and don't finish a 5 points US you register 45 points. If sprint N you only report 1 points from your story there is 4 points worth of work that kinda disappeared.

The best agile practice would be not to use story points at all or not use them for planing. The best corporate practice is whatever make your team look better or improve your KPI. In some companies improving your velocity is more important, so do keep the full amount of point. In others predictability is better, so maybe split the US in two, one done with the amount of point "done" and a new one with the amount of point "left".

Answer 4

Do not re-estimate the story or story points.

Story points are an estimation. Actuals should be recorded as well. Comparing actual versus story estimate can tell how accurate (under/over) the original estimation was and is useful to measure how accurate your team is in that regard. Velocity is average of work done over time and serves as an estimation of how much work the team can do per iteration. This is useful for longer term planning/team capacity.

5 points is a big story. Try breaking down the stories to 1, 2, or 3 points. There will be less hangover. The bigger the story the higher chance of hanging over to the next iteration.