Skip to main content

User Story too large to do by end of Sprint

Last post 03:49 pm August 25, 2023 by Thomas Owens
12 replies
12:40 pm August 23, 2023

I couldn't find any similar posts, perhaps my search terms weren't good enough so started a new question. 

I hear this a lot from the team "I know there are only 2 days left in the Sprint but we just need to be working on this new User Story as it's key to what we're trying to do, it's just going to have to carry over". 

Any feedback or suggestions on how I get better at handling (or pushing back) on this kind of thing? 


I don't want Scrum to be a blocker to the team working on the correct tasks, but I try to avoid this as to not have unfinished work so will normally suggest the PO load in something else that can be Done by Sprint end. Deep down, I feel this is wrong. I challenge the team to break the priority work down into smaller parts so that parts of it can be done in the Sprint, is that all there is to this or am I missing something? 





12:52 pm August 23, 2023

A few questions for the team before pulling in a new PBI:

  • Has the Sprint Goal been met?
  • Did we create at least one valuable, useful product Increment this Sprint?
  • Did we complete all action items from the past Sprint Retrospective that we said we would finish this Sprint?
  • Would pulling in this new PBI jeopardize our Sprint Goal or Done Increment?
  • Do we have any lingering technical debt that should be cleaned up?
  • Does the team need any additional cross-training to help them be more cross-functional?


12:54 pm August 23, 2023

Thanks Chris - the work they request to be pulled in is part of the Sprint goal. So they got through their PBI's but now there is some space, they want to pull in the next backlog item but its far too large to fit in with the remaining days. 


Some other good suggestions there. 

01:23 pm August 23, 2023

John - I'm confused. If the new PBI they want to pull in is required so the Developer's can meet the Sprint Goal, the next step is for them to negotiate the scope with the Product Owner so that the PBI can be finished by the end of the current Sprint.

If the Sprint Goal is intended to span more than one Sprint, perhaps the Sprint Goal is too vague and that should be discussed in the Sprint Retrospective.

All the best,


01:48 pm August 23, 2023

the work they request to be pulled in is part of the Sprint goal. So they got through their PBI's but now there is some space

What commitments have they made, and have they met them at this point? Perhaps this matter is not as transparent to the team or to others as it ought to be.

01:55 pm August 23, 2023

I'm confused by this situation.

The Sprint Goal was established at Sprint Planning. If this large Product Backlog Item was truly necessary to achieve the Sprint Goal, it should have been pulled into the Sprint at Sprint Planning and not in the last 2 or 3 days of the Sprint. Unless the team is just realizing that this work is necessary to achieve the Sprint Goal, then I don't understand how the team got into this situation.

03:19 pm August 23, 2023

Basically best thing to do is to try your best to meet Sprint goal while working in a regular cadence, and discuss this story at the Retrospective.

It takes time for teams to master the good Sprint planning and create good Sprint goals without items falling on their head during the sprint to meet the sprint goal, so never take such situation as an emergency which should be solved by any cost(unless it is for external reasons)


03:26 pm August 23, 2023

I have been here before.  While this may not be the case for you, what it boiled down to was the Developers really wanted to work on that item because it was using some new tech.  It had nothing to do with it being related to the current Sprint Goal.  It was also a way for them avoid working on things like backlog refinement or fixing some small technical debt.  However, the Developers had learned enough about Scrum to know that if they said it was related to the Sprint Goal, they might get away with it. 

I brought it up in the next retrospective because they had 2 days in the previous Sprint to work on it and finished it the morning of the second day of the current Sprint.  I asked them why it was so important that they start working on it early since it could obviously have been done in a single Sprint rather than spreading it across two Sprints.  That was when they admitted it. 

The next time they tried this, I made a deal with them. I told them that we would follow Scrum guidelines and return the item to the Product Backlog at the end of the Sprint if they had not finished and it would be ordered appropriately by the Product Owner.  They agreed, the item was not finished and it returned to the Product Backlog.  It was not ordered high because feedback from the Review made the work unnecessary at the time. 

Let them work on it and use it as an opportunity to learn.  Inspect and adapt with everything.

05:25 am August 24, 2023

I see here a couple of issues, which should not be mixed up.

