Advice for Extending the Sprint

The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.

28th
OCT

Advice for Extending the Sprint

Posted by admin under Agile and Scrum, Scrum Basics, Scrum Discussion

Your Scrum team is days away from the end of its sprint when it discovers a significant impediment—one that’s large enough to keep the team from delivering the product increment it’s negotiated for the sprint. So how should the team handle this late-breaking discovery? And what should the Product Owner do about it?

This is the question posed by InfoQ reporter Mark Levison in a recent post titled “When to Extend an Iteration/Sprint.” He aggregates advice from numerous Certified Scrum Trainers and, though there was some discrepancy among their responses, everyone seemed to be on the same page on this issue. Namely, all the CSTs surveyed explained that the team should inform the Product Owner as soon as the problem is discovered and that, under no circumstances, should the sprint be extended.

Perhaps the first point is an obvious one. When a problem arises, if the team informs the Product Owner immediately, it gives him or her more time to access the extent of the problem and formulate a plan of action with as much time remaining before the end of the sprint.

But why should a sprint never be extended?

In Scrum, development activity is organized in repeatable work cycles called sprints or iterations. It’s essential that sprints always be the same length because 1) it allows the development team to establish a rhythm and 2) lets the Product Owner observe the team’s velocity, which is extremely helpful with release forecasting. When a sprint’s length deviates, it undermines the repeatability of the process and erodes the urgency associated with sprint deadlines.

So what does the Product Owner do in such a situation?

First, the Product Owner should take stock of the situation. If work can be reorganized to salvage important sprint goals, it should be. But if the problem is too far-reaching for that to occur, then it should be treated like any other PBI in Scrum. That is, it should be returned to the backlog (where its acceptance criteria might need to be revised) and added to the next sprint. More thoughts on why awarding partial credit within a sprint is potentially harmful, take a look at this blog post by CST Michael James.

Be Sociable, Share!