Skip to main content

team capacity for support & development work

Last post 03:57 pm March 10, 2022 by Daniel Wilhite
3 replies
06:12 am March 10, 2022

How do you deal with agile teams that work on both dev and support with within the same Sprint? Challenge could be that the team does not know how much support work will come their way so it's hard to estimate and commit for Sprint. There could be multiple ways to handle this. But how do you or your team face this? Just curious to know your thoughts!

08:34 am March 10, 2022

The Scrum Guide says:

"The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team."

If technical debt is extensive and renders the Product Backlog too volatile for effective Sprint Planning, then quality ought to be stabilized by improving the Definition of Done.

01:00 pm March 10, 2022

There are multiple ways to handle it, and the best people to choose the right way in a particular case is the team.

I do think the first step would be to understand the nature of the support work. What is causing it?

If this support work is related to poor product quality, then any approach should be focused on reducing the amount of support work by increasing product quality. This may mean investing more in paying down technical debt, spending time fixing defects, or designing solutions that reduce the support work of the development teams.

If the support work is business-as-usual operations and maintenance work, then a good approach may be to plan it as much as possible and have a stable workload between development and support that can be planned on, using historical data. This doesn't mean that every Sprint will have the same balance, but you may be able to find what conditions change the level of support work, detect those conditions, and plan accordingly.

It would also be beneficial to be able to order the support work. Is it necessary? Is it more valuable than the development work? Being able to say "no" or "not now" to support work and placing it into the Product Backlog and planning accordingly can also be valuable.

03:57 pm March 10, 2022

I will echo @Thomas' opening statement.  The right way to decide this is for your team to discuss this and come up with a solution.  This would be an ideal Sprint Retrospective item. 

Having said that, another approach your team might consider is to plan a Sprint that delivers a valuable increment but doesn't require every member to work 8 hours a day.  Take on the support work as it comes always looking at how that work will impact the ability to reach the Sprint Goal. Every day in the Daily Scrum, your Developers discuss their progress and whether the Sprint Goal is in danger.  If they feel it is in danger, conversations need to happen right away with the Product Owner to come to a decision on what to do.  If there is an overwhelming amount of support work, a decision could be made to cancel the Sprint. Or another decision could be to modify the Sprint Backlog if the support work is deemed more important.  Remember this statement from the Scrum Guide's section that describes the Sprint Backlog. 

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

There are multiple options for modification.

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.