How to handle a user story that is significantly larger than estimated

Question

A user story calls for an extension to a current feature. This is reviewed and discussed in planning and given a small/medium point value. Internally within the team the effort is estimated at 2 to 3 days. As work progresses it becomes clear that it is not possible to extend the feature in the desired way without significant effort - it calls for a re-architecture and near total rewrite of the feature so that it can be extended in the desired way. This is epic in size and could take 4 to 6 weeks of effort.

How should the scrum team handle this? Specifically;

• Should the original user story be removed as it cannot be completed?
• Should the sprint be backfilled to make up for it?
• Am I correct to add an epic to the backlog and link it to the original user story?

The story cannot be carried over, it is a dead duck. As far as I see it is up to the product owner to review the new epic and prioritise as appropriate. It may never even happen.

Answer 1

My recommendation would be to remove it from the current sprint, and then continue the sprint as usual. Don't "backfill" the sprint (though, I'm not 100% certain by what you mean by that). If you finish everything before the sprint is over, at that point you can do what you normally do when you have extra time, which might be to bring in one more small story. The important thing is to finish everything else before bringing any new stories into the sprint.

Since there's a little extra time in the sprint, someone (or everyone) can work with the product owner to help split this larger story up into smaller stories. These stories can then be considered for the following sprints.

As for linking the epic to the original story, I'm not sure it matters. The end goal of the team is working software rather than a stack of old story cards. If it's helpful to keep it, keep it. There's nothing in the scrum guide to suggest that you keep it or that you throw it away. Do what helps your team.

If it were my team, I'd probably keep it and stick it on the scrum board with some tape, to serve as an historical artifact and a reminder about how hard estimation can sometimes be.

Answer 2

The goal of a sprint is not to complete stories, but to deliver value, i.e. working software. The value of stories is determined by the product owner, but their prioritization depends on the team's estimate of required effort. If it becomes apparent that a story was wildly underestimated, the priorities might change.

If you realize the problems early in the sprint, renegotiate the contents of the sprint with the product owner. You're not going to complete that huge story – what would they like instead? How can you use the remaining sprint to deliver the most value?

This is not always possible because work takes time, and some of that time has already passed. Especially if the problems appear late in the sprint, dropping the story and focusing on the rest will be better.

Under no circumstances should one underestimated story impede progress on other stories. Focus on attainable goals in order to deliver as much value as possible at the end of the sprint. If you end up with some extra time at the end, you can use some of that time to research the problem in more detail.

Going forward, do you now have enough information to break down the problem and estimate its next steps? If not, consider doing a spike, a time-boxed experiment during the next sprint. Spikes don't get story points and the time used for them is not available for work on features so they “reduce” velocity. The result of a spike is better understanding of the problem.

Answer 3

Try not to drop stories if at all possible.

If you drop stuff because its hard then it really brings into question the motivation to do any of the stories.

You put those tasks in because they make money for the business right? You are saying that value was less than 6 weeks of dev time. Thats ridiculously low given the product will likey be in service for years.

Granted there are some situations where features lose value if they miss a deadline, or you are throwing in a freebie to keep a customer happy because you thought it was cheap. Or perhaps the budget is just too tight.

But, if you are putting in tasks that have no real business need then something has gone badly wrong.

I would recommend either keeping the task in and devoting the time needed to refactor and make it happen. Or giving your requirement gathering and prioritisation a very hard look.