Re: Best sprint length
- I've been thinking about this a couple of ways. First, what is your definition of Done? For my teams, Done means, concisely, it can be deployed in production, and people can use it world-wide.
Then, think about your minimum batch size. How much work do you have to do to be able to add some business value and be Done at the end of a sprint? In addition to implementing new stories, what other things do you have to do each sprint to be Done, and how long does that stuff take?
For my teams, two weeks is the right sprint length. At 1 week, our batch size approximately 0--we can't add enough business value for it to be worth our time, given the other Done activities that we do each sprint. With 2 weeks, we can add value and get it totally stabilized and ready for production deployment. More than 2 weeks isn't worth talking about, because we can get stuff Done in 2 weeks.
--- In email@example.com, "Joe" <jhlittle@...> wrote:
> There is a poll about the best sprint length.
> I think the question should be re-worded. A given sprint length does not fit for every situation. There are probably in some domains & situations where "working product" can not be done in 4 weeks. (Very very few in my experience.) I find most domains can do it in 2 weeks (maybe after a few impediments are removed). But the more feedback the better...a few domains can do it in 1 week. Or even less.
> So, "what is *typically* the best sprint length?" is a better question. With some explanation for those who haven't thought through the issues.
> I like 2 weeks especially because 2 + 2 = 4 weeks, which is also useful as a feedback cycle. As Ken Schwaber is very fond of, for good reasons.