Selecting the right iteration duration [closed]

Question

I've long argued that "1 week" makes a great iteration duration. It forces the issue of getting SW Dev tools operating smoothly and effectively, it also makes it much harder to operate a "dev then kick it over to test" mentality.

I know the rule of thumb is "2 weeks" and I've heard iterations running as long as a month. I've run iterations lasting both 1 and 2 weeks and listened to many reasons and factors being considered for selecting one duration vs. another.

Question: What factors do you use in selecting your iteration length (Sprint duration in Scrum)?

Also, have you found one duration that works better than another in practice, but I'm most interested in the factors considered when you chose a duration. (I'm less interested in 1 week vs 2 week vs N week answers)

Answer 1

I don't believe there is a single good iteration length or an ideal we should aim toward.

In terms of setting iteration length probably the best advice you can get is: do what works for you.

There are teams which adjust well to short iteration, hence one week. There also are people who work efficiently when they have a longer plan ahead, so three- or four week long iterations. Some people experiment with extra-short iterations, like one day long. More and more teams abandon time-boxing and go iterationless but it is usually interlaced with switching to Kanban.

You can look at it from a perspective of flexibility versus predictability. The more flexibility you need the more you will lean toward short iterations. On the other hand if predictability is something your organization values highly you will find it both easier and more convenient to have iterations longer.

So in short:

• Think about the length the team feels comfortable with.
• Think how much predictable and/or flexible you need to be to achieve your goals.
• Remember there is cost attached to start and finish of each iteration (prioritizing backlog, planning sessions, demo, etc.) and plan for this.

And then experiment to find the right iteration length in your specific case. This means you might want to change it and measure your productivity against different cadence.

Answer 2

We keep all iterations at 1 week.

It only causes difficulties if the feature in the backlog doesn't fit 1 week (very rare).

Otherwise 1 week seems the natural rythm and keeps everyone, including customers alert and communicative.

2 weeks, in my opinion, would provoke "I can make it next week" thoughts, which are unwanted in rapid software development.

Answer 3

Factors I use to determine iteration duration

• Amount of infrastructure needed for each feature - some products require a deeper vertical slice through three or more technology layers. These can take longer to develop a feature and so I tend to favor 2 week iterations
• Number of external systems interfacing with the product - the more external systems that are needed the more I tend to 2 week iterations
• Customer feedback turnaround time - some customers take 3-4 days to provide feedback on releases, others can do it on a moments notice. Longer customer turn around time tends to the 2 week timeframe.
• Degree of homogeneity of the team - If the team is made up of multiple different specialists then an iteration might need to take longer to spread the knowledge/experience across the team. If the team is made up of generalists, then it tends to lend itself to shorter iterations.
• Degree of integration with SQA - If the existing tendency is to dev then hand to test, I've noticed a shorted iteration forces this to change and have the team realign the SQA and Dev teams to be more tightly integrated.

I'm sure there are others, and I'd appreciate more people providing answers based on their experience.

Answer 4

I feel there are three issues to consider;

1. the level of automation available
2. the maturity of the team
3. built in overhead of Agile Ceremonies

Short iteration cycles are dependent on high levels of automation 1. Automated Build 2. Automated Deployment 3. A high % of automated testing both functional and regression

If these system are not in place you will very quickly get to a point where your velocity drops because the code base has reached a point where it takes so much time to do all these steps manually that there is no time to develop new features.

The maturity of the team and the overhead of agile ceremonies are interrelated. If a team is new to Agile it takes longer to groom the backlog, task out stories for the iteration planning meeting and get through the review and retrospective meetings.

In Ken Schwabers book “Agile Project management with Scrum”, He suggests time boxing your Sprint Development Meeting to 8 hours, your Sprint Review to 4 hours your Retrospective to 3 hours and your daily stand up to 15 minutes a day. Added all up you have just spent over 40% of your development time in meetings.

Granted when he said this he was talking about an iteration length of 4 weeks or roughly 10% of the available development time. While I agree that smaller iterations require shorter meeting times I don’t believe nor have I ever seen all these ceremonies compressed to fit the 10% time commitment suggested in Ken’s book and this delta between optimal and actual is larger the less mature the team is.

Personally I would not want to go smaller than two weeks but if the team wanted to try a week I would be willing to try. I just think that the value derived would be smaller. I guess I will have to try it and develop some numbers.

I would be interested in hearing your results.

Answer 5

In our project there are lot of stake holders. Getting requirements can easily take 1 week, as there is lot of discussions to understand what they do. Build and deployment process takes about 2 days. We started with 3 weeks Iteration. The client expects waterfall results. We have changed this to 5 weeks. A weeks worth of testing. Now we can build almost bug free functionalities in 5 weeks.

Answer 6

For me it depends on the type of project. If there's going to be a lot of experimentation with the direction of the product then I gravitate to 1 week, otherwise I prefer a 2 week iteration. Any longer than that is too long in my book.

This would be a good question for your team. i.e. What iteration length do they prefer and why?

Answer 7

I would also have to agree that 1 week works great for starting up a team or for addressing continuous issues. As you mentioned it ensures the technical practices like automated testing and continuous integration (which are critical to a smooth agile process) are in place and working well. I think 2 weeks is also a very good length and once any technical issues have been ironed out may be worth considering moving to. If you have a product owner that needs to travel to meet with clients, 2 weeks may actually allow him/her to be more engaged with the team as it gives a slightly longer window for him/her to plan travel in and still be able to consistently make it to the planning, estimating, retrospective meetings since those would happen every other week instead of every week.

I would not recommend anything over 2 weeks. We started with 4 week sprints and we had a lot of troubles making commitments that far into the future. You also got into the issue of things expanding to take as long as you have to complete them. So we found that 4 week actually hindered predictability in contrast to what Pawel suggests, though it could have been specific to us. Generally speaking, it is easier to plan smaller chunks of work over a shorter period of time, so if your team is consistently struggling with planning, my advice would be to shorten your sprint length rather than lengthen it. Once the team starts getting consistent with planning and meeting commitments, if there are other reasons to lengthen the sprint you may try that, but in my experience, lengthening a sprint almost never helps with planning/commitment.

Answer 8

We are now on 2 week iterations, and thinking on switching to 1 week. But, we are distributed (stakeholders, devs, po -- everyone is in separate cities), hence communication IS issue. So we think switching to 1 week would: 1) higher our costs (travel costs, communication costs) 2) unable PO to investigate more before handling over stories to the team.

Those are our reasons....

just my 2 cents.

Answer 9

I've seen teams fixate on (say) "one week" and then design their sprints to fit into "one week" when they are naturally bigger. Sprint durations don't have to be of equal length, anyway. Look at what is a "logical, self-contained" piece of work-to-do-next, estimate how long you will need to do it, and add a week. (Programmers always lie...)