Skip to main content

Adding new items to the current Sprint

Last post 09:26 am June 12, 2024 by Joeri Mastop
4 replies
03:22 pm June 4, 2024

Hello! I am part of a scrum team and i am facing some difficulties regarding the best practices of a sprint's workflow.
From my past experience, when you estimate the amount of work (in time) ready to be assigned to a Sprint, it must exceed like 70% of its capacity to allow enough time for unplanned issues (critical items that needs to be done ASAP). So in the remaining 30% of the capacity you can either insert critical unplanned items or if the sprint goal is achieved you can bring new items from the backlog.

The workflow of my current team is not efficient from a Sprint perspective (in my opinion). To be mentioned that i am part of a Scrum Agile team.
So, they estimate and plan the Sprint and load it to 100%.
During the Sprint, they also work on issues from the backlog.
At the end of the Sprint, lets say either they reach the goal or even not, but the real amount of time spent is at least 30% for the issues in the backlog. Is the time spent on issues outside the Sprint, counted in that Sprint?

How to properly manage a Sprint? And i also have some scenarios:

1. You drag items from Backlog in the current Sprint. You work on items and then you add extra work time to the current sprint.
- for this scenario, lets say that the sprint load is not 100% but 80%
- lets say that an individual just finished his tasks earlier and has some time left, so he drags items from the backlog. 
Isn't this the right approach? Why would you work on items outside the Sprint? Usually the retrospective of the Sprint is based on what have you worked. And what have you worked should be displayed in the Sprint. So if an individual works 40h in Sprint items and 20 on backlog items, during the Sprint retro, it will figure with 40h of work? The 20h are gone in the space?

2. You want to keep the same amount of time (story points) as the initial plan.
You add 10 story points items, you remove items worth 10 story points, so you keep Sprints estimation the same.
I can understand this approach when the time left (other resources) do not allow you to increase the amount of work and you don't want to exceed Sprint's limits in time or leave some tickets unresolved. So in order to add new story points to the current Sprint, you remove the same amount just to keep it even. But i think that this approach suits the cases when you load the sprint to 100% - which i am not a big fan of.

3. You drag items from the Backlog in the current Sprint, and you overcome the estimated time.
Lets say you have an 100h load Sprint and in the end it looks like you logged 120h in the Sprint. 
It can rise some question marks related to the skill of being able to properly estimate the tasks, but this is not the point.
Lets just pretend that the team was very efficient this sprint. They reached 90% of the Sprints goal with 3 days left, and then they drag some items from the Backlog. So in the end they will finish the tasks, log the worktime and the Sprint will be overcommitted with 20h.
This.. or leave the Sprint with 100% load and goal reached and then have some extra 20h on the backlog? What's the good approach?


Long story short. What capacity should a Sprint be initially filled? 100% / 80% / 70% ?
How to deal with items worked on from the Backlog? Should they be inserted in the current Sprint? If yes, how to manage then?


Thanks in advance!

05:30 pm June 4, 2024

Long story short. What capacity should a Sprint be initially filled? 100% / 80% / 70% ?

100%, in so far as there ought to be 100% transparency over the work the Developers are doing.

That 100% ought to include which can be negotiated out of scope if needed, while still allowing the Developers to meet their Sprint Goal commitment. How much contingency is needed will vary by Product or even by Sprint, depending upon the level of complexity and the unknowns being faced.

How to deal with items worked on from the Backlog? Should they be inserted in the current Sprint? If yes, how to manage then?

If new work is discovered which is necessary to meet the Sprint Goal, the Developers will revise the Sprint Backlog accordingly. It is a forecast of the work they believe they need to do to meet this commitment. Any other work may or may not be done this Sprint.

06:08 pm June 4, 2024

There are no best practices when working in a complex environment. What works for one team in their context may not work for another team, even if that other team is operating in the same context. What we can share are good practices that have worked and you can explore if those practices make sense in your context, adopt the ones that do, and then inspect how they may have helped the team.


When using time-based estimates, you are correct that you should leave some buffer. For example, Capers Jones has found that a team uses about 85% of their available capacity for work. I've had the chance to review data from a number of organizations, and I've found that to be on the high side, so I tend to use 70-75% for planning purposes. This means that a 40-hour-week is really 28-30 hours or an 8-hour-day is really 5.5-6 hours. Another way of looking at it is a task that the team estimates to be 5 hours will be about a day to complete. You may be able to collect historical data for your organization and teams to get more precise figures. Leaving between 15% and 30% of the team's total capacity for unplanned work is not only realistic, but a good practice.

