2010-06-17

Sprint length: it's all about batch size

What is the ideal 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 overhead take?

For my teams, two weeks is the right sprint length. At one week, our maximum batch size is approximately 0--we add hardly any stories of business value for it to be worth our time, given the other sprint-Done activities that we do each sprint. With a two week sprint, we can add value and get the system totally stabilized and ready for production deployment. More than two weeks isn't worth talking about, because we can get stuff Done in two weeks.

2 comments:

Vineet said...

We have actually found that the sprint length (for us) depends on the stage of the project. For sometime our team had and benefited from really 2+ month long durations without a release - as we wanted to make a number of fundamental updates to challenges that we had. Yes, frequent releases would have been nice then, but we new exactly what our backlog was and it was nice to not have the distractions of the real world to bug everyone.

We came out of these fundamental changes, we were able to add capabilities very easily. So much so that we realized that we needed to spend significant time polishing how all these very different capabilities works with the users experience. We actually started doing very short 2-day sprints with a full day in between just to focus on getting feedback and prioritizing the next steps. Again we really appreciated being able to respond to the feedback really fast.

So, what is the ideal length? Our team might be strange but for us it varies depending on what our teams needs are.

Richard said...

Vineet, I’m worried. You are using the term Sprint, but you are talking about varying durations. If you’re doing Scrum, then Sprints are fixed duration, period. If they aren’t fixed duration, you can’t call it Scrum, and you shouldn’t call them Sprints. It sounds like you are doing milestone based development rather than sprint-based development. If that works for you, great.

My experience is that fixed duration iterations are the best way to understand your team’s capacity, expressed as velocity. Velocity is expressed as units of work completed per time unit. The best practice is for the time unit to be a constant, not a variable. Once you get good at knowing your team’s velocity, it’s easy to predict what your team can get done in the future.

LinkWithin

Related Posts with Thumbnails