2 ms·

Or at least reach an agreement of reserved off-sprint capacity. For example, I've been on teams with minimal ops burden where the manager agreed to keep 1 head

Or at least reach an agreement of reserved off-sprint capacity. For example, I've been on teams with minimal ops burden where the manager agreed to keep 1 head off-sprint to handle emergencies. On typical weeks, that gave the team 15% capacity towards tech debt/better OE... which reduced frequency of emergent events... and when there was a true emergent situation (eg log4j), it was immediately started by that reserved head with no impact on product commitments (that stability then also saved the manager and lead dev's time). That very same team had constant product priority churn, but personally I took no issue with that given the pleasant state of code.

kqr 5y ago
Yes, this is the classic trade-off between optimising the time it takes to get things done, and the time spent doing things. If you want things to be done quicker, you counter-intuitively have to spend less time doing things. Keeping a person in reserve is one easy way of accomplishing that. (Why is it a trade-off? Because when in order to ensure you spend a lot of time doing things, you need to have a long queue of things to be done so you never run out of things to do. That long queue means everything takes longer to get done because it spends more time queuing.)