Six reasons why sprint hangover is a fail

It is not uncommon for sprint teams to question the importance of finishing in a sprint what was intended. What does it matter if user stories simply carry over to the next sprint? So the argument goes. Often, the response they get is not very convincing. Does anyone really care? The answer is not always obvious and, depending on the context, different reasons may be valid. Here are my six reasons why it’s important to avoid sprint hangover:

1. Team cohesion: setting a team goal for a sprint brings team members together to achieve a common aim. Clear, short-term goals are essential for motivation and for good collaboration. If a team is indifferent to sprint hangover, then this means that they are not pulling together.
2. Predictability and transparency: any stakeholder should be able to look at the current sprint and expect with a high degree of confidence the items in the sprint to be completed within the sprint. If a team takes on work with no intention of trying to complete the work at the expected time, this is very poor for stakeholder confidence. This can lead to all sorts of detrimental knock-on effects, such as a complete loss of trust in the team and the temptation for stakeholders to try to break process in order to get things done.
3. Co-ordination: knowing when a certain piece of work will be done, allows for co-ordination of work between teams.
4. Capacity planning: taking on the right amount of work for a sprint allows a team to budget some time for other activities which are necessary for overall sustainability, such as dealing with housekeeping / tech debt / documentation / process improvements and so forth. If a team is always maxed out and always still in the middle of stories at the end of a sprint, sustainability falls by the wayside.
5. Prioritisation: knowing how much effort is involved in a piece of work helps a Product Owner to prioritise. The amount of time and effort involved in a piece of work can greatly impact prioritisation decisions. If a team regularly takes much longer on a piece of work than was planned, it is robbing the Product Owner of a decision lever.
6. Agility: the end of each sprint is an opportunity to re-prioritise. Perhaps a new request has come up which needs to take precedence over something else at the top of the backlog. Unfinished work at the end of a sprint impacts agility. Work which now may be lower priority may need to be finished before the higher priority work can begin. Or worse still, unfinished work may need to be parked or rolled back causing more disruption. This is ultimately the main point of a sprint: a clear set of priorities for a short period of time, striking a balance between avoiding team disruption and being flexible enough to manage changing priorities.

Haran Rasalingam is the Enterprise Agile Coach at Trainline.