Change the Sprint Length after an Abnormal Termination

I was talking to my friend, Vijay, a couple of days ago. His team had recently started using a particular code library that was going to make their development work much easier. They’d looked around at all the possible options and then licensed what they considered to be the best.

And then the company that had developed the library was suddenly acquired. Worse: the acquirer is known for buying companies, swallowing up their products, and then stopping sales of them.

Vijay and his developers were worried they’d just selected a product that would soon be orphaned by the vendor.

Fortunately, they had only been using the library for a few days so they weren’t very committed to it. And so, they decided to take the safe road and switch to what had been their second choice library.

This was on the third day of the sprint, but everything the team had planned for the sprint involved that library. With that specific library out of the picture, the team wanted to plan a new sprint.

Some of the work in the new sprint would be the same. But there was a lot to learn about the new library. And so the team wanted to commit to less and possibly do some of the easier things first with the new library.

They decided to abnormally terminate the sprint.

Following an abnormal termination, how long should the next sprint be?

I recommend that following an abnormal termination, the team run a sprint of an unusual length.

This is not for any fancy philosophical reason. Rather it is so the team can get back on its regular schedule.

For example, if a team abnormally terminates on the third day, as Vijay’s did, I suggest running a seven-day sprint. That will get the team back to having reviews, retrospectives and planning meetings on the team’s preferred day(s) of the week.

Most teams have a strong preference for starting and ending sprints on a certain day of the week. Adjusting the length of the sprint following an abnormal termination keeps the team’s sprints ending on the desired days.

Plus, it has the added advantage of keeping stakeholder’s expectations of meeting days consistent. If stakeholders have become accustomed to attending sprint reviews on every other Thursday, for example, it will be difficult for them if those meetings were to be held on Mondays from then on.

In choosing between a slightly longer or a slightly shorter sprint, consider stakeholder expectations.

If, for example, you have stakeholders who fly into your city for sprint reviews, consider adjusting the next sprint length so that meetings again fall on the actual dates stakeholders expect, rather than just the day of the week.

In Vijay’s example, this would push him toward a seven-day sprint instead of a 12 day.

By adjusting the length of a sprint following an abnormal termination, you can help your team succeed with agile.