“We are almost done.  Let’s move the sprint review back a couple of days and wrap this up.”

“We should change our sprint length from two to three weeks so we can get more done.”

If you are a Scrum Master, how do you respond?

Those are two fundamentally different statements, but they have a lot in common.  Let’s look at how one might respond.

“Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.” – Scrum Guide (2013, p. 7)

“Sprints best have consistent durations throughout a development effort.” – Scrum Guide (2013, p. 7)

Textbook response.  Nailed it.  Tick!

If this is all you respond, I’ll give you a C.  Scrum Masters are expected to be masters of scrum (know the scrum guide cold). Appeals to authority (like this), while correct, are very unsatisfying.  If you want to motivate and educate, Start With Why?

Let’s look a little deeper at why scrum has these rules (fixed length sprints) and guidance (best to have consistent durations).

1. Your product Owner wants a release plan, therefore needs a velocity. I can already hear some of you arguing that velocity can be calculated for every sprint length.  Mathematically true, but it overlooks the increasing variability encoded in a longer sprint, which obviates any hope of predictability if sprint length changes.
2. Lengthening sprints is often a sign of weakness.  Teams may need coaching and practice to effectively split items to something small enough that also maintains end-to-end customer visible customer value.  Short, fixed length sprints expose this weakness, giving them an opportunity to correct it.
3. If you stretch the sprint to finish, where do you draw the line?  The same argument can be repeated ad nauseum.  Timebox is a psychological driver for closure.  It is used everywhere in scrum, on purpose.  We want to be able to inspect & adapt, and the points at which we do this are at the timebox boundaries.
4. If you lengthen the sprint, you may inadvertently increase the size of items taken into the sprint by e.g. 50%.  1/3 of a two week sprint is about three days, but 1/3 of a three week sprint is closer to a week.  This should be concerning because 1) there is a non-linear relationship between the complexity of a requirement and the probability of not being able to deliver in a sprint, and 2) the second most significant factor in the success of a software product is small sized requirements [1]  You are climbing out on a nonlinear curve, and it’s really not working in your favor.  You are making things worse, not better.
5. Humans respond well to predictable rhythms.  Sprints give them a predictable rhythm.
6. “if you want to get good at something, do it more often” – Jez Humble.  Basically a restatement of #2, without the guilt trip.
7. Inspect & Adapt is almost a mantra with scrum.  If you lengthen a sprint, you lengthen the feedback loop and reduce opportunities to improve.  Sometimes learning means tossing the work for an item at the end of a sprint.  Short sprints reduce the cost (time invested) before learning occurs.

Those are some of the ‘why?’ that come to mind to motivate why scrum is defined the way it is.  Use some combination of the above and see if that helps.

Extra credit: what other reasons have I overlooked from that list?

 

[1] COCOMO II