I’ve long understood agile sprints to be a fixed set of work. Lately, I’ve had to examine why. I think the principle still stands, and here’s why.
For work to interrupt an iteration, we either
- undermine the work that was deemed most important
- didn’t understand the priorities when planning the sprint
- are surprised by an unforeseen high priority
None of those are good scenarios or things we want to happen often, if at all.
Emergencies and misunderstanding happen from time to time, but frequent occurrence creates an unsustainable workplace. It leads to frustration, burnout, and unsatisfied customers. Frequent mid-iteration change means our planning and discovery are insufficient to last a week, let alone reliably set expectations and satisfy customers.
This task churn is a vicious cycle. Long term improvements and personal growth are usually the first to get dropped for tackling emergencies. This cuts off the improvement that could lift a team out of the emergency cycle. Compounding the issue, task churn increases context switching and decreases implicit commitment to the deliverable, which reduces productivity in the short term too.
I don’t mean to discount continuous priority systems (e.g Kanban). Such methods still define controls to limit switching once work items are in-progress. However, I think fixed-length sprints are a sharper tool for teams dealing with high uncertainty. Sprints require less intentionality and include more scheduled opportunity to recognize issues with priority and planning. Sprints also set a simple expectation to regulate customer-developer relationships while giving both parties appropriate control.
Conclusion
I still believe that work planned for a sprint should be stable, and now I have a clearer picture of why. Churn and stability are indicators of how well we understand our customer and how well we plan. A firm process for containing churn is the foundation for shared expectations, delivery forcasting, and wider planning predictability.