Beyond Fixed Sprint Duration
Everything starts for good reasons. When you start a new project, getting a cadence, a sense of progress, a way to see the journey done so far and what lies ahead provide benefits. But has you progress, it is time to revisit this cadence.
Choosing a sprint length at the start of each sprint is a waste of energy. Experiment with a couple of lengths, make a decision, and stick with it until there is a significant reason to change. — Mike Cohn
Sprint duration gets fixed because it’s supposed to help. But do you always need that help? I say no. You should outgrow the need for fixed duration sprint. Like a crutch help you at first, but once you feel better you feel fine to walk alone. And the crutch is slowing you down at that point anyway.
The best rhythm is natural. It fit the process without problem, because it kinda happen anyway if you don’t do anything special. But what if the natural rhythm for developing stories isn’t the same as for doing the design work? What if it isn’t the same as what works for QA, or production deployment? Even more, what if it vary from story to story? If you have a fixed sprint duration, it would not fit the natural rhythm of the majority of the tasks involved.
With fixed sprint duration — the length doesn’t matter — you are forcing an unnatural cycle on your team. Will work for some, will make others’ lives harsher.
Work doesn’t have to be that way. If you let go of the fear of not doing exactly the same popular fixed sprint pattern and look for solutions that better suits you and your team instead, you open a door on endless possibilities. Should you consider a pull approach instead ala Kanban? Or varying the sprint duration based on size of stories? What about decoupling prioritization of stories from development from QA from deployment, having difference cadence for each? You can re-prioritize the backlog every 2 weeks, have 1 week long sprint, 3 days short QA cycle, and deploy on Monday whatever is viable at that point?
There are teams delivering value in shorter cycles: e.g. Google and Facebook perform continuous delivery and release an updated product multiple times per day. While continuous delivery can be done within the Scrum framework, some of these teams apply other agile frameworks like Kanban. — Matthias Orgler
The idea is to take the time and think about this. Why are you using a fixed sprint? It might be what’s best for your team currently, but maybe not. Discuss this with your teammates and see if you could improve your productivity by giving you more flexibility on that part. You don’t become a rock star by following the trend; you have to find your own rhythm.
Originally published on Medium