Skip to main content

Bandwidth Issue

Last post 11:50 pm August 19, 2025 by Chris Belknap
5 replies
03:18 pm August 19, 2025

I have a situation in which QE is working on 8,8 pointer two left out user in the current sprint and developers 2 out of 3 don't have any user story to work in the current sprint. So, I advised them to pick from backlog and keep it in backlog because only 2 days left for the sprint to complete and QE's don't have bandwidth so they won't be able to complete the user story if new user story is pulled in the current sprint.

My question is 

Is it a right approach to ask dev to work from the backlog user story or should I pull the new user story in the current sprint knowing that it will lead to spill over?


04:26 pm August 19, 2025

It seems to me the real issue isn’t whether to pull more work, but whether the Scrum Team is focused on achieving a usable Increment and meeting the Sprint Goal.

Scrum isn’t about keeping individuals busy; it’s about the entire Scrum Team being accountable for delivering value. Everyone is responsible for the Increment and quality, not just the QE role. If some Developers have availability while others are bottlenecked, then the team should swarm on the unfinished work. That can mean pairing, automation, exploratory testing, or simply helping QE complete what’s needed.

Pulling in new stories with two days left only increases the risk of spillover and distracts from what matters: finishing what’s needed for the Sprint Goal. A transparent Sprint Backlog shows what is achievable in the Sprint, not a holding place for “extra” work.

In short: the right approach is "all hands on deck" to get to Done. Get into the mindet that every Sprint might be your last.

All the best.


04:35 pm August 19, 2025

Thanks @chris it helped. :) 


05:41 pm August 19, 2025

I advised them to pick from backlog and keep it in backlog because only 2 days left for the sprint to complete and QE's don't have bandwidth so they won't be able to complete the user story if new user story is pulled in the current sprint.

Which backlog did you advise them to pick from? If it's the Product Backlog, it might be wiser to spend the time refining it.


09:30 pm August 19, 2025

"Get into the mindet that every Sprint might be your last."

That actually sounds like a very bad advertisement for Scrum to be honest.

You know, anxiety, so on. 

Idk Chris, how long have you lived from invoice to invoice?
 


11:50 pm August 19, 2025

That actually sounds like a very bad advertisement for Scrum to be honest.

You know, anxiety, so on. 

Idk Chris, how long have you lived from invoice to invoice?

Allow me to clarify. My statement wasn't about about fear or anxiety. It’s about urgency and intentionality. I've seen too many teams treat Scrum like an infinite treadmill. When we assume there’s always another Sprint, we delay improvement, skip feedback, and roll work forward endlessly.

Also, I’ve done my fair share of invoice-to-invoice living, which is exactly why I don’t take time, value, or opportunity for granted.

All the best.


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

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.