Setting Your Team Up for Success in the New Year: A Scrum Perspective

The end of the calendar year brings a natural pause that many Scrum teams fail to use deliberately. The sprint that straddles the holiday period tends to be treated as just another sprint -- or quietly regarded as a low-productivity interval to survive before things get back to normal in January. Neither approach takes advantage of a genuine opportunity. The transition between years, if used well, is one of the better moments available to a Scrum team for deliberate reset and renewal.

This is not about elaborate ceremonies or off-site retreats. It is about using the natural breathing room of the year-end period to address the accumulation of small technical debts, process shortcuts, and implicit assumptions that every team builds up over the course of a year. It is also about bringing fresh strategic perspective to the product backlog before January creates its own momentum.

Update Your Definition of Done

The Definition of Done (DoD) is the team's shared standard for what constitutes a complete, releasable increment. Most teams establish a DoD at the start of a project and then let it drift over time -- adding items informally, removing others through gradual neglect, and accumulating implicit exceptions that everyone understands but nobody has written down.

Year-end is an ideal time to audit the Definition of Done formally. Hold a focused session where the team reviews the current DoD item by item. Which items are consistently met? Which are aspirational rather than operational? Which important quality standards are missing entirely? Update the document so it reflects what the team actually believes constitutes done -- not what was written 18 months ago and has since been silently amended.

Also examine whether the DoD has kept pace with quality expectations that have evolved over the past year. If the organisation has adopted new accessibility standards, security requirements, performance benchmarks, or compliance obligations, those should be reflected in the DoD -- not added as ad hoc reminders during sprint reviews.

Refine and Re-prioritise the Product Backlog

The product backlog reflects the product owner's best understanding of what is most valuable, most urgent, and most feasible at any given point in time. Over the course of a year, strategic priorities shift, market conditions change, and the backlog can become a historical artefact -- filled with items that made sense when they were written but whose priority has changed significantly since.

Year-end backlog refinement should take a more comprehensive approach than the regular sprint refinement sessions. Set aside dedicated time for the product owner and team to review the full backlog -- or at least the top 30 to 40 percent -- through the lens of next year's strategic priorities. Items that were high priority for reasons that no longer apply should be moved down or removed. Items that have become newly important because of strategic shifts should be elevated.

This is also the right moment to clear backlog debt: items that have been sitting in the backlog for months or years with no realistic prospect of being worked on, items that have become technically obsolete, and items whose business case is no longer clear. Removing them is not failure -- it is honest prioritisation.

Revisit Team Working Agreements

Working agreements are the explicit norms the team has established for how they will work together -- communication channels, meeting norms, code review expectations, on-call arrangements, and the like. Like the Definition of Done, working agreements tend to drift from their original form over time, and new team members who joined during the year may not have the same understanding of them as founding members.

Year-end is a natural time to surface working agreements explicitly, review them as a team, and update them to reflect how the team actually wants to operate -- not how it was operating when the agreements were last written. This review also creates an opportunity to address tensions that have built up over the year but never been formally acknowledged: meeting structures that are not working, collaboration patterns that are creating friction, or tooling choices that have become a source of frustration.

Set the First Sprint Goal for January

One of the most effective things a Scrum team can do before the year ends is to agree on the first Sprint Goal for January. The Sprint Goal is the single objective that will give the first sprint of the new year its coherence -- the answer to the question of why the team is doing this particular sprint.

Without a clear Sprint Goal, the first sprint of January tends to get loaded with whatever was left over from the final sprint of December, whatever someone thought of during the holiday break, and whatever the loudest stakeholder requested most recently. The result is a sprint without a coherent purpose, which sets a poor tone for the year.

Agreeing on the first Sprint Goal in advance does not require complete sprint planning before the year ends -- that would be premature. But it does require the product owner to have a clear view of what matters most in January and to be able to express it as a single, motivating objective. The team knows what to prepare for; stakeholders know what to expect; and January starts with direction rather than drift.

What Not to Do

• Carry over stale sprint commitments. If items were not completed in the final sprint of the year, treat them as backlog items that need re-evaluation -- not as automatic carry-forwards that inherit their previous priority without scrutiny.

• Start the year without a clear product goal. A product goal is the longer-horizon objective that the current sprint goal is serving. If the team does not have a clear product goal for the new year, January sprint planning will lack the strategic context that makes prioritisation meaningful.

• Ignore the lessons from the past year's retrospectives. The most common failure mode of retrospectives is that actions are identified and then quietly abandoned. Year-end is the moment to review what the team committed to improving over the past year and to assess honestly whether those improvements were made -- and if not, why not.

XNM Consulting helps organisations build effective agile and Scrum delivery practices, from team-level process design to enterprise-wide agile transformation.