TLDR: support should absolutely tank velocity, make the org feel your pain. If they want better velocity they need to invest in shoring up issues. One thing to

TLDR: support should absolutely tank velocity, make the org feel your pain. If they want better velocity they need to invest in shoring up issues. One thing to consider… support tanking your velocity is a feature, not a bug. Sounds like you need investment in support tooling etc that can lessen that burden. Velocity will improve when support is less burdensome. This is obviously not one-size-fits-all advice but worked well for a previous org I was at. If the sprint work will have a side effect of fixing support or support is so intense it requires a majority of the team you HAVE to fix that first regardless if sprint/scrum/kanban, etc. if velocity was super high for a few sprints but regressions/bugs were introduced they could impact future velocity, so those high velocity sprints weren’t as productive as you thought. It’s never just one number. The org I worked at with the absolute worst support/sprint structure also had the only code base I considered “unsalvageable”. They refused to do anything to improve existing processes and spent half of every team’s time on the same support issues on an endless loop. They never had the measurements needed to actually figure out where to improve clients experiences.