Breaking the Sprint

When teams are using agile for a longer period, they become more experienced with agile and familiar with their team members. When teams as a unit become more experienced, sprints become more efficient while the amount of work assigned for each sprint will gradually become tailored to the perfect amount. However, reaching this Goldie-Locks amount of work for each sprint is only achieved through trial and error. Sometimes an agile team may decide, for a large number of possible reasons, that they can no longer deliver the work they committed to at the beginning of the sprint. When this is the case the team typically will end the sprint early, often referred to as ‘Breaking the Spring’ or even ‘Abending the Sprint.’

One of the most obvious reasons a team may not be able to complete all work that had been committed at the start of the sprint would be overcommitting on the amount of work. This is a common occurrence in newer agile teams. Another common occurrence with inexperienced agile teams is under-committing to the amount of work, which is safer than trying to plan out too much work to do. The prediction of amount of work to be completed is a controllable variable that tends to become less as a problem as time goes on. Other non-controllable variables may break a sprint as well. Such as, team family member emergencies, 3rd party technology failures, natural disasters, and even major product backlog re-prioritizations.

When one of the highest priority items on a product backlog list gets removed or transformed, it can affect the overall goal of the sprint so greatly that continuing to work on that sprint would no longer benefit the project at all. This scenario is often caused by the product manager having a misunderstanding on a requirement. The product manager will then communicate to the team the change in goals (and apologize for their misunderstanding). At this point the scrum master should jump in and remind the product manager that agile does not support such modification and that the smart thing to do would be to blow up the sprint and start a new one the next day.

Keep in mind that blowing up a sprint will generally cause all work during that sprint to become lost. This causes the projected finish date of a project to be pushed back as well as all sprints and tasks that come after the broken-up sprint. All because a team runs into a substantial issue does not mean that they should automatically break a sprint. Sprints should only be stopped and thrown out if the goal of the sprint no longer benefits the overall success and completion of the project.

Work Cited:

"Agile at Work: Driving Productive Agile Meetings." https://www.lynda.com/Business-Skills-tutorials/Breaking-sprint/175075/438009-4.html. Accessed 20 Nov. 2017.

Image Provided By:

https://softwareengineering.stackexchange.com/questions/304711/what-happens-if-sprint-goal-is-not-met