Wednesday, February 11, 2009

How long should a sprint be?

What is the ideal length of a sprint? Sprints typically last two to four weeks, but many factors influence this::
  • The frequency of customer feedback
  • The experience level of the team
  • The time overhead for planning and reviews
  • The ability to plan the entire sprint
  • Balancing the intensity of the team over the sprint
Customer Feedback
The duration of a sprint depends on the amount of time the customers can go without seeing progress and providing input, or direction on the game. Some core mechanics require frequent feedback in the early stages of development, so a shorter sprint is required to be sure the game is headed in the right direction. Some teams don’t need such a rapid cycle of feedback (e.g. production teams) so a longer sprint is better for them.

The key idea is that the team must not have their goals changed within the sprint. If four weeks is unbearably long for customers to wait for a review, then they need to demand a shorter sprint.

Team Experience
The experience level of a team influences the length of an sprint. Teams that are new to game development, agile, or working together, should start with shorter sprints. This allows them to iterate on the practices and learn how to iterate properly. Teams that are new to Scrum should be discouraged from practicing longer sprints. New teams will generally approach a sprint like a mini-waterfall project; (see Figure below) inexperienced scrum teams will still approach development sequentially (one activity after the other). They’ll spend a couple of days exclusively in design, a few weeks creating code and assets and finally integrate, test and tune during the last few days of the sprint. They end up crunching at the end of the sprint to reach the finish line. This doesn’t give them the opportunity to achieve the best possible result.

Experienced teams will perform these activities more in parallel. Working this way creates better results and allows the team to iterate more during the sprint.

Planning and review overhead
Shorter sprints require a larger portion of a team’s time for planning and review meetings. Review and planning usually require a good portion of a day regardless of the length of the sprint. Even though planning for a shorter sprint may take less time, the remainder of the day following the meeting is never 100% effective. Imagine that you had a sprint that lasted one week. You’d probably spend one day that week in review and planning. That’s 20% of overhead!

Plan to party - Allow the team to have a little celebration time between sprints. Besides, game developers don’t need much excuse for a party!

Ability to plan the sprint
If the sprint goal is uncertain: if experimentation or prototypes need to be done then the sprint should be shorter. Uncertainty implies that the work required might be significantly different from the one anticipated at the start of the sprint. If this is the case, it’s better to change direction after two weeks than four.

Prototype sprinting - Some prototype teams have chosen extremely short sprint times of days!

Balanced Intensity
Sometimes four weeks is too long for a sprint. This is especially true of teams that are new to agile. As described above, new teams will work sequentially during sprints. This leads to a low intensity mini-design phase up front and a high intensity debug mini-crunch phase at the end. While the “mini-crunch” isn’t going to kill anyone, it’s not the most efficient way to work.
Teams will find what works best for them.

Choosing a sprint duration - On my last team, two week sprints felt too short. It was as though the review was too soon to “do anything too challenging”. A four-week sprint was too long to create a sense of urgency. We compromised and chose a three-week sprint because “it felt right.”

When is the sprint too long?
A product owner will usually limit a Sprint’s length to four weeks. Some may argue that some technical areas (e.g. engine or pipeline development) cannot achieve any significant progress in as little as four weeks. The need for longer sprints to show value is usually an indication that the technical practices need to change. Any development practice that can’t demonstrate progress at least once a month should be changed. Interim goals can demonstrate a reduction and have value. The longer a team goes without proving or disproving architectural assumptions, the greater the potential waste.

Who selects the sprint duration and when?
The customers and the team needs to be determine the duration of the sprint. If there is a disagreement, the product owner has the final say. The length of the sprint can only be changed between sprints and shouldn’t change frequently. Frequent changes to the length of sprints can be disruptive. It takes time for teams to adjust to this change; the rhythm and pace of a particular sprint length takes some time for the team to adjust to.

Whatever the duration you choose, don't be afraid to change it throughout the project. The conditions listed above will change.


Anonymous said...

I've worked with iterations varying between 2 to 4 weeks. Although most people new to agile tend to prefer a 4 week iteration, they like a 2 week iteration onces they tried it out. The main benefit of shorter iterations is the bigger focus of the team. The sprint review is never far away. I agree with your statement that inexperienced teams should start with short iterations in order to learn the flow. If the customer doesn't like to be in a sprint review meeting every two weeks, you can just demo internally with the option of the customer to attend. Great post.

Ron said...

I've been on teams with 4 week and 2 week sprints. The 1st team I was on fit Noostvog's pattern, started out 4 weeks and went to 2 weeks. We got an amazing amount of work done in 6 months.

Current team prefers 4 weeks sprints, doesn't want the overhead of reviews and planning every other week.

Anonymous said...

I think there is a good arguement for both short and long sprints. It really just depends on the complexity of the project and experience of the team members, especially their experience in working under an agile methodology.