Ideal Iteration Length, Sprint Length, How Long should be a Sprint or Iteration

New teams struggling with Scrum or Agile adoption more than often struggle with their Sprint or Iteration Length. [Whether or not a Sprint or Iteration is a good thing or needed for Agility is a debatable topic in itself though]. Most of the teams pick up iterations or sprints month or even two months long. Then their idea of Iteration is moulded in Waterfall Phases [this is a Design Sprint, this is a Coding Sprint, this is a QA sprint and this is a Release Sprint] – this is for another day. When deciding on the length of a sprint or iteration, many factors need to be considered:

• Administrative Overhead : Each iteration needs a planning meeting/ game to kick start the iteration. Each iteration would also need a closing/ review meeting. And there will also be a retrospective at the end of iteration. Although one can say that the size of these meetings [minutes consumed] would depend on the length of sprint, so as long as these meetings comprise say just 10% [you can come up with your number] of overall time available for a sprint/ iteration, it should be fine. I personally think this reasoning is fine. If meetings are taking longer, then there are generally Process Smells – Product Owners who have not done their homework correctly or have not had the chance to review the deliverables properly.
• Feedback/ Flexibility : Shorter the duration of the sprint/ iteration, earlier the feedback and correction and more flexibility, longer the duration of the sprint/ iteration, longer the correction – more chances of canceling the sprint and more chances of things being obsolete [competitive advantage erosion].
• How good is the marketing team : If the marketing team is good [Product Owner is good], then he/ she will break the stories or tasks small enough to keep sprint/ iteration length small. He/ she would know the worth and priority for each story or task and help the team pick up most important stuff – minimizing stuff thats not needed – helping the team become Agile.
• How Fast can the team move : This is generally the most important factor in deciding a sprint length. Assuming the team has a good marketing leadership, one reason the team does not commit to a smaller iteration is lack of confidence in themselves. If they had confidence in themselves [they were doing refactoring, TDD, shared code or just were good group of people together].

There was a certain slant for a smaller iteration length in the post. This is because:

• Short sprints make certain bad habits impossible to get away with and certain good habits more attractive to learn.
• Shorter sprints or iterations are difficult for product management team but also most desirable as they can make changes quickly.
• Shorter sprints or iterations force continuous evaluation regularly and quickly.
• Shorter sprints or iterations also allows the team to establish
  an empirical velocity very quickly.

Some people and trainers say that when teams are new to Agile/ Scrum, they could start with 2 week sprint. I generally advise against this. I would rather have them do 1 week sprints with lesser stories – allows them to learn quicker and faster. However, important point to note is that each team is unique and each product is unique as well – hence, there might be cases for 2 weeks as well as 2 months sprints. I haven’t come across any so far though.

Advertisement