If you're thinking of changing your sprint length, but aren't sure if you should run shorter or longer sprints, here are some heuristics that I've observed. First, I'll give you some background on what I've tried.
At a previous startup, we had 1 week sprints. That worked fine at a startup because everyone did everything. Devs were devs, but they were also client services, designers, DBAs, and devOps. Later, while working at a more established company, we ran three week sprints because there wasn't a pressing reason to change. Let me rephrase that last comment. The established company was used to running sprints like every other established company and 'best practice' was equivalent to whatever was in standard training materials. Now, after switching from a Kanban style (for reasons I won't discuss here,) I am back to 1 week sprints. I feel like that's currently the best match for the company I'm at.
I understand that there are trade-offs in the sprint length that is chosen. So I'll get on with the actual heuristics I'm using to set my sprint lengths.
<------------------------------------------------>
SHORTER LONGER
smaller feedback loop You know your strategy
Forces you to break up issues Priority of features doesn't change often
You may be reactive You're just starting out and going with historical opinion
I hope you can use this scale to better match up your circumstances to an appropriate sprint length for your company.
Subscribe to:
Posts (Atom)