A redditor asked the following question:

Question#

Spillover stories are giving us a bit of a headache in sprint planning.

Here’s the deal: We’re trying to find a smooth way to handle the remaining story points (SP) of spillover stories during our sprint planning in Jira, without messing up the original estimates. We tried duplicating stories with only the leftover SP, but tracking turned into a hot mess. We’re now manually updating the SP burned field to deduct the remaining SP, but it’s tedious and it doesn’t help that Jira’s reports stick to the initial SP estimate anyway. We’re often falling back on good old Excel to do proper sprint plan, but Jira is then blind on the remaining points (and again reports are messed up, especially velocity).

How do you deal with this?

My answer#

Why do you spend so much time doing all these estimates and excel mumbo jumbo? What’s the point of it?

If the team started a story and didn’t finish it, they burned zero story points.

I always recommend re-estimating the remaining work. Just treat it as a new story, because the situation is different, you know more, maybe the team has a different idea of how to do it, maybe the risk is lower now.

I know, with such an approach the team might feel that they are losing story points, because they “burned” 3/5, but the sprint ended, and now they will only burn 2 points in the new sprint.

But believe me, this is better than your approach. Story points are there to help you plan, it’s easier to plan if you only count work done according to your definition of done.

Instead of focusing on keeping original estimates (why, by the way?), reports and all that redundant shit, focus on customer value, eliminating waste, breaking stories into smaller ones. Estimates are meaningless once you have finished the story. They are invented as a planning tool.