Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm new to a small development company (half a dozen programmers and should grow to possibly a dozen eventually). We also have a few external contractors working with us (just to add a bit of complication).

I would like to slowly start adopting Agile, or more importantly short sprints. I was curios to know, from past experience, what would you recommend that our initial sprint length (in weeks) be?

Maybe I can even go as far as asking what is the sprint length of a very mature and experienced Agile team (shorter [2 weeks] or longer sprints [4 weeks])?

My initial thought was to use a shorter sprint, say 2 weeks and then in time, once we get the hang of things and all has smoothed out, we could simply double it to 4 weeks.

share|improve this question
2  
Consider that a short sprint has the advantage of earlier feedback at the cost of more overhead (grooming, planning and other meetings). Also, some complex tasks might not fit into a short sprint (by the time you start to get some real work done the sprint is almost over and you have to start over during the following sprint). So I find your approach of starting with two-week sprints and then gradually moving towards longer sprints a reasonable idea. –  Giorgio Aug 12 '13 at 13:07
    
@Giorgio: how is that more overhead? Aren't grooming, planning and other such sessions supposed to have a length proportional to the sprint length? The time taken by daily stand-ups is the same regardless of sprint length? But I agree that complex tasks are not easy to fit in very short sprints. Sometimes you just can't break something down any further. –  Marjan Venema Aug 12 '13 at 17:34
    
@Marjan Venema: I am not sure if the length of these activities is exactly proportional to the sprint length: I would expect that there is always a fixed cost associated to each meeting or presentation and that a four-week sprint will have less overhead than four one-week sprints. If there was no fixed cost you could make your sprints as short as you want (e.g. have 2-day sprints, or 4-hour sprints). Also, the duration of a meeting is not the only overhead: the productivity before and after each interruption can be lower (see e.g. point 1 in paulgraham.com/head.html) –  Giorgio Aug 12 '13 at 23:50
    
@Giorgio: It's recommended to be proportional, but no, it doesn't have to be exactly proportional. And you certainly have a point with the interruption overhead! –  Marjan Venema Aug 13 '13 at 7:18
add comment

4 Answers

DEFINITELY use shorter sprints.

Two weeks is very common, and it's what I've used before.

The entire point of agile is to get rapid feedback an adjust your course as you go - the longer the sprint, the longer you go between course adjustments. Especially when just starting out, this is problematic, because you can end up doing the wrong thing for a month before you adjust.

share|improve this answer
add comment

Two or three weeks would likely be best to start with. Remember, you aren't making a life-long commitment to one or the other, so which you choose isn't critical. Pick something, anything, and stick with it for a while. Discuss how it works in your retrospectives. Once the team has enough data to make a decision, let them make that decision.

Some people think four or more weeks is a bit long for a sprint, though others think it is about right. However, since you are just getting started, having shorter sprints mean you spend a bit more time in planning meetings and retrospectives, which is good because the practice will make your team stronger.

share|improve this answer
add comment

It will depend on your team's ability to adapt to the sprint structure and discipline, but when our company transitioned we found that two weeks was too short when we were still adapting to the framework. Consider that the first few times you do estimations, planning, retrospectives, daily stand-ups, etc. you will likely take more time to do these and learn about them initially.

I would consider starting with a 3 week iteration, and doing that 3 or 4 times. Once your team is more comfortable, you might be able to bring it down to a 2 week iteration, or you might find that 3 weeks is the perfect comfort zone. My first few projects I ran with 3 week iterations, and I found it was just a few days too long for my liking, and have more recently transitioned to the 2 week time span and it goes by lightning fast.

I would not recommend going to longer sprints after you get comfortable, unless you are trying to do several 1 week iterations very quickly to get everybody used to agile and then slow down to a 2 week interval. The more often you release, the more feedback you get and the greater your agility to change directions.

share|improve this answer
    
I agree with your answer but I would like to comment on this statement: "The more often you release, the more feedback you get and the greater your agility to change directions." The goal is to be "as agile as needed" not "as agile as you can". So, depending on the customer and the kind of product, two-weeks may be too long or two short. Changing direction very often can be a requirement but it has a cost. So, for certain projects, one-week sprints may be appropriate, for other kinds of projects, four-week sprints may be a better choice. –  Giorgio Aug 12 '13 at 14:22
add comment

Having implemented Scrum in a few teams I would suggest starting with two week sprints. This is because it gives you a lot of retrospective meetings, allowing you to identify and discuss process improvements, so you can hone your actual Scrum processes quickly.

Once the team are comfortable with Scrum and how things work (maybe 5 sprints) I would suggest the team to try a three week sprint, and then see how it goes in the retrospective. From here most teams I have seen will opt to keep three week sprints. After a few you could offer the suggestion of a four week sprint if you think it worthwhile, but it is vital it is the teams decision. Most teams I have worked with settle on three weeks.

There are many advantages and disadvantages to differing lengths:

  • Frequency of retrospectives and reviews. 2 weeks allows more frequent feedback from business and team, so story priorities may change, as well as development processes within the Scrum process. At an early stage, regular retrospectives are extremely useful.

  • Pressure on team. With short sprints release is always just around the corner, and depending on the individuals in the team 2 week sprints can be very stressful. On the other hand 4 weeks (or longer) can lead to relaxing at the start. This is why personally I prefer 3 week sprints once the team is settled.

  • Unforseen Complexity. If a task is larger than anticipated, a short sprint makes it harder to make up lost time. This can lead to not delivering everything comitted, and potentially demoralise the team. This is more applicable in small teams.

  • Rhythm. So long as the meetings are well run, shorter sprints provide a good rhythm to the team, while it can be harder to get into the groove when you only have a four weekly meeting.

  • Achievement. With 2 week sprints, the end of the sprint may not feel particularly special. With longer sprints, you get a real sense of achievement and reason to celebrate. I find teams still feel like it is a celebration with a 3 week sprint.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.