Sprint Lengths - 2 week vs 30 days

Question

I want to implement Scrum, but I can't decide on a Sprint length. Ken Schwaber seems to relate that 30 days it the defacto... but I can't imagine waiting 30 days without the possibility of changing direction or reprioritizing.

Our projects usually only last 1-3 months using the waterfall method and moving to Scrum would probably mean less opportunity to fine tune.

I was thinking about 1 week sprints, but this seems like Scrum Micro Management.

Having 2 week sprints would probably be ideal, but I want to know if others out there were able to implement this successfully. What are the downsides? Is it more work/less work/same about of work to manage a team with shorter sprints?

BTW... 3 week sprints seem odd to me, who does a 3 week sprint? Why not just make it 4 weeks. ;)

Answer 1

2 weeks (10 standard working days, if you are a M-F outfit or 12 if you are a M-S outfit) is half a month (a month typically has roughly 20 working days in it, give or take). Also, week is more vague than day but less vague than month, so it makes the unit of measurement in weeks better for more agile (more give/take) development projects.

However, the last time I did anything like scrum, it was on a school project and it wasn't truly scrum. So it was 7 day weeks in a 10 week quarter. I really liked the 2 week block for that situation. I felt that I could get a lot done but we could adjust timelines and plans frequently.

Answer 2

I've worked on teams doing 1, 2 and 4 week sprints. It really is dependent on your organization. I prefer 1 or 2 week sprints. The current team I'm running is at 4 week sprints because we are coordinating efforts of 12 different products. I'm looking to move them to 2 week iterations soon.

The key thing to defining length is getting to "done, done". For some teams, this means in production. For others, it may mean verified by the business to meet their needs using an internal release. I'd start by defining done, done, then looking at how to structure your sprints around that. Ideally all stories are getting to done at the end of the sprint - and you aren't just doing Scrummerfall.

Answer 3

I like two weeks. It forces a reasonable time box on problems yet lets you see results at a reinforcing pace. 30 days is forever. One week could easily be the right rhythm for a fast moving product like a website.

Answer 4

Right now we're doing 30 day sprints, and getting piles accomplished. One reason that 30 day sprints work well for us is that our planning and estimation usually takes 2 days (gathering and deciding which high-level tasks to take from the backlog, taking the high-level tasks and decomposing them, putting estimates on the decomposed tasks, and then assigning them). We also set aside 2-3 days for bug fixing and testing.

We're already at 5 days there, so doing 2 week sprints would only leave us with 5 days of R&D. 30 days has been a great balance for us so far.

Answer 5

Sprint lengths may vary from project to project but should remain constant throughout the same project. The best thing to do is trying to find the most confortable sprint length for your team, I've been using Scrum for two years and now we settled for twenty work days sprints.

My experience tells me that in projects that need fast deliverables and relatively simple programming (CRUD operations, simple grids and forms, etc) it's wiser to go for shorter sprints, like two weeks. For things with higher complexity (like frameworks) probably it's probably better to go for longer sprints, such as four weeks sprints. My current project leans towards the last option.

But the important is choosing the length confortable for both the team and the product owner.

Answer 6

The product owner should allways have the opportunity to change prioritations and directions. One of the purposes with SCRUM is to embrace changes and let the product owner be the responsible for priority by looking at the business needs and developement team responsible for delivery on time.

So even if you have a 3-week sprint, doesnt meen that the product owner has to wait 3 weeks if he find out something that (possibly) is going to break the sprint.

In some rare cases you have to stop a sprint in the middle and create a new because of new information or new prioritations.

Answer 7

I was thinking about 1 week sprints, but this seems like Scrum Micro Management.

Yes, but this will cause you to do more Scrum: you'll do a sprint planning, an iteration demo and a retrospective every week. The downside is the overhead, however, you spend less time planning, demoing and "restrospecting" a one week iteration than a one month long iteration.

The shorter the iteration, the faster the team learns the process.

Now, depending on the kind of project, it might hard to be able to achieve something valuable in a one week delay.

Before I forgot, I do not do three weeks iteration :o)

Should you go with four weeks iterations, you also have the possibility to replace tasks that have not been started with tasks estimated for the same amount of time.