Loading to 100% doesn't acknowledge the fact that there are unknowns. The total scope of work is unknown. Although we have refined the work to the point where we are comfortable accepting the remaining risk, we have to acknowledge that we may find additional work is needed to get the work to a state where it's deliverable. The total capacity is also an unknown. Although you know the people on the team and the hours that they work, the total capacity may change if they have to work on things unrelated to the product or take unplanned leave. Planning to less than 100% capacity can help address both of these situations.

It's not clear to me how a team can estimate work, load their Sprint to capacity, get that work done, and get other work done. There are likely many explanations for this. Perhaps they are significantly overestimating the work. Maybe they are working extra hours over the planned capacity to get things done. Understanding how the team is estimating the work and tracking their hours is key. I'd be worried about people working too many hours, especially too often - it's not a sustainable pace and leads to burnout.

The approach that I've found that works well in most situations is:

  1. Craft an appropriate Sprint Goal. It's often helpful if the Product Owner comes to Sprint Planning with a good idea of what the Sprint Goal is, but the works with the team to refine it.
  2. Select the Product Backlog Items necessary to complete the Sprint Goal, based on the current understanding of the Sprint Goal and the Product Backlog Items.
  3. Check that the size of the Product Backlog Items is achievable. When using hours, the estimated effort to complete the Product Backlog Items should never exceed 85% of the forecast capacity, and ideally shouldn't exceed 75% of the forecast capacity. If it does, iterate on the Sprint Goal and selected Product Backlog Items.

Whether the team selects additional Product Backlog Items up to 85% or even 100% of the forecast capacity is up to them. Some teams I've worked with have found it helpful to pull up to the full capacity into the Sprint Backlog, knowing that they probably won't get to those Items. Being very clear about what should be worked on if there is capacity is helpful, though. Other teams prefer to keep their Sprint Backlog focused on only the necessary work until the time comes that they are able to start something new. However, one thing holds true: the Sprint Backlog promotes visibility and transparency into what the team is working on, so anything that the team pulls into the Sprint should be visible on the Sprint Backlog to any stakeholders who can view it.

05:34 pm June 5, 2024

As @Thomas said, here are some practices that have worked best for teams I have been associated.

Forget capacity based planning and focus on value based planning.  Craft a good Sprint Goal, fill the Sprint Backlog with items that will allow the satisfaction of the Sprint Goal.  If you have to work extra hours, you do.  If you get it done before the Sprint ends, pull in some smaller items from the Product Backlog or spend time doing things like refinement, code clean-up, or learning new technologies that might be useful to implement.  This is my favorite and go-to if I have a choice in the matter. 

If I have to use capacity based planning, I tend to look more at throughput and cycle time to plan capacity rather than time.  Time is difficult to predict when you may not have all of the information you need.  However, trailing metrics like throughput and cycle time are based upon actual history.  Look back at the average of how may items the team completed in past Sprints.  Use that to determine how many items they may be able to complete in current/future Sprints. Look at cycle time to see how long items take to go from "ready to work" to "done".  These metrics are easier to explain and easier to justify. I've also found them to be more reliable than hour based capacity.

If I have to use time based capacity planning, I advocate the 70% mark and make sure that EVERYONE inside and outside of the Scrum team understands that our capacity is based upon a lot of guesses (i.e. estimates).  I do not like to track actuals vs estimate because it just leads to a lot of confusion, frustration and anxiety over being judged based upon numbers that you weren't able to completely control. 

09:26 am June 12, 2024

I like @Daniel's first practice also. If you need to talk about percentages in relation to sprint capacity, then the focus of your team (or even worse: stakeholders or management) tends to shift to throughput in stead of value. I only use velocity as a metric for the team itself, to reflect on how they work towards a sustainable pace.

That said, if team members consistently choose to work on PBI's that are not in the sprint, then there is maybe an issue with commitment to the sprint goal, or perhaps team members don't feel they have enough say or influence during sprint planning.

Lastly, if your team worked on items outside of the sprint (and they are 'done'), at least mention them during the review. If they slip under the radar then your transparency is gone. Stakeholders should have an understanding of what the team works on, in general terms. And spend some time with the team to discuss why this happens, for example during the retrospective.

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.