A discussion that regularly comes up with teams new to Scrum is deciding what sprint length to choose for a project.
Although changing the sprint length during a project may help the team become more efficient, it is something that should not happen too often. The goal of maintaining a fixed sprint length is to establish a rhythm of delivering value to the product owner. It introduces routine, making the team more efficient and letting it predict the scope it can commit to in a sprint more accurately. A team should therefore try to select a sprint length that will most likely not require any changes during the project.
While the general rule demands a sprint length of 1-4 weeks, I personally find it important to start with two weeks sprints, when you are new to Scrum and have yet to find out what is optimal for the team. The general tendency of teams coming from a less agile approach, however, is to start with four week sprints instead, which makes it harder for them to successfully adopt Scrum.
Impact of sprint length
Understanding the impact of shorter or longer sprints is crucial for making the right decision about the ideal length for your project. I want to discuss the aspects I have found so far that need to be considered when choosing the length that is right for your project.
Pressure on the team to finish
The most obvious impact a team will usually consider is the pressure of delivering something of value to the product owner. The idea of delivering early and regularly might be scary for a team new to agile methodologies. It’s almost natural that four weeks seem to be the most feasible (but still inconvenient) option under this general impression.
While one week sprints can put even experienced teams under constant pressure, two week sprints already allow the team to put up with and release the tension.
That’s because in one week sprints you are already worried about the next deadline, when you just got out of the review of the previous sprint. You don’t even have a single weekend where you can relax and stop worrying about what you are going to deliver at the end of the next sprint.
Two weeks, however, give at least a week and a weekend, where the deadline is not in immediate proximity. For the second week there is again a build up of tension for the team, as the deadline approaches. This makes a good balance of recovery and pressure, which usually establishes a productive rhythm for the team.
Longer sprints of three or four weeks, on the other hand, disturb the balance of this rhythm. Only in the last third or quarter of a sprint will the team have the imminent deadline in mind again. Only disciplined and well focused teams will not lose sight of the sprint goal in the first two or three weeks.
Coordination with external parties
Another reason for longer sprints being brought up by teams quickly is the need to coordinate with external parties. These might be integration necessary for each sprint release, or dependencies between the team and external parties in either direction.
One week sprints again are hard to achieve when considering this aspect. They simply don’t allow for any contingency when either party fails to deliver in time to the other.
Two week sprints provide a good balance between flexibility to deal with glitches and keeping up the pressure on the other party to deliver.
Longer sprints bear the danger that problems are exposed too late to the other party. While a Scrum team has the daily stand-up as a tool to monitor progress and status within a sprint, external parties can track progress only based on what they deliver to each other.
Another reason that can be brought up against short sprint length is the high effort for integration at the end of each sprint. In this case, however, four week sprints will also cause troubles that need to be dealt with. A common approach to overcome such problems is to invest in sprint automation – you need to do this anyway, even with four week sprints.
Having enough time to finish a story
Worrying about having enough time to finish a story usually smells of something else going wrong in the project. The most common reasons I have come across for why a team complains about not being able to deliver business value within a sprint are:
- Inability to identify the individual user intentions contained within a story, which would allow the team to split up the story into smaller deliverables.
- Implementation tasks are distributed by layer instead of by user story, causing overhead and reducing focus on finishing a single story.
- Big Design Up Front approach leading to implementation of functionality not required for a particular story.
- Team members are not fully committed to the project, causing problems in communication and less efficiency because of multi-tasking between projects.
Reducing the sprint length helps teams identify and resolve these problems. Two week sprints are more than long enough for complex stories that are hard to split up further. Even one week sprints should allow enough time to deliver business value to the product owner in most cases.
Shorter sprints mean running more sprints to deliver the same scope. A typical assumption derived from this is that shorter sprints mean more planning overhead.
Besides the daily stand-up, which is a constant engagement independent of the sprint length, the following meetings are held for each sprint according to Scrum:
- Sprint planning
- Sprint review
- Sprint retrospective
I have found that the time required for the sprint planning in four week sprints is almost twice as much as in two week sprints. I don’t have comparable numbers for review and retrospective, but I assume that the amount of time required to demo is also nearly in linear relation to the length and scope of a sprint. The retrospective might be an additional overhead for each sprint. But on the other hand, learning about problems and possible improvements earlier can also be a benefit for the project.
While the overhead of the additional meetings might not be fully negligible in one week sprints, two week sprints do not introduce significantly higher planning efforts compared to longer sprints.
Amount of transient knowledge to be maintained
One goal of time boxing a sprint to 1-4 weeks is to limit the amount of transient detail knowledge the team is required to hold about a system.
Agile methodologies like Scrum acknowledge the fact that, at a certain level of detail, system requirements cannot be explicitly documented anymore. Other methodologies that try to ignore this fundamental law in software development impose huge inefficiencies on the development process: product owners try to specify details they have no clue about in advance, and developers desperately try to extract the business value and user intentions from loads of detailed specifications with no value, as they are not applicable anymore by the time they are needed.
However, the details required to implement a system still need to be agreed on between the product owner and the team. The sprint is the time box into which a feasible amount of detail knowledge should be fit. Each story is a reminder of a discussion that takes place before implementation, where the developer can ask the questions required to know what exactly to do. Of course the developer will take notes, either on the back of the story card, or in any other informal way that is suitable. In no case is a formal document created to capture the collected details. Instead, transient knowledge is built within the team and the product owner, starting with the sprint planning and further derived in discussions during the sprint.
The knowledge can be transient as it is not required beyond the scope of a sprint, and almost immediately transformed into (potentially automated) acceptance test scripts, unit tests and implementation.
The shorter the sprint length, the less transient knowledge has to be maintained. Shorter sprints also reduce the risk of defining outdated detail information, and a shorter period to look ahead makes it easier for the product owner to understand the impact of details defined for the system.
Having said this, one week sprints should be preferred when considering only this aspect. Two week sprints, however, still produce a well manageable amount of transient knowledge, and provide a good compromise with the other aspects considered so far.
Flexibility – opportunities to introduce change
While a Scrum project is agile, and allows the product owner to change scope and priorities between each sprint, it is quite strict about introducing changes during a sprint. This concerns organisational changes as well as functional scope changes.
Important organisational aspects to keep within a sprint are the length and the team. You shouldn’t finish a sprint later or earlier in order to accommodate a certain deadline, or deliver more scope than actually possible within the sprint. This would disturb the rhythm of the team, important for efficiency and for predicting what scope can be achieved. You also shouldn’t change the members of the team during a sprint. Important transient knowledge of leaving members may get lost before it can be transformed into implementation and new team members might miss knowledge that was built up in discussions during the sprint.
A team may choose to accept minor changes during a sprint, or commit to additional scope, when finishing early. But regular changes of the scope during the sprint will reduce the efficiency of the team, and the product owner should ideally make decisions based on the demonstrated current feature set of the product, which is not available before the end of the sprint.
Choosing a short sprint length allows the project to be delivered closer to externally set deadlines and provides more opportunities for change. Therefore this aspect would again be ideally fulfilled with one week sprints. But given the constraints introduced by the previously considered aspects of well balanced pressure and coordination with external parties, two week sprints allow for enough flexibility in most cases.
- As the bottom line, I advocate starting projects in general with two week sprints, because they
- Provide the best balance of pressure and recovery for the team.
- Allow enough time to coordinate with external parties while keeping up short feedback cycles that expose potential problems of integration.
- Better expose smells in the project related to organisational or engineering practices not well suited to agile development.
- Do not introduce higher planning efforts than longer sprints.
- Result in a well predictable and well manageable amount of transient detailed knowledge about the scope of the sprint.
- Provide enough flexibility to meet external deadlines and provide enough opportunities to introduce changes to the project (team, scope, priorities).