team capacity for support & development work
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!
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.
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.
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.