The Many Tradeoffs of Sprint Length

By Ryan Panos, Agile Researcher

Of all the seemingly critical questions facing a team that is about to take the reputedly arduous plunge into implementing Scrum, the one that should be approached with some care is: “How long should your sprints be?”

The original literature from 10-20 years ago often cites four weeks or one month. More recent literature will often mention 2 weeks, with some enthusiast insisting on 1 week. So how do you decide what is right for your team and your project?

The fact is, there are many reasons to strive for a short sprint and there are many obstacles to the intimidating scenario of 1 week. As the trend is heading toward shorter sprints, let’s examine the advantages of this objective first.

The Benefits of a Short Sprint

One of the primary objectives of adopting agile methodologies is to be more responsive to the changing needs of the customer. Therefore, a team that reconvenes with their stakeholders at least twice a month has the ability to be twice as responsive as a team who meets with these primary customers once a month (http://www.agilehelpline.com/2011/03/sprint-length.html). In fact, if a change in the road map is just as likely to reveal itself today as it is on any other day, a team can be said to be able to deliver a significant request in 1.5 sprint lengths. In mathematical terms, if the arrival times of requirements changes are uniformly distributed, as they might be added to the backlog at any time with an equal likelihood, then their expected arrival time averages to mid-way through any sprint. In other words, over time half of the requirements changes will arrive in the first half of the sprint and half will arrive in the second half so the “average” arrival time will be midway in the sprint. Since it is a generally agreed upon rule not to add a requirement during a sprint, the least additional waiting period would be during the sprint in which the request is tackled. So a team that can achieve a one week sprint will be able to deliver with an average lead time of one and a half weeks.

In addition to the ability to react to a change in requests, a more frequent delivery also gives all the stakeholders a higher degree of visibility. This not only calms high profile nerves but also mitigates risk because clarifications can be made. The team, like every single team since the beginning of the industry, is always running the risk of building a feature that is not actually needed simply by misinterpreting the author of the requirements. Since a major tenet of Agile is to not invest significant effort into writing documents, this makes the possibility of wasted effort is even more likely. However, with more frequent deliveries via shorter sprints, this threat to productivity is well managed.

However, building a more productive relationship with the stakeholders is not the only reason to consider a short sprint. Another popular argument is simply that the team will learn more about their need to improve their methods and will strive to do so sooner. This is because the Scrum process should, among other objectives, expose a team’s most ineffective processes so that they might be refined to reduce inefficiencies (http://blog.agilebuddy.com/2010/01/whats-the-ideal-sprint-length.html).

In fact, many advocates for Scrum tell us that building a team that lives by the agile principles should ultimately be the goal. However, true Agility is not something that can be achieved overnight. In actuality, Scrum is the most popular structured approach used when attempting to obtain agility. So the sooner a team can survive a few iterations of Scrum, the sooner their processes have the opportunity to become more refined and the goal of agility might be legitimately achieved.

More specifically, the period in the sprint where the team has the greatest potential to refine their processes is during the Sprint Retrospective where the group discusses the successful and unsuccessful aspects of the past sprint (e.g., Dr Linda Rising, http://osr.cs.fau.de/2010/06/17/linda-rising-on-retrospectives-in-amos-praktikum/). So if the Retrospective is performed as often as every week, there are more opportunities to review the team’s methods.

Another way a shorter sprint can have a major impact on the team is in terms of focus. CPrime’s Dr Thompson puts it best, “The longer the Sprint, the easier it is to lose track of where we are relative to where we should be. Also, Team member’s sense of urgency tends to go down as Sprint length goes up, which removes motivation to perform when we get to long Sprints.”

In stark contrast, at a company that is not using Scrum at all but simply living by long delivery schedules, the inevitable cycle begins with a period where no one is really concerned with when anything needs to be completed followed by a period of incredibly intense stress at the end of a release. The unspoken belief is that this period of panic is generally believed to be inevitable because timelines will always slip. In fact, the team probably had to beg for an extra month of working nights and weekends in order to deliver anything close to the original request. To make up for this period of terror, management will often, officially or not, tolerate the aforementioned period of low paced work so that everyone can recover and employee turnover does not reach crisis levels. This cycle then repeats.

But to be clear, experts such Mick Cohn, co-author of the original Agile Manifesto (http://www.informit.com/articles/article.aspx?p=466660&seqNum=5), point out that Scrum should not be used to create constant intense pressure on a team but instead it should be used to maintain a productive level of motivation. Some even say that without adequate time constraints, an engineer will take as long as he or she is allowed to deliver a feature. This author finds this cliché to be a dangerously simplified and cynical notion. However, every software engineer needs to feel his or her progress is going to be recognized. So if the primary visible measure of this progress is delivery to the product owner at the end of the sprint, then a more frequent delivery will allow for more recognition and therefore greater focus.

So we have established that there are a variety of reasons for why a team should consider a very short sprint length. In fact, advocates of continuous deployment speak as if sprints should be measured in seconds. Fortunately those with any authentic Scrum experience know that a week is the shortest practical length due to the overhead of the widely adhered to team gatherings of the Planning Meeting, Daily Scrum, Sprint Retrospective and Sprint Review. Speaking in extremes, we would not want to invest 4 hours of planning for 30 minutes of development. Yet with all the advantages listed above, why are so many teams still failing to achieve or even attempting the 1 week sprint? The list is long.

The Barriers to a short sprint

In an ideal world, all stakeholders live and breathe in a series of cubicles a few feet from the development team and all have an undistracted dedication to this project. In this hypothetical scenario, the product owner then has continual access to these fussy and indecisive customers. But outside of this fantasy world, there will always be some impediments to proper collaboration with stakeholders. They will either belong to a very different part of the company, be distracted by many other responsibilities, reside in a different time zone, or even work for a different company altogether. In the Scrum world, the Product Owner serves as their proxy and will do his or her best to build the most efficient relationship to foster the smoothest communication. He or she will work odd hours, travel around the globe, negotiate elaborate scheduling compromises via all forms of communication, and effectively do everything possible to compensate for these less than ideal environmental factors. But even with the hardest working Product Owner, there will still be many environments where there just isn’t enough consistency in stakeholder availability, let alone the ability to assemble the team and the stakeholders to conduct Sprint Reviews, to make a one week sprint practical. So in many cases, a longer sprint should be considered just to accommodate for any inconsistencies in the availability of the stakeholders.

Just as with nearly every article on Scrum this article has been treating the team in question as if they lived in an isolated world with only their cost conscious stakeholders and their future revenue to consider. In the real world, however, there might be many other software teams to collaborate with and the nature of the collaboration is difficult to plan for. In other words, your stakeholders might be developers on other teams that you are quite dependent on and they might not be able to provide the details of their needs with a frequency that allows for short sprints. (See http://www.cognizant.com/insights/perspectives/agile-scrum-sprint-length-whats-right-for-you).

Ashwini Khanna (PMP), a project management consultant for large organizations such as Pfizer, points out that in a very large enterprise system, one team cannot possibly control or easily be aware of the impact of every change they make without detailed “Impact analysis” across multiple areas and boundaries. Therefore, longer sprints maybe required simply to capture regression and other not easily visible errors. So whilst a team’s responsiveness is a function of their sprint length, it is sometimes hindered by the need to plan for the responsiveness of dependent teams. For example, in an environment such as with extensive data validation needs, a short sprint would add excessive risk. Additionally, relating to data, Ashwini points out, “In the Management of Master Data, one change could have an impact on an entire organization, so much of the sprint must be devoted to assessing the impact of each change. This is usually not possible in a one week sprint and in my experience in large organizations, sprints of three to four weeks are therefore more common.”

There could be other factors that restrict how small a story might be able to become and that alone might prevent a 1 week sprint. In fact, many say the largest story should occupy no more than 35% of your total capacity (http://www.scrum-breakfast.com/2011/03/what-is-optimal-story-size.html) and many have a shorter limit. So shorter Sprints require smaller Stories, but some fields involve work that is harder to decompose into small pieces. For instance, data warehouse work tends to operate naturally in larger chunks than software development, so 3-4 week Sprints may make a lot more sense for that kind of field. Meanwhile, trying to decompose data warehousing work into pieces that take 2-3 days can result in deliverables whose definition seems patently ridiculous to the Team members.

Another factor that must be considered is simply the level of experience within the team. This might refer to the collective professional maturity as a whole but it primarily refers to a measure of agility. If a team is accustomed to a more traditional workflow then jumping to a 1 week sprint might be very stressful and face some opposition. Meanwhile slowly increasing the frequency of the various formalized meetings is an approach that some in the industry agree can ease a team into a proper sprint length. Although not all agree with this as others say that you should never change the length of your sprint under any circumstance as establishing and maintaining a rhythm is the entire goal. However, what is generally agreed upon is that you should never increase the length of your sprint after setting an ambitious goal. If a team starts with a two week sprint and then decides to move to a four week sprint, it is said there will be tremendous resistance to any future push to shorten the sprint again later. This is likely because the collective confidence of the team has taken a significant hit with this step back and all will be inclined to associate the shorter sprint length with a lot of stress. Of course, the capabilities of the team are not just a function of their level of experience but also the tools and methods used. Automated testing, continuous deployment, test driven development, and other practices are all considered choices that would make a shorter sprint more manageable.

The remaining common words of caution against a 1 week spring are not agreed upon within industry, and that is the overhead of meetings. Officially, the length of meetings such as Sprint Planning, Sprint Retrospective and Sprint review should all be proportional to the period of time they cover. So according to many, these meetings should be twice as long for a two week sprint versus a one week sprint. However, the disagreement comes from the fixed time costs that are not proportional to the amount of work the team is agreeing to tackle such as the productivity lost due to the interruption. As cPrime’s Dr Thompson points out, “Context switching has a minimum cost that doesn’t scale down with decreasing Sprint length.”

The other retort to this proportional argument comes from the unofficial “mid sprint alignment meeting” that, although nowhere near an official part of Scrum, sometimes occurs spontaneously during a more stressful long sprint. To discourage this scenario, some say that a short sprint has the advantage of keeping a team member’s list of tasks short enough so that he or she might even be able to remember all the major items and be capable of discussing them verbally at almost a moment’s notice. In contrast, a long sprint will create a list that is not easily recalled at any time, thus it might take a bit more effort to coordinate with the rest of the team. To remedy this situation, some teams use a mid-sprint meeting to re-align every one’s efforts. This tactic, although not always necessary, is certainly an added cost.

Lastly, some claim that the length of the sprint is not terribly important but the number of sprints per release is absolutely important. This might be an especially important consideration for those in a market or an environment that does not allow for frequent delivery to the customer. So Scrum might be used to enforce periodic deliveries of “working code” to the stakeholders but in terms of actually deploying to the customer, releases might only occur a few times a year. Hamid Shojaee, CEO of Axosoft—a firm that develops the software project management application OnTime—says you should plan for at least four sprints per release. He says the team should, “Tackle the toughest stories in the earliest sprints. Then take on bug fixes and stabilization in the latest sprints to reduce project risk. Of course, four is the minimum number of sprints but you might go to 7 or 8 or even 10. ” Hamid also says the team could go with less than four sprints per release, especially if the team prefers to use continuous integration, but then you can’t take as many risks with each release.

Conclusion

So there are many reasons to strive for a short sprint and many reasons why this is going to be difficult. Dr. Kevin Thompson, Agile Practice Lead for cPrime, summarizes it best by saying that the choice of sprint length is “A compromise between competing tendencies. Shorter Sprints keep people focused on deadlines and encourage timeliness, at the cost of relatively higher overhead and less productive working time compared to longer Sprints. Longer Sprints better address work that is innately harder to decompose into small pieces (such as data-warehouse development), and suffer from relatively less overhead compared to shorter Sprints, but may reduce the sense of urgency to one of complacency and thus slow the pace of progress.

Dr. Thompson has also said, “Contrary to popular opinion, the overhead of the Scrum process does not scale directly with Sprint length, because the impact of context switching between meetings and development time is constant. This is why shorter Sprints have relatively higher overhead than longer Sprints.”

So when choosing a sprint length, a team should consider the conditions of the working environment, especially in terms of how the team collaborates with the stakeholders but also the nature of the technology involved, along with the team’s capabilities. This should then be weighed against the advantages of a short sprint. Therefore, the key is to find what is appropriately ambitious and yet pragmatic for your team.