I’ve done 1 week to 6 week sprints (yes at 6 weeks we called it a sprint) – if you’re not sure what fits best for you, here’s some guidance.
1 Week – It’s all bugs, it’s all known quantities, you have minimal code and your deployment model is code, commit, deploy. QA happens when you ship to Production, teams of 1 – 2 developers. The Theme is “MVP”.
2 Weeks – User Stories are in the fray now, the team is growing, and there are other people in the mix (product management, QA) but the goal is continued output. Your sprint activities are minimal – plan it out, estimate, review, and demo. Do a retro every few sprints. The Theme is “Keep it Productive and Viable”.
3 Weeks – There is some more maturity in the team now, the first week is spent more on planning, design, estimation, nailing down the work to be done perhaps doing additional unit tests and performance testing. QA has a larger role here. Here the the Theme is “Putting out quality and performant code”.
4 Weeks – Now we’re getting worried because we made our last 3 Week Sprint too big so we tacked on another week because we thought that would be all we would need, okay let’s do that. The Theme here is “No More Bugs, Please”.
5 Weeks – We got it wrong, it’s worse than we thought, we can either start a new sprint or keep this one going because “hey, sometimes things go wrong”. The Theme here is “We can’t Extend this another week.”
6 Weeks – Stop the pressures, how did we get here and how do we get out of it? We underestimated everything, we accounted for no change and we took on way too much work. We need to stop, cleanup and get back to doing our 2 – 3 week cycle. The Theme is “Someone has to Lead this and Get us Back on Track.”
