Skip to main content

Items in a Sprint don’t get finished and there is spill over

Last post 11:08 am June 12, 2024 by Ryan Kent
7 replies
10:55 am June 6, 2024


I'm new to Scrum and JIRA 

What happens when Items in a Sprint don’t get finished and there is spill over –

Question How does it get calculated from a story point perspective in JIRA in the sense part of the work was completed some was remaining. How can i account for part of the work completed and carry forward for the Story points that are left to be completed. 

If i shift the story to the next Sprint it gives a false view that i have complete more work that is the case as it bcomes skewed 

Reason i am asking is that the company i work for has Tableo Tracking which tracks Scrum KPIs 



07:09 pm June 6, 2024

There's no spill over in Scrum. A Sprint Goal is either met or it isn't, and any unfinished work is re-estimated on the Product Backlog for consideration in a future Sprint Planning session. That's it.

Velocity is the rate at which work is Done, not part done. Any work partly completed, once re-estimated on the Product Backlog, can be expected to lower the overall amount of work remaining.

08:23 pm June 6, 2024

As it's defined in the Scrum framework, work doesn't "spill over". When the Sprint timebox expires, undone work is returned to the Product Backlog, where the Scrum Team (primarily the Product Owner) can reorder it. If there is some partially done work, this could be a factor to consider when ordering the work in the Product Backlog. When the team is planning their next Sprint, they craft a Sprint Goal, but may also select other Product Backlog Items based on their capacity.

In Jira, at the end of the Sprint, you have the option to either move undone work into a new Sprint or to return it to the Product Backlog. Moving it to the Product Backlog first is more consistent with the Scrum framework, but if you know that it's likely to be selected, then it could be easier to move it to the Sprint first.

In my experience, work is either done or not done. There is no partial credit. When using story points, the team will "earn" the full value of the story points when the work is complete.

However, this gets into more philosophical questions about story points and the value of estimation. Personally, I don't see much value in estimating. It's more valuable to decompose the work into the smallest unit of demonstrable or deliverable value, then work on that. You can use flow metrics, like throughput and cycle time, to forecast the amount of work to plan in a Sprint or when a given Product Backlog Item will be done. Eliminating the estimation question saves a good deal of time in refinement, allowing the team to either do more refinement or focus on value-adding work like designing and delivering product changes.

11:20 am June 11, 2024

Aside from the reason why you would use story points or estimation, if you regularly have stories that aren't finished at the end of a sprint, spend a little more energy on your refinement process. It could be that the stories are too vague or too large to get 'done' in a sprint. I also regularly encounter teams that have stories with dependancies on external resources. For example: a story where person X should do something, but person X is not on the team. Those kind of dependancies tend to lead to stories that are difficult to finish. Try to define the 'what' part of your stories to only include things your team can do themselves.

12:52 am June 12, 2024

This is a common question, how to manage the story points on items not finished. Scrum / Agile do not award partial story points as said above. Either the full story point count is included in the velocity calculation or nothing. However at the end of a sprint the items not finished are moved to the backlog and then re-estimated, often to a lower value as some work was already completed. This is were the problem comes in. What happens to the story points "partially" completed? One option is to re-estimate the story points in Jira when the item is put back on the backlog, but keep track of the original story point value. For example put the original value in a Jira comment as Jira don't have "original" and "re-estimated" story point value fields (as far I know). Use the original value then in velocity calculations. 

Unfortunately you use some story point tracking tool, else the recommendation would be to not focus so strictly on precise accurate story point values. Scrum is geared to value work done and sprint goals met, not chasing story points. 


06:50 am June 12, 2024

As most of the people have mentioned, the story should be re-estimated and go into the backlog/next sprint. This essentially means the story will carry a lower story point as some amount of work has been completed. You need to take this point in the sprint retrospective and check why the story could not be completed (could be it was not small enough to be done in the sprint or there were some blocker/dependencies which came into play).

Reason i am asking is that the company i work for has Tableo Tracking which tracks Scrum KPIs 

What KPI is used here exactly? If it is average velocity, it is something very specific to the team for them to know how much work they can get done (and the only purpose it is used for is to forecast). 

Focus should be on measuring the value that is delivered through the increment. Using velocity as a KPI and comparing between teams would be a wrong idea.

08:54 am June 12, 2024

Good point by Ian there. If the team has planned 10 items in the sprint backlog which contribute to a sprint goal, even if 1 item is not completed, it means the sprint goal was not met. Now in that case, few questions arise:- 

  1. What happens to the sprint then? If the sprint goal is not met, what does the team demonstrate in the sprint review? 
  2. Does the team commit partially achieved sprint goal? 
  3. If the team was unable to meet the sprint goal, does it add one point in team's failure board? 

In practical scenario, I have few workarounds for this (strictly remaining inside Scrum boundaries): - 

  1. If by keeping aside the unfinished item, team is still able to deliver value to the customer, let the team commit finished items and demonstrate those in the sprint review. 
  2. The unfinished item can be moved back in the product backlog. Depending upon the customer feedback in the Sprint review, the priority of that unfinished item can be arranged by the PO. 
  3. The team should not be afraid of failures but take them as lessons and Retrospect :) Maybe the DoD or working agreement needs to be changed during the Sprint retrospective, team will discuss and derive a solution to improve the situation. 

11:08 am June 12, 2024

Loads of great advice above. 

I think it is important to see story points for what they are and to understand what they are not. What they are is a relative size in numerical form. A guess. They are not something that can be earned, delivered or redeemed.

The problem with story points being in numerical form is that we want to do math with them. Story Point accounting. This leads us to things like “how can I account for part of the work” and “carry forward the Story Points”.

Story points don’t really provide a representation of work completed as there is no connection to what the velocity number represents. 13 points could mean 1 backlog item, 3 backlog items, 13 backlog items…

We want to be careful about normalizing “spill over” or “carry over” as teams can become comfortable with this. To borrow a term from PST Sandur Dur, they get a case of the TANS (There is Always Next Sprint).

The Sprint Backlog is ephemeral. It lasts as long as the Sprint does and a new one is created with the next Sprint. Rather than think about it in terms of “spilling over”, think about the started but not finished work being returned to the Product Backlog, discussed and sized, and pulled (or not, there is always a choice) into the new Sprint Backlog if it serve the next Sprint Goal.

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.