Are there any conditions in which a Sprint’s timebox can legitimately be extended?  I think I might have found one.

In my Scrum-damentals webcast I’m pretty strict in advising that teams should not extend the timebox of a Sprint, even when things go pear-shaped.  Why not?

You and your team have certain goals as you’re getting ramped up with Scrum:

• Learn your true velocity based on real-world measurements
• Improve your estimating and forecasting capabilities through regular feedback
• Refine your story sizing and task breakdown skills
• Develop a comprehensive definition of done (e.g. don’t overlook needed work)
• Over time establish reliable metrics for future forecasting

Extending a Sprint in order to complete all of its deliverables undermines all of those goals.

Besides, there are better alternatives.

• With the Product Owner’s approval, you can reduce the scope of the Sprint at any time for any reason
• I personally like a Kanban WIP (work in process) limit to be in place from the start of the Sprint, because if you need to cut scope mid-sprint, it’s a lot nicer to have some completed stories (credit!) and some unstarted stories than all half-finished ones (no credit for any of them!)

This week one of my Scrummy friends presented me with an interesting challenge and got me to reconsider—or rather, refine.

You may have heard that we had a little weather up here in the Northwest.  Being the tech city that we are, nearly everyone (who doesn’t already do this full-time every day) retreated to work from the comfort of their living room and their fleecy pajama pants.  I won’t speculate on what this does to teams’ productivity, but we can safely say that widespread power outages that started on Thursday knocked out all but the most hardcore workaholics (running their laptop on battery, tethered to their 4G smartphone, recharging off the Prius in the driveway, you know the type).

My friend spent his week trying to salvage a Sprint which was scheduled to end on Friday.  He phoned in each day to his daily Scrum.  Standing up isn’t prescribed by Scrum, but lots of teams appreciate the value of a standup and he indeed stood up, pacing the kitchen during the requisite 15 minutes.  They lost time to and were blocked by the storm in various ways that I don’t know all the details of, and on Wednesday he lamented to me that, with all they’d have to cut from scope, they were facing a “failed Sprint” because you “can’t” extend it, not even to account for the weather.

I gave this a little thought and asked, “didn’t you determine your Sprint backlog based on your team’s capacity?”  Of course, he said.  “If a federal holiday fell in the middle of your Sprint and your entire team missed a day, would you count that against their capacity or would you plan around it?”  Don’t be silly, you wouldn’t count a federal holiday as a team Sprint day any more than you’d count a weekend, he said.  (Neither one of us is the tethering/Prius type.)

“So, if nature drops the equivalent of a federal holiday into the middle of your Sprint, why not move the Sprint around it?  If you move the Sprint end date by one day, aren’t you just keeping the Sprint the same length it was before?  The same duration your team had in mind when it accepted the scope?”

So, in my mind, this is a legitimate reason to change the end date of a Sprint.  I’m not sure it even counts as “extending”—the point is to keep the capacity constant.

I also told him that I don’t remember seeing “failed Sprint” in the Scrum Guide…

Finally, if you think a little snow is a bad reason to lose productivity during a Sprint, Seattle sportswriter Art Thiel and I invite you to shut the hell up.

Keep warm, Seattle!  And don’t run your Prius inside!