I recently had the question of should/can we extend a Sprint. I am pretty Anti on extending Sprints. This is a GASP that I treat as a pretty standard rule. I will search high and low for an alternative to extending a Sprint. I did not put much personal input into this post, I did add what I sent out in relation to the practice.

Some articles on Sprint Extension (they are anti-too)

_____

http://kenschwaber.wordpress.com/2012/07/25/self-organization-and-our-belief-that-we-are-in-charge/

Ken Schwaber = Instead of extending, what can you get done?

_____

http://scrum.org/Forums/aft/206#838

Don McGreal is a pretty respected coach locally. Don = I would certainly avoid extending the Sprint or creating sicktime/holiday PBIs.

http://blog.cromwellhaus.com/2012/01/time-box-a-holistic-view-on-sprints-and-iterations/

_____

http://cromwellhaus.com/2012/02/time-box-get-stuff-done-tool-for-risk-reduction-focus-and-decision-making/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%253A+RyanCromwell+%2528Ryan+Cromwell%2529

These are articles suggested by Scrum.Org on time boxes.

_____

Abnormal sprint termination (PO Decision)

From the Scrum Guide 2011

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog Items are reviewed. If part of the work is potentially shippable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone has to regroup in another Sprint Planning Meeting to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.