If your team is using Scrum to organize their work and deliver done, working software, you'll be working in Sprints. A Sprint is the time you have to do your work. A Scrum Sprint goes like this: 1) at the start of the sprint you plan what you're going to do and how, 2) go actually do that work (this is the bulk of the Sprint), 3) at the end you show off what you've done and gather feedback, and 4) you wrap it up with a discussion of how that sprint went. And then you start over and do it all again.
But how long should these Sprints be? The Scrum Guide says that Sprints are "limited to one calendar month". Put another way, the maximum sprint length is 30 days. Alright. So we've established how long a Sprint can be. But is there a reason to make them shorter? And if yes, how much shorter?
Choosing your Sprint duration really comes down to just two things:
- What is your tolerance for risk?
- How long can you wait to change your mind?
Before I explain what those two items mean, I'd like to stress that you should choose a sprint duration and stick with it. If you decide that your sprints are 14 days long then they should be 14 days long until the end of time or until something has changed that says that sprint duration isn't working anymore. One of the most important reasons to keep your sprint lengths constant is that you can train your stakeholders and your organization that they get done, working software on a predictable cadence. Since Scrum is all about delivering done, working software at the end of each sprint, those stakeholders can get into a rhythm of knowing that new stuff (and/or bug fixes) will show up every X days. That reliable, predictable delivery cadence helps your team to maintain its credibility.
What is your tolerance for risk?
Risk management is a huge factor in deciding your sprint length. As an organization, ask yourself how long can you let the team work without really knowing how they’re doing? Once the team has finished their Sprint Planning Meeting and have come up with their Sprint Backlog they should be off and running. They know what they're trying to accomplish in this sprint and they're working on it. But how do you know if they really know what they're doing? I mean, are they clueless? Are they just sitting around surfing the internet and playing games on their computers? Are they hopeless and/or incompetent and just burning up the company's money? You might pop your head in to the team room from time to time to ask how it's going and they'll probably say something like "great!" or "61.295% of the way there!" but -- let's be honest -- you don't know and they're always wrong so you basically still have no idea.
The only time you actually know how that software project is going is when it's done. Now thinking back to the old timey days when we rode around on horses and managed software projects with the Waterfall Methodology, it might be 6 months to a year (or more) before the end of the project and you got some actual done, working software. While that code is being developed and tested, you have no clue how it's really going. Six months is a long time to not really know how your project is going. That's a lot of risk. In Scrum, we're working in Sprints and delivering done, working software at least every 30 days. Ok...well, so sometimes we don't deliver done, working software at the end of those 30 days -- even to the best teams choke once in a while -- but that's good to know, too! At the end of 30 days, you know for a fact that the team either delivered or didn't deliver that done, working software.
Put another way, that means that your maximum risk window in Scrum is 30 days.
Now what if 30 days is too long? Let's say that you don't trust your team because they're a bunch of jokers, yahoos, and ne'er-do-wells. Maybe you want to keep your team on a short leash. That's a good reason to have a shorter sprint length. Maybe 3 weeks, or 2 weeks, or even 1 week sprints would be better. Let's say that you pick 2 week sprints. If you get to the end of 2 weeks and the team doesn't have much (or anything) to show for it, that's a good opportunity to ask why. If they actually deliver done, working software then that means you know that (at a bare scraping minimum) you've got at least that bit of done, working software that you can use.
That done, working software at the end of the sprint is the ultimate proof that your team knows what it's doing.
How long can you wait to change your mind?
Another great thing about Scrum is that the Product Owner gets to change his/her mind fairly often. Thinking back to that by-gone era when dinosaurs roamed the Earth and we managed software projects with the Waterfall Methodology, you decided everything that you wanted to do in a project before you started. You probably even decided what order that you'd do those pieces of everything and then set the team loose for the next 6 to 12 months to go build (and presumably deliver) all that stuff. But what if you learned something new and changed your mind about the list of features or how a feature was supposed to work? You were probably screwed. Well, unless you rrrrreaaaaaaaaallllly wanted that change then you filled out a change request document, sent it up the chain of command, got legal's approval, then they drafted a change to the master contract, and then the team reviewed it, and then hopefully that change made it into the product. (Hashtag: ouch.) And since it's painful, you wanted to change your mind as little as possible so whatever you chose was what you were getting...even if you figured out a better way.
Back to Scrum. In Scrum, you've got the prioritized Product Backlog that describes everything that the Product Owner might ever dream of doing. The stuff that's towards the top of the Product Backlog is considered high-priority and will be done first by the team. The stuff that's towards the bottom of the Product Backlog is lower priority and might never get done. When you plan your Sprint, the team is usually picking the top items on the backlog and those are what will be forecast to be delivered in that sprint. Once the team has decided what is going to be done and started working, there's no more changing your mind. You're locked in...but just for that sprint.
All the stuff that's on the Product Backlog can change while the team if is off working on the current sprint. Put another way, the Product Owner can change his/her mind as much as they want for anything that's in the future. What's top priority today could be irrelevant tomorrow. Maybe market conditions change. Or new feature requests come in from Stakeholders or customers. Or you've got a gut instinct that says you're going to need more sparklepaws in your hoozeewhatzits. Whatever the reason, you can change your mind and you're only locked in for the remainder of the current sprint.
So, based on how your company operates and the environment that it operates in, how long can you wait to completely change your mind about what your team is working on?
Summary
Some of you might have noticed that I didn't say anything about how big your product backlog items (PBIs) or features are. Yah. That doesn't really matter because there are always creative ways to make a PBI smaller so that it fits in the sprint. In the end, choosing a sprint length comes down to just two things: your risk tolerance and how long you can wait in order to change priorities.
-- Can't quite get a handle on what your risk tolerance actually is? Confused about changing your mind regarding how to prioritize your product backlog items to get more sparklepaws in your hoozeewhatzits? We can help. Drop us a line at info@benday.com.
