When a team that is accustomed to working on 6, 12, or 18-month long projects adopts agile practices, the prospect of planning its work every week or two is daunting. Planning the work every month might be tolerable so the team goes with four week long sprint lengths. As the team becomes more and more agile, the four week long sprints start to feel drawn out and constraining. This prompts the question, does sprint length really matter?

Smells that indicate a need for shorter sprint lengths

1. Multiple teams on same program needing to re-sync/adjust frequently because of dependencies:

In a large program consisting of several feature teams, the work produced by one feature team often becomes an input into work done by another feature team.  For example, consider Team A and Team B. Their sprints are synchronized to begin and end at the same time to help with release planning and tracking. In any given sprint, Team A may produce something in the first part of their sprint that is needed by Team B in order to produce something else in the latter part of their month-long sprint. In theory this works, but in reality as soon as something delays Team A from delivering, Team B’s sprint commitment is jeopardized. After this happens once or twice, members of Team B will no longer be willing to commit to work with cross-team dependencies. One or two-week sprints eliminate many of those disconnects.  Team B simply does not pull an item into one of their sprints until Team A is done building the pre-requisite feature set. Because the sprint length is short, there is minimal delay between Team A finishing their feature and Team B starting their work.

Note: this does not presume that component teams (that only develop one layer of the app then hand it off to another team to develop another layer) are to blame here.  These interdependencies also occur with feature teams.

2. Team sagging in middle of the sprint and then having a burst of energy towards end of sprint.

Teams using four week sprint lengths, in spite of the professionalism and motivation of team members, can be susceptible to waiting until a deadline looms to become focused on what is needed to close out stories. The effort and energy level may not really crank up until the latter part of the sprint. Have you ever worked with a Scrum team whose energy level looks something like the graph below over the course of a sprint?

This is a sign that the longer sprint length is causing the team to lose focus and/or momentum until the point when they need to “put the pedal to the metal” in order to meet the sprint objectives before the close of the sprint.

3. Team taking on a small number of large stories.

New Scrum teams often have difficulty slicing features into multiple, smaller stories. Sometimes this is because the users are afraid that if they don’t cram all of their requirements into this one story right now then they will never have another opportunity to build the rest of the functionality. Without going into a dissertation about queuing theory (check out Little’s Law if you want more info about this), large stories have a profound (negative) impact on team throughput. One of the most tangible effects of large stories is that there may be little or nothing for the users to test until near the end of the sprint, which then results in a mad scramble to finish the stories. Not exactly a model for a sustainable pace and high quality.  Shorter sprints force teams to break large stories down into smaller pieces. Once they get the hang of it, they will size the stories so that they can deliver a steady stream of functionality to QA, the Product Owner, and users for testing throughout a sprint.

4. Team is finding that the large number of small stories is getting hard to manage and wants to combine them into just a few large stories in each four week sprint.

For teams that become adept at breaking stories down into smaller stories, a new challenge can be that there are so many stories in a four week sprint that it becomes almost unmanageable. This is a clear signal that it is time to move to shorter sprints involving a lower number of but still small stories.

5. Team is tinkering with what stories are in the sprint backlog due to learnings that occur early in the sprint.

What if, early in the sprint, the team learns something while working on a story that results in a new story being created that encompasses those learnings? While it is commendable that the scope of the current story was not just expanded, what is not so commendable is that often teams, especially ones working on four week sprints, become tempted to swap out another story lower in the sprint backlog for this new story because otherwise the team will not be able to address the new story for another month. Of course a constantly shifting sprint commitment is hazardous to a team’s health. A team working on two week long sprints would not need to be concerned about long delays before it can address the new story.

Nowhere to hide

Just as the initial agile adoption effort brought many organizational dysfunctions to light, shorter sprint lengths will unearth still more issues. Sporadic involvement of the product owner or users cannot be concealed in a two-week sprint. Excessive work in process, with a team that is hesitant to swarm on a small number of stories at one time, creates bottlenecks for testers, product owners and users who must focus on large number of conversations at once rather than focusing on a few at a time. Shorter sprint lengths will expose these and other shortcomings and allow a team to quickly learn and adjust its practices. Also, if the Scrum Master is wise enough know when he/she needs to let the team members fail in a sprint in order for them to learn a tough lesson on their own, the impact is muted due to the shorter sprint length.

Roadblocks

If the case for one or two week sprints is so obvious, why is it hard for some teams to adopt them? A common roadblock is stakeholder concern that more sprints will result in more “unproductive” time planning sprints, doing retrospectives, and conducting sprint reviews. The reality is that sprint planning time should correlate very closely to the number of stories in the sprint, therefore a shorter sprint = less time needed for planning. Retrospective and sprint review meetings can also be shortened accordingly.

Reflections

• One or two week long sprints allow teams to better synchronize their efforts.
• Small stories are that much more important with shorter sprint lengths.
• Shorter sprints require more consistent involvement from everyone on the team, including testers and product owners.