When the PBI is essential for the Sprint goal, the sprint goal needs to be discussed in the retro and maybe the team needs more insights on how to craft a better sprint goal or/and why this PBI has been forgotton to be added during the planning. Especially when the metric for the sprint goal is not well defined and it lets space for too much discussion, then you can trap into the situation that someone come up with "hey, this PBI is also part of the goal".

Carry over are not bad per se. I know this discussion where someone says "Everything in the sprint = commitment = needs to be finished at the end of the sprint". Carry over needs to be discussed when they are part of the sprint goal and if they really needs to be carry over. 

10:02 am August 24, 2023

A few things stand out for me…

“carry over”

Just because work is started, it doesn’t mean it automatically continues. There ought to be choice based on Stakeholder feedback, market needs, learning etc. This would really be a PBI that is started and not finished. As Daniel mentioned in his post, this ought to be put back into the backlog for consideration at next Sprint Planning (and not just “carried over”). Consider dropping “carry over” as a term.

“the work they request to be pulled in”

Developers are accountable for the Sprint Backlog (a plan by and for Developers), and no request needs to be made to pull in a PBI to achieve it. If they are calling out that the Sprint Goal is jeopardy with this newly discovered requirement, then scope can be negotiated as others have mentioned.

“So they got through their PBI's but now there is some space”

“Got through their PBIs” is different from achieving the Sprint Goal. If the newly discovered work is a must have for the Sprint Goal, and they cannot complete it in the remaining days, the Sprint Goal is now in jeopardy. Consider focusing on that. Scope can be negotiated with the Product Owner as a first step to determine what can be done to achieve the Sprint Goal.

11:43 am August 25, 2023

Any feedback or suggestions on how I get better at handling (or pushing back) on this kind of thing? 

Direct pushing is rather not a good idea, nor does the Scrum Master have any sort of authority to 'rule' the Developers etc...

The SM makes sure that Scrum is established with all its events, and artifacts. Through training, coaching, helping, and facilitation SM is causing everyone to understand Scrum and enabling them to make decisions in accordance with Scrum so that they can keep improving. 

It is of course easier said than done. Anyways, it is better to ask questions than to provide solutions.

You may ask the Scrum Team: 

- What is standing in our way of delivering a Done Increment of Value every Sprint?

- Was our Sprint Goal clear enough or too ambiguous? How to set better goals?

- Are we OK with the current duration of the Sprint? What can we gain or lose if it is longer or shorter?

- Are there any ways we can improve our forecast or better track our progress in the Sprint?

These are obviously very broad examples of a question and knowing the details of your situation you can ask more targeted things. 



12:23 pm August 25, 2023

Thanks for the replies, these are helpful. Allow me please to clarify what I was asking as I notice there was some confusion? 


Sprint goal agreed

items pulled into sprint

some devs had run out of things to do 

so PO wanted the next high prioirty thing Done


Was too large fit into remainign days in Sprint


I suggested this not to be brought in as too large, but team and PO state "but it's somethign we need to work on, we will just carrythe remainder onto the next sprint."

03:49 pm August 25, 2023

It's not up to the Product Owner to tell the Developers what to work on. The Developers select work for a Sprint and plan how that work gets done. The Product Owner collaborates with the Developers at Sprint Planning, can collaborate with the Developers regarding work that may be discovered during the course of a Sprint, and can keep the Product Backlog ordered so the most important thing is up next. However, the Product Owner cannot tell the Developers what to work on or how to use the time within the Sprint.

I'm struggling with the fact that "some devs" ran out of work. This seems to mean that there is still work that was initially selected for the Sprint that remains undone. Rather than starting new work, I think it would be better to consider how the Developers who finished "their" work can help get this other work to a Done state.

My biggest problem with starting the next highest priority Product Backlog Item, especially when the team says it can't be finished within the Sprint, is that any stakeholder feedback received between now and the next Sprint Planning, especially at the Sprint Review, could make that work less important or urgent for the team to work on. Since it won't be done, the team will have to make the decision to finish the work that is now no longer necessary or carry around undone work as waste.

There's plenty of valuable things that could be done instead, ranging from helping other members of the team get work Done to paying down technical debt to cross-training on new knowledge and skills. These are things that can support the team's current Sprint Goal, make the team stronger and more capable for future Sprints, and not have the risk of waste in the process.

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.