How long should our sprints be? This is a question I am frequently asked by new scrum masters and scrum teams. Here is how it showed up in my in-box recently.
After we participated in Agile Learning Labs’ Certified Scrum Master (CSM) workshop, my colleagues and I have begun practicing scrum very seriously. We chose one week as our sprint length. Some developers feel one-week sprints are too short, since we have a very strong definition of done. Delivering visible work in one week, along with all of the time in scrum meetings, is too stressful. One team member suggested increasing our sprint length to two-weeks. What are your thoughts?
Thanks for the question! The short answer is keep your sprints short; find and fix the sources of the stress you are feeling. All too frequently, when scrum uncovers a problem, we seek to change the way we are doing scrum in order to cover the problem back up. Have a look at this post about story point accounting for another example of this tendency. A better response is to address the underlying root-causes of the problem.
For your team, it is unlikely the underlying problem is not enough time in a one-week sprint to get user stories done. More likely, the team is dealing with one or more of the following problems:
Our User Stories Are Too Big
If your user stories are too big, then you won’t be able to complete them in a sprint. Luckily, this is a solvable problem. Have a look at SmallerStories.com for techniques that will let you split any user story into small user stories. Practice these techniques, and you will be able to have meaningful user stories just as small as you like. My suggestion is to make user stories at the top of your product backlog small enough for the development team to comfortably finish four to six each week.
Testing Takes Too Long And We Can’t Finish It All In The Sprint
First, make your stories smaller. When I said the team needs to be able to complete four to six stories each week, this includes the testing; dev-done isn’t done.
Next, work to have the development team swarm on completing the stories that are already in progress, instead of letting the coders start new stories. This makes testing, including that boring regression testing, everybody’s job. Yes, I know, developers don’t like testing. This is exactly why I want them responsible for the testing, especially the regression testing. You see, developers often think that the answer to most problems is to write code; in this case they are right! The best way to solve the regression testing problem is to automate those tests. With the regression tests automated, your professional testers are now free to focus more of their time creating acceptance criteria for upcoming stories, so that the whole scrum team will better understand and agree what will be needed to truly complete those stories. This will lead to fewer surprises and disagreements, and more stories done.
Our Meetings Are Inefficient And Take Too Long
This is a common problem, especially for new scrum teams. The fix is to learn how to have focused, efficient meetings. This takes practice. This takes facilitation, by the scrum master and others on the scrum team. When teams decide to make their sprints longer in the hope to have more time available for ‘the work,’ they usually make things worse instead of better. The problem is that longer sprints have more unknowns and thus are harder to plan. It takes more than twice as long to make a plan sufficient for two weeks than it does to make a plan sufficient for one week. Figure out what’s wrong with your meetings (e.g. You keep getting derailed into design discussions), and fix that.
Our Team Is New And Still In The Steep Part Of The Scrum Learning Curve
It’s true that when a team first starts using scrum, they will struggle. It’s new. They are learning how to do scrum, and that’s hard at first. At first, it actually slows us down, as we navigate the learning curve. My experience is that it typically takes three to six sprints before a new team starts to get over that learning curve. Notice that this is sprints, not time; it’s the number of times through the cycle that matters. With one-week sprints, a new team can get through the learning curve in three to six weeks. Choosing two-week sprints will double the amount of time needed to climb up that learning curve.
My advice is to stick with your one-week sprints and fix the problems that scrum is making visible to you.