Archive for Sprint

A Sprint is different from an Iteration

Posted in Agile, SCRUM with tags , , on March 8, 2009 by vikramadhiman

In other frameworks under Agile, the term iteration is used to define the time period in which plan and develops an increment of functionality. So, why introduce a new term – sprint in Scrum.

The obvious answer [and correct one too] is that Scrum borrows a lot of terminology from Rugby [including the word Scrum]. A sprint in Rugby is a distance an athlete would travel from one end to another. Before an athelete or team would sprint, the team would quickly get together and plan how to go about it. During the sprint, an athlete would encounter opposition from the other team and might go ahead with the plan [if the plan still is good] or more likely alter the plan. You can anticipate but not predict the opposition. A sprint tests whether the team is a team, whether they are good or not and their ability to respond to change. It is clear to see why sprint is an appropriate terminology for Scrum. A sprint in Scrum is a time period (can be anything from 2 to 8 weeks) in which the team does whatever it can to develop software as per the features/ requirements that the Team has committed to. It is important to note that during a Sprint, the team not only iterates towards a final product solution, always improving on what they already have, but also take on some additional increments. Hence, product is developed iteratively and incrementally during a sprint. The term iteration can sometimes fail to capture the incremental part of product development during a sprint.

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

Posted in Agile, Release Planning, SCRUM with tags , , , , , , , , on January 11, 2009 by vikramadhiman

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.