(I originally posted this on my MSDN blog.)
I wrote about my preference for short Scrum sprints last month, where “short” means no more than two weeks. Recently there was another internal email thread on roughly the same subject where some people listed some concerns they had about moving their team to two-week sprints. I’ve combined, paraphrased, and edited some of the questions and included my answers for them below.
The environment isn’t nailed down and requirements are still up in the air. I need four weeks in order to maintain control.
When you have a lot of uncertainty in your project and your requirements are up in the air, that’s precisely the time when you want to have short sprints so that you have frequent adjustment points.
The whole idea of a sprint is that you build a crisp short-term plan based on facts that you know and can rely on. If there’s a lot of uncertainty in your environment, which is easier: to build one plan that will still be accurate and useful four weeks later or to build a two-week plan, execute it, and then build another two-week plan using additional facts that you’ve learned during the first sprint? Long sprints are for stable environments where the need for flexibility and responsiveness is low. Short sprints are for changing environments where you don’t know a lot right now but in two weeks you’ll know more.
Planning for four-week sprints is painful as it is; I don’t want to do that twice as often!
With shorter sprints, your planning for each sprint should get shorter as well. In fact, I’ve found that when going from four week to two week sprints your planning can be reduced by more than half because you simply don’t need all of the process that you need in a four week sprint.
For example, in a four week sprint it’s important to carefully estimate the number of required hours for each task, then track the number of hours you spend on each task, and generate a burn-down chart so that you can tell if you’re tracking to the plan. Most teams have some point at about halfway through the sprint where they evaluate the burn-down chart and make adjustments to the sprint commitments depending on how they’re doing, because four-week plans rarely survive unchanged.
Well, instead of doing that, how about if you skip the burn-down chart and just build a new plan at the two-week point? You can save all the effort of detailed tracking and you get a more up-to-date plan as well. Remember, building a two-week plan isn’t nearly as expensive as building a four-week plan so you’re doing about the same amount of planning (or probably less) overall.
How far off track can you get in two weeks, anyway? Certainly not as far as in four weeks, so there’s not as much need for oversight. And if you do start to get wildly off-track, just glancing at a sprint task board or a list of completed stories will probably tell you that you’ve got problems because the total number of items is small enough that you can understand them at a glance and eyeball it pretty reliably.
Meeting proliferation – yuck!
The same goes for meetings. There may be more meetings but each one is much shorter because there’s less to cover. If it’s hard to get all stakeholders together for a demo every two weeks, you might schedule a big public demo every four weeks (after two two-week sprints). Short meeting tend to be more productive because they’re crisp and people don’t get burned out. Four-hour planning meetings (or 6 hours, or 12!) are way too painful to be productive.
I have multiple teams in different geographic locations that need to stay in sync. Won’t short sprints hinder that?
Syncing multiple teams ought to be easier with short sprints because no team is ever more than two weeks away from being able to make major adjustments to their plan in response to the needs of another team. I’m not sure how long sprints would help the syncing issue. Long sprints give you the illusion that you know exactly where you’re going to be four weeks from now, but you probably don’t. You can make a pretty decent predictions for several weeks or even several months into the future using product burndown velocity, and that reminds everyone of what they really are – predictions. Not guarantees. Now, predictions are useful. I’m not saying that you don’t think about the future at all. I’m just saying that you need to be realistic about your level of certainty.
I’m not sure my team is ready to transition to two-week sprints. As scrum master, should I just mandate it?
I would not try to impose two-week sprints over the objections of the team. One of the fundamental principles of Scrum is that the team should be self-organizing as much as possible. If there’s general agreement that short sprints wouldn’t work for some reason, then imposing them probably won’t be successful. That doesn’t mean you can’t keep evangelizing the idea and hope to eventually change people’s minds, though.
If your organization is still feeling shaky about Scrum in general and people are still climbing the learning curve, then you should probably just stick with whatever sprint system you’re using at the moment unless it’s obviously broken. People can only absorb a certain amount of change at once. It might be wise to let your recent changes soak in a bit before you muck around with the system.
Anything else I should know about short sprints?
The one thing that short sprints really do demand is that you have to be able to write very good user stories that are small, well-defined, but still vertical slices that deliver real business value. That’s not an easy skill to develop, but I think it’s totally worthwhile because it pushes you to really understand the features at the top of your product backlog. Big, vaguely-defined user stories are hard to get done in two weeks, so they make you feel like maybe you need three or four week sprints, but I think the right answer is to not work with big, vaguely-defined user stories. There’s almost always a way to break them up in a way that makes sense if you take the time to thoroughly understand them, and only good things can come of thoroughly understanding your top-ranked stories.
Ok, there’s probably one other thing that short sprints demand. They demand that your entire team be familiar with, comfortable with, and committed to agile principles. If your team really wants to work in a high-planning, waterfall system and they’re just doing this Scrum thing because someone higher up told them they had to, then long sprints at least gives them some of the long-term planning that they desire. Short sprints will just make them even more uncomfortable than they already are. That says nothing about the viability of short sprints – it’s about people’s comfort zones.
To sum up, the whole premise of Scrum is that you make crisp firm plans based on facts that you definitely know, and you avoid making firm plans based on anything you don’t know or only pretend to know. Planning beyond the knowledge horizon doesn’t really change what you know, it just tricks you into thinking you know more than you do. The key is to execute hard on the facts in front of you and stay loose on everything else. And remember, people are the ultimate limiting factor so don’t drive them faster than they’re willing to go.
Everything I’ve said about two-week sprints applies to one-week sprints, only more so. The ultimate conclusion to this line of thinking is Lean/Kanban development where you don’t have time-boxed sprints at all; you just have single-piece workflow and a pull model. I haven’t really gone there yet because I’m still consolidating my grasp of Scrum principles but a lot of the industry thought-leaders are already there.
SaintGimp 