Scrum Methodology
Learn Scrum
The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.
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.

Leave a Reply
Scrum Training Series
Recent Posts
- Scrum based funding model – 20 percent May 9, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
- Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting? February 5, 2013
- Happiness Metrics January 23, 2013
Archives
- May 2013 (1)
- March 2013 (1)
- February 2013 (2)
- January 2013 (2)
- December 2012 (3)
- November 2012 (1)
- January 2012 (1)
- December 2011 (2)
- November 2011 (3)
- October 2011 (2)
- November 2010 (1)
- September 2010 (1)
- June 2010 (1)
- April 2010 (1)
- March 2010 (1)
- February 2010 (1)
- December 2009 (3)
- November 2009 (2)
- October 2009 (4)
- September 2009 (4)
- August 2009 (2)
- July 2009 (2)
- June 2009 (2)
- May 2009 (2)
- April 2009 (2)
- March 2009 (5)
- February 2009 (2)
- January 2009 (2)
- December 2008 (4)
- November 2008 (3)
- October 2008 (4)
- September 2008 (4)
- August 2008 (1)
Categories
- Agile and Scrum (32)
- Agile Assessment (2)
- Agile Manifesto (6)
- Agile Principles (10)
- Scrum Basics (45)
- Scrum Discussion (28)
- Scrum Transitions (19)
- transformation (5)
- Uncategorized (10)