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.

3 Answers 3


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.

  • which might be to bring in one more small story this is what I mean by backfill. I like the idea of stickying the old story as a reminder that estimation is just that and it is sometimes way out.
    – Qwerky
    Sep 14, 2018 at 14:59

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.


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.

  • 6
    I think you've misunderstood the question. They didn't put in a story with no business value, and they aren't dropping a story because it's hard per se. They also aren't necessarily completely dropping the feature from the project as a whole, they are just dropping it in the current sprint. The story has business value, but they are dropping it because it simply can't be finished in a short print. Sep 13, 2018 at 2:09
  • @bryanoakley plus the value the story brings might not actually be worth six weeks if work.
    – Andy
    Sep 13, 2018 at 3:02
  • @BryanOakley I think you covered that angle in your answer. I am addressing the subtext
    – Ewan
    Sep 13, 2018 at 6:00
  • 1
    The story is dropped from the sprint because there's no way it will even fit. Its still going to be there in the backlog, but as an epic instead. Its not a question of motivation, but the effort/value payoff needs to be re-assessed by the product owner with the knowledge that the effort could be 10 times more than we thought when we committed to it.
    – Qwerky
    Sep 14, 2018 at 15:04
  • @Qwerky yes, what im saying is the effort shouldnt really be a factor
    – Ewan
    Sep 14, 2018 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.