Skip to main content

How to handle story that cannot meet the definition of DONE at sprint end

Last post 09:47 pm February 28, 2023 by Olawunmi Onafuwa
4 replies
12:17 pm February 27, 2023


The developers in my team have estimated a story as large [20 story point] and projected that it can only be delivered [meets DOD] over 3 sprints and they don't want to break down the tasks smaller. 

The expected outcome to meet DOD is that the following are completed:

  • Investigation task completed
  • Coding completed
  • Dev tested
  • Code reviewed
  • QA test
  • Merge

How can the team deliver value at sprint end if expected outcome cannot be achieved within a sprint? Is it ok to carry tasks over multiple sprints until DOD is met?

07:36 pm February 27, 2023

Why doesn't the team want to break the work into smaller units?

Scrum prescribes that Product Backlog Items become ready for selection when they can be Done by the Scrum Team within one Sprint. My preference, also based on my experience, is to go smaller - it is better if a Product Backlog Item can be something that the team can get to Done and then deliver or demonstrate to key stakeholders in a couple (2-3, at most) days.

I would want to understand why the team isn't refining and decomposing this work into smaller chunks that can help the team ensure they are building the right thing. What would happen if, after three Sprints, they show all this work to a key stakeholder and they built the wrong thing? How can they show progress with the work if it takes 3 Sprints to get it to Done?

10:13 pm February 27, 2023

Scrum is not some sort of reductionist process where large pieces of work are chunked down for delivery in Sprints. Scrum is about learning to build the right thing at the right time.

How can the team reduce the leap-of-faith they are taking in this work before they get an empirical outcome, and assumptions about it are validated? That's the challenge.

10:42 pm February 27, 2023

I've faced this before.  The real reason that the Developers didn't want to break it down further was because they didn't fully understand their solution and couldn't visualize a way to break it down.  I suggested a couple of "spikes" to try out some potential solutions.  They were able to do two spikes in a single Sprint and discuss solutions with the stakeholders. They were then able to break it down into smaller deliverables.  It took an extra Sprint to get that information but they were able to deliver the solution in two parts across 2 additional Sprints (i.e. 3 Sprints total). So in the end it didn't save much time but it did allow them to get feedback sooner and it included the stakeholders in the decisions. 

As usual, I agree with everything that @Thomas and @Ian have said.  But I will offer another suggestion.  Let the Developers do the work as they want across 3 Sprints.  However let them know that in every Sprint Retrospective the progress needs to be a discussion.  When they do finally deliver, there should be some detailed, honest discussion about the work to identify if they could have handled it differently.  Make sure that they inspect, adapt, repeat. 

07:04 pm February 28, 2023

Thanks all for the responses. 

@Daniel Wilhite, the developers feel that the story is complex as it involves a lot of database work which only one developer should undertake after initial investigation was completed. Development work alone is estimated to last 2 sprints. Since there would be no release until June, the PO is happy to go ahead with the developers suggestion of how to handle this particular story. This situation is not a regular occurrence but an exception as the highest story points normally allowed in a sprint is an 8.  


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.