Is it really such a bad idea to change your Sprint length?

“Is it really such a bad idea to change your Sprint length?”  I get this question all the time especially from teams and organizations that are new to Scrum.  The answer is a slam dunk: YES.  Yes, it is indeed a horrible idea to change your sprint length.

When I’m talking about changing your sprint length, I’m thinking of two different ways to do it.  The first model is to change the sprint duration rarely.  The second model is for teams that change their sprint length for each sprint.  Sprint 1: 8 days.  Sprint 2: 12 days.  Sprint 3: 5 days.  Sprint 4: 15 days.  Etc etc etc.  I’m not saying that you should never change your sprint length but if you do, you should have a very good reason and plan to stick with that new duration.  Changing the sprint length every sprint is particularly evil.

It feels like changing the duration should be trivial.  Well, it is trivial.  Just change the number of days in your sprint.  The *effects* are kind of awful because all of your metrics and estimations are messed up.

Let’s say that you have 6 sprints worth of velocity numbers for your 2 week sprints and you go to 3 weeks.  That means that you can’t compare “apples to apples” any longer because the velocity for a 2 week sprint isn’t going to be the same as for a 3 week sprint.  Sure, you could probably do some math to adjust those numbers but it probably won’t be all that accurate.  As a team gets into a groove of a certain sprint length, stuff starts to happen in a certain way.  A 2 week sprint for a team just isn’t going to *feel* the same as a 3 week sprint.  It’d be like driving a sports car for a year and then switching to a minivan.  Sure, they’ll both get you to the grocery store and they’ll both drive on the highway but it’s going to be a very different experience.  If you change your sprint length, your velocity numbers will be messed up and, since you use velocity to help plan and forecast, your planning and forecasting will therefore be messed up, too.

Your teams are going to likely have some amount of trouble estimating how much work is achievable because their instincts will be messed up.  If they’re used to 10 working days in a sprint and you change the sprint length, they probably aren’t going to be as comfortable with their forecasts.  If you change your sprint length for *every* sprint, then they’ll never even develop those instincts for what they can likely get done and this means that their estimating and forecasting skills will never ‘gel’ or improve.

Changing your sprint duration could cause you to need to re-decompose your Product Backlog Items (PBIs), too.  This probably wouldn’t be a problem if you’re going from 2 weeks to 3 weeks (increasing your sprint length) but if you’re going from 3 weeks to 2 weeks (decreasing your sprint length, you might have to go through and decompose your PBIs some more.  Why?  Because PBIs need to be completely do-able to your Definition of Done (DoD) inside of a single sprint.  If you’d structured your PBIs so that they’re achievable in 2 weeks or less in a 3 week sprint, that’s probably fine.  But if you’re doing 2 week sprints and your PBIs are structured to be 2 weeks of work, that’s pretty tight and you might have trouble actually delivering those PBIs to “done”.  For any of those PBIs you might have to go through and re-decompose them into chunks of work that are even smaller.  That’s not the end of the universe…but it could be a pretty solid amount of effort.

So, in short, don’t change your Sprint length unless you’ve got a really good reason.  And definitely don’t change your sprint length from sprint to sprint.

-Ben

— New to Scrum and need some help staying on track?  Want to do Scrum but you’re not sure how to start?  We can help.  Drop us a line at info@benday.com.