Chapter 6. Determining Sprint Length

There is no one-size-fits-all magic bullet for determining a sprint length that works well for every team. Originally, Scrum called for one-month sprints, but nowadays many teams have been successful with two-week or even one-week sprints.

With all these options, how do you choose the sprint length that works best for your team and project? Is there ever a time when it’s okay to have a sprint length that is longer than one month? Why would a team want to implement one-week sprints? And what are the factors that influence what the right sprint length should be, especially on a new project?

This chapter explores these questions and the concept of sprint length through a story. After that, it describes ways you can determine which sprint length makes the most sense for your team.

“Rachel, I’ve been going over these requirements documents for days and I’m stuck. We’ve got some difficult constraints to work with. Tegla needs us to build an order-tracking system. The problem is Tegla’s budget cycle ends at the end of the year, which means we have to get the system built quickly and correctly, because after the first of the year we won’t have a budget to fix it. From what I can tell, the stakeholders at Tegla are not yet very clear on their requirements. All they know is they don’t want the next version of what they have today; they want something completely new.”

“Wow,” said Rachel. “That’s vague.”

“What’s worse is that the requirements are a bit dated. There is a visual design document that someone put together for them, complete with UI elements, behaviors, and system interactions. We can use this as a starting point. We also have the legacy system as a reference, along with the use cases that were built to support it. The rest of it will need to be developed over time,” replied Jay.

“Hmmm,” said Rachel. “Let’s divide and conquer and see what we can figure out. If you can identify the essential people for the core of the team based on what you know, I’ll talk with the customer and come up with a recommendation for how to structure this project.”

After a few days, Rachel and Jay met again.

Jay described his efforts to build a core team. Rachel responded with her own conclusions and questions.

“I think using Scrum to manage this project would really help,” said Rachel. “How much experience does the core team have with Scrum?”

“Actually, the team members have been on a few Scrum projects together and are experienced with technical skills like test-driven development and continuous integration. They’re pretty strong,” Jay replied.

“Good,” said Rachel. “I spoke with the stakeholders at Tegla and gave them a high-level overview of our various project engagement styles, and they liked Scrum the best. I gave them a bunch of information on how Scrum works, and they were receptive. What I did not tell them is how long the sprints will be, so we need to figure that out. Here’s what we know so far.”

Rachel wrote a bulleted list on the whiteboard.

“Great summary, Rachel,” said Jay. “The biggest issues I see are the 31 December deadline and the loose requirements. We don’t know exactly what it is they want, and neither do they. With our team, their deadlines, and the fuzzy nature of the requirements, I’m thinking short feedback cycles will work best. I’m thinking weekly sprints.”

Rachel smiled. “Me too. The real variable is Tegla. I don’t think the stakeholders have the time needed for one-week sprints. They would have to be very committed and available to the project for one-week sprints to work, and I just don’t know if they’ll be willing or able to do that. Logistically, it would be possible. All the customers are located in the one local office. Still, they’re pretty busy with other duties. I can’t think of any project with Tegla where we’ve asked for that level of commitment,” said Rachel.

“Well, all of the other projects we have done with Tegla have been better defined,” countered Jay. “We didn’t need that level of commitment.” He paused for a moment, then continued. “Let’s set up a meeting. We’ll ask them a few questions and get an idea of how much time they have to commit to the project. Then, we’ll make our case for weekly sprints and see what they have to say. Never hurts to ask, right?”

The customer meeting came before Jay and Rachel knew it. They had a good turnout: All five customer representatives from Tegla were present. Jay decided to start by recapping why everyone was there and what the purpose of the meeting was. “Hi folks,” he said. “We are here today to talk about how we are going to work together to build the system in the timeframe you want.”

Jay continued. “We have a solution that we think will work for our team, but to make it work we need your commitment. Our approach will provide you frequent opportunities, we hope weekly, to review the system. We will work with you each week to determine what we build the following week. We will deliver code in a state that is potentially shippable so we can put it on your production systems and not have issues dealing with operations.”

The customers’ eyes got very wide upon hearing this. “Weekly releases and feedback? Sounds great. What’s the catch?” one of them asked.

“Well, in order to ship every Friday, we are going to need you to spend a lot of your time guiding us in the right direction. We’re talking 20 to 30 hours per week for one person, less for the rest of you. That time will be spent refining the product backlog, running through all the stories to ensure they work to your satisfaction, helping prioritize the upcoming sprints, reviewing and helping triage bugs—and writing bugs for that matter. Also, we’ll need you to—”

Jay stopped in midsentence as he saw the eyes of the customers gloss over in disbelief. One of them spoke: “We have jobs to do. How are we going to be able to do this?”

“Well,” said Jay. “It is a lot, I agree.”

Rachel nodded her agreement.

Jay continued, “However, doing this each week will give us about 22 opportunities—one per week for six months—to adjust the direction of the project. It’s the best way to make sure that what you have at the end of the year is what you want.”

“It might be the best way,” replied one of the customers, “but I know I can’t commit to the amount of time and feedback you will need. Is there a way we can stretch it out a bit? What if we did this once a month instead of every week?”

Rachel chimed in this time, “Jay and I discussed this option before the meeting. Monthly feedback cycles do work for many projects. The issue we both identified is around the requirements; they are very soft. Combine that with the fixed end-of-year deadline and we run a high risk of building the wrong thing, which none of us want. Monthly sprints only give us five opportunities for feedback, because by the sixth sprint, we’re delivering the system.”

“It’s all about stimulus-to-response time,” agreed Jay. “If you were to cut your finger, how quickly would you want your brain to respond to the cut? Immediately, right? Well, when we build a piece of functionality, it’s better for the overall health of the system if you respond to these changes almost as immediately. So, we want to build in several stimulus-to-response cycles. Doing that requires an investment on your part. However, making that investment means we have a higher likelihood of getting it right.”

Rachel nodded and said, “I know you’d rather have monthly sprints, but given the time duration of the project, I strongly feel we won’t get enough response that way. What if we compromise and have two-week sprints? That’s not as ideal (or intense) as the one-week sprints we proposed originally, but it still gives us an adequate stimulus-to-response time.”

The customer team knew the math. A six-month release window with two-week sprints meant they would have between ten and twelve opportunities to impact the direction of the project. They also knew that getting the system in place by the end of the year—and having it be the right system—was critical. Otherwise, the budget would be gone and they would be stuck with either half a system or a complete system that no one could use.

“We’ll find a way to make two weeks work. We’ll just have to juggle our schedules a bit for the next six months,” said their decision maker. “We’re going to need your help, though. We are new to this Scrum thing, so you will have to help guide us through. We are a little skeptical, but you make a good argument. Let’s go with a two-week sprint length and get this thing out the door.”

In a sprint, the initial stimulus is the customer setting the priority of the stories. The response is the team building working software. The building of the working software is in turn a stimulus to the customer. The customer’s response is feedback. The more instantaneous that feedback, the higher the likelihood that what is delivered in the end is what the customer really wanted, which is not necessarily what the customer originally asked for. This stimulus-response cycle continues until the project ends.

Rachel and Jay recommended one-week sprints. They arrived at this conclusion by taking into account the following criteria:

The expected duration of the project

Customers/stakeholders

– Availability for feedback and guidance

– Cultural barriers and Scrum familiarity

– Environmental factors

The Scrum team

– Scrum experience

– Technical capabilities (such as automated acceptance testing, test-driven development [TDD], automated releases, etc.)

– Ability to decompose work

These elements play a critical part when any team is trying to determine how long its sprints should be: from one week to one month. The next section looks at each element in more detail.

What about a year-long project? Assuming one-month or four-week sprints that break approximately monthly, that project would offer 11 opportunities (plus the final release) for stakeholders to see the developing product. One-month sprints are a realistic option, depending on the other factors involved.

The area between three months and one year is less clear. The project in this chapter’s story was a six-month project. If a six-month project is run on a one-month sprint model, the team has a scant five opportunities for feedback because the last sprint will end the project. Is that enough feedback to produce the right product? It depends. My advice for projects of greater than three months and less than one year would be to choose a sprint length that mirrors the project length—meaning a project that is short should have short (one- to two-week) sprints. A project that is long can have longer sprints, between two weeks to one month. Again, and I can’t stress this enough, sprint length should never be longer than one month. In fact, I recommend two weeks for nearly all of my projects, as I find it gives the ideal amount of stimulus to response.

If a project is expected to last more than one year, rethink the project. Multiyear projects are too big. Find a way to divide it into shorter releases. Just as you wouldn’t want a two-month sprint, you don’t want a two-year project—divide it into four, six-month projects instead. If you find you can’t come up with a way to break the project into smaller components, then you likely have larger cultural issues in your company that should be addressed before you try to use Scrum.

Figure 6-1 shows another way to view it. The lighter the sprint length bar is, the more likely you are to build the right thing because you will have more clarity. As you move to the right, to a darker shade, you have less clarity, less customer involvement, and you increase the risk of building the wrong thing.

1. Product owner and stakeholder availability

2. Company culture and familiarity with Scrum

3. Product environment

Look at the availability first. It’s crucial to balance the team’s needs with the needs of your stakeholders. Having a one-week sprint might solve some team problems but could put too much stress on the team’s relationship with its stakeholders. Discuss the situation, just as Rachel and Jay did. Explain why stakeholder feedback is so important to the project’s success and tell them what they will get out of the added expense of their time. Remember, in most cases, those who are new to Scrum are not accustomed to Scrum’s demand for interaction. They are used to dropping the requirements off at the beginning of the project and picking up their product at the end. Regardless of the sprint length you choose, you will want to spend time educating everyone about the value of frequent feedback and the necessity of stakeholder involvement in the development process.

Next, examine the company culture. Is working with a Scrum team new to the company and its culture? Is it perhaps being tested in a pilot group? If so, consider that short sprints may give a false impression that Scrum teams put undue pressure on stakeholders. Find ways to align the values of the company with those of the stakeholders and Scrum team. If the stakeholders and Scrum team value the idea of having working software every two weeks but the company values an all-encompassing project plan, the project will struggle regardless of sprint length. Again, education is key. Meanwhile, the more results the team produces, the more willing a reluctant company will be to accept the value of frequent iterations over a comprehensive plan.

The environment in which the final product will live can also affect the project. Environmental factors (such as regulatory issues) are often overlooked but, from my experience, affect what the team can deliver and when. If your team has a large number of regulatory issues to contend with, you will probably want to choose sprint lengths of at least two weeks (three may be ideal) because of the amount of compliance assessment and auditing that will need to occur before any software can truly be considered shippable.

Team experience with Scrum

Team engineering capabilities (TDD, continuous integration, pair programming, etc.)

Team ability to decompose work

In this chapter’s story, the team members had some experience with Scrum and XP. They knew each other well, would not have to start from scratch, and felt comfortable working within the Scrum framework. None of them had the “I own this part of the code” mindset. Jay and Rachel knew this, so they felt confident with one-week sprints. As a rule, an inexperienced Scrum team should stick with two-week to one-month sprints because a one-week sprint is much more advanced and better suited for established teams that have a good working relationship.

If you do choose a one-week sprint length, you need to have the engineering capabilities in place (or learn them awfully quickly) to execute work in that compressed time frame. Good engineering practices are just as important with longer sprint lengths, but their absence is not as painful or glaringly obvious on a one-month sprint as it is on a one-week sprint. To efficiently execute a one-week sprint, the team must be able to establish and maintain a continuous integration server and should follow engineering practices such as TDD and pair programming. Utilizing an automated acceptance testing framework is also a requirement, as the testing debt growth will be fast and furious. If learning these mechanisms in a hurry is your goal, then a one-week sprint might make sense. Otherwise, don’t even think about a one-week sprint until you have these capabilities in place.

The ability of the team to decompose its tasks is critical on short sprints and still important on longer sprints. Decomposing tasks, in and of itself, is an art form, one that requires critical thinking, a clear mind, and the ability to see beyond the surface of a problem. If your team is good at decomposing tasks (or wants to get good in a hurry), shorter sprints (one to two weeks) can work. If your team is still learning how to decompose tasks, you might want to start with longer sprints. Read more about task decomposition and ways to improve in Chapter 12, “Decomposing Stories and Tasks.”

I find myself asking a series of base questions each time I set up a project, just as Jay and Rachel did in the story. These questions help determine sprint length but are not conclusive and should be considered guidelines rather than hard and fast rules. What I’ve ended up with is a quiz similar to one you’d see in a magazine, where you answer a series of multiple choice questions, give a certain value to each answer, and then tabulate those answers to arrive at your ideal sprint length. As with any tool, use it wisely—if the answer it gives you does not feel right, then choose a different sprint length.

First, answer the multiple choice quiz shown in Table 6-1. Choose the answer that most closely matches your situation.

Once you’ve answered the multiple-choice questions in Table 6-1, use the scoring key in Table 6-2 to assign a number for each question based on your answer. You’ll notice that there are three numbers in the key: 1, 3, and 5, where 1 = Bad Choice; 3 = Workable; 5 = Ideal. You’ll carry all four numbers that match your answer into the sprint length model.

As an example, recall that in the story Jay and Rachel had a timeline of six months. I’ll use this as the data point to answer the first question: What is my project duration? Their answer would be C. 6–8 months. If you had a project duration that matched Jay and Rachel’s, you too would go to the 6–8 months row in the scoring key and copy the numbers into the sprint length model, as shown in Table 6-3.

You would then answer the next question, taking the numerical values from Table 6-2 and populating the sprint length model. You should proceed until you have answered all questions.

For example, assume that your answers for questions 2 through 5 (about the customer) were all B, and your answers to questions 6 through 8 (about the team) were B, A, and A. Your completed model would look like the one shown in Table 6-4.

In the last row, you will see some numbers (3, 4.75, 4, and 3). These are calculated averages (I added the numbers in each column and divided by eight, the number of questions). Based on the average rating, your hypothetical project should work best with a two-week sprint, with three weeks being a close contender and one-week and one-month sprints coming in last.

When teams do not have experience running sprints, they tend to experiment with various sprint lengths, which can be confusing for the customer and debilitating to the team. One company I worked with wanted to experiment with all the sprint lengths to see which one fit them best, even though two weeks was the obvious choice based on the sprint length model and just simple gut feel. They started out with three-week sprints, then two-week sprints, then a one-week sprint, then a one-month sprint, then back to a two-week sprint, and finally a three-week sprint. They ended up settling on two-week sprints, but by the time the team finally landed on an optimal sprint length, the team members felt like they had just walked away from a car crash with no seatbelts.

If your team is new to Scrum, you should start with one of the two accepted standards (two weeks or one month) and do that consistently for several sprints. If you find that you are having difficulty at that point, it is much more likely that Scrum has uncovered a problem your team is having than that there is something wrong with your sprint length or with Scrum.

When determining sprint length, it is essential to remember the following things:

Stability of requirements

Project duration

Amount of risk you are willing to take on

The ability of the team

The tolerance of the stakeholders

For each of these points, remember that the stimulus-to-response time should be the main driver in your decision. The more feedback you have, the better you will be able to tolerate risk. Shorter sprints enable you to identify potential risks sooner but come with a cost of increased customer interaction and more interruptions for the team. Longer sprints mean that it will take longer to find the risks but have the benefit of fewer interaction points and interruptions. Balancing feedback with interaction and interruptions is a challenge that your team and stakeholders will perfect over time.

The questions and corresponding scoring key I provided in this chapter may not work for everyone. When you’re adjusting sprint length, consider it a starting point. Don’t stress about following the model’s exact questions and answer weightings. Focus instead on whether you are considering both your customer and your team when determining your sprint length. Finally, don’t forget the reasons you are working in short iterations: to gather stakeholder feedback, to show project progress through working software, and to frequently deliver a project that is potentially shippable. The right sprint length balances the team’s craving for feedback and input with the team’s ability to deliver and the stakeholder’s ability to respond.

This advice is important because the whole purpose behind the one-month-or-less sprint length is the feedback loop—validating that the path the team is on is the correct one. Another way to put it is that in the beginning of the sprint, the team heard what the product owner (and the stakeholders) asked for. At the end of the sprint, the team presents what it thinks it heard—essentially trying to prevent what I call the “what I meant syndrome,” when customers and stakeholders say after a sprint or release, “You built what I asked for but not what I meant.” This situation plagues so many teams, why would they not want shorter feedback loops?