Long story short few weeks ago we switched to 1 week sprint. You can read my early notes here: 1 Week Sprints Hurt. But in a good way.
After few sprints the 1 week rhythm feels natural now. We got used to more frequent planning, review and retrospectives and the business got used to frequent demos and frequent updates of the apps we are working on.
We still feel like we are in hurry all the time (we truly are – as a startup we follow the “conference-driven development” approach) but we got used to this.
We got definitely much better at organizing our work. It is obvious now that some tasks are too big to fit into a sprint. It is also obvious that if we don’t start some tasks right after the planning we won’t finish them on time. There is less friction in our cooperation and we are able to keep the quality high (no QAs on the team, or rather we are all QAs).
With 1 week sprints it is easier to focus on one particular theme. It is even possible to have a “only new business features” sprint and move all the infrastructure-related task to the next sprint. Which, as you can imagine, business loves.
My worst mistake? Not informing the business what we are trying out so they got very worried about the team performance (it took few sprints before we learned how many tasks we could close during a sprint).
It seem we will stick to 1 week for a while
Some team members say they would rather have 2 weeks sprint. But under closer investigation it seems it is more a personal preference than anything else (see TODO my x better than y). So, in the absence of good arguments to change sprint length we stay with 1 week.
P.S. Yes, it sill hurts, but hey! – pressure makes diamonds – don’t you know it?
P.S. 2 Last week for some reasons we had a 4 day sprint. And we did it quite well.