Under Scrum, we have a story which was estimated to be quite short. Once the story was picked up by a developer, it turned out that a significant amount of technical preparation is required, and this is dragging hugely.

The business has agreed that the preparation work can be left as it is once we reach the end of the sprint, so that the developer can continue to pick up other (more important) work - meaning that the story cannot be done. This is an explicit agreement with the business that the current story will be picked up later (after a particular deadline has passed.)

Should this problematic story be moved to Done, marked as cancelled and then resurrected in a later sprint or should we simply mark it as blocked and leave it where it is until some (possibly much) later sprint has capacity to pick it up?

A third option is that we dissect the story into two: one for the preparation work and one for the actual work. But with that the question remains: What should be done with the actual story, given agile guidelines?



Assess the impact on the Sprint Goal, and then allow the Product Owner to fulfill her function accordingly.

The Scrum Process for Handling Incomplete/Uncompletable PBIs

[T]he story cannot be done...Should this problematic story be moved to Done, marked as cancelled and then resurrected in a later sprint[,] or should we simply mark it as blocked and leave it where it is until some (possibly much) later sprint has capacity to pick it up?

None of the above. You can't treat an incomplete story or unshippable feature as "done." Work also cannot be automatically carried forward from Sprint to Sprint without violating core framework principles.

A bigger question, unanswered in the original post, is whether or not this story is essential to meeting the current Sprint Goal. If it is, and if it can't be completed within the current Sprint, then the Product Owner must decide whether to work with the team to re-scope the goal or declare an early termination of the Sprint and a return to Sprint Planning.

Regardless of whether the Sprint is terminated early or not, unfinished work is "not done," and is returned to the Product Backlog at the end of the Sprint. The Product Owner can then decide whether to re-prioritize the work for a future Sprint, de-prioritize, discard it altogether, or refactor/edit/decompose the story in whatever way she sees fit.


I don't know of any official agile guidelines around this. There are a few things that common practice would dictate though:

1) It sounds like your team and business had exactly the right conversation about what to do when they discovered it was much bigger. Great Job!

2) The story was started and you stopped working on it. I would not move it to done - rather just move it back to the backlog to be picked up later. It doesn't actually sound like it's blocked, just that you've de-prioritized it, so the PO should move it wherever they think it goes in priority. This is one of the few exceptions where I'd actually recommend resizing the story to represent the new size, just because it will actually drive decisions later.

3) Cleanup: If the team did some work on the story, they may not want to leave half-done code hanging around. Whether the right way to clean up is to roll it back or just tidy up the code so it can be easily picked up later without causing problems, your team will have to decide, but create some space for it.


Scrum defines three roles. When it comes to the work in the Sprint, it is forecast by the Development Team and aligned with a Sprint Goal determined by the Scrum Team.

If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

How the Scrum Team manages that work is up to the them as they remain transparent about the effort, issues, and outcomes. Is the team attempting to eat the elephant all at once instead of in small bites? Can the item be broken into smaller functional units? Are multiple learning spikes (research, prototype, proof of concept, or safe to fail experiments) needed to determine the best approach?

What are "agile guidelines" and how do you feel they are applicable? (See the definition of agile.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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