Sprints are a feature of the most popular agile approaches to project management and product delivery. They are primarily used to segment large pieces of work into smaller, more manageable chunks to be delivered by agile teams.

Sprints were first described as part of Scrum – one of the first and definitely the most popular of agile approaches in use today. They are also used by Nexus and LeSS (approaches used for scaling Scrum) and the latest version of AgilePM. Other agile approaches such as SAFe, DAD and XP use an almost identical concept but use the term Iteration rather than Sprint.

In the following paragraphs I will start by describing what Sprints are and how they are structured before getting into some pragmatic advice and guidance on ensuring they deliver as they should.

A Sprint is a short, fixed-length timebox during which a team works to complete a set of prioritized work. Sprints are intended to allow delivery teams to make meaningful, incremental progress towards longer term goals in a predictable, stepwise way.

Limiting Sprints to a timeframe of 2-4 weeks, and ensuring that each Sprint has a clear goal, encourages frequent delivery of valuable, strategically aligned outcomes.

The rhythm and discipline of Sprints, help teams build momentum, manage complexity incrementally, and adapt quickly to change. Importantly, it enables continuous improvement by providing frequent opportunity for feedback, learning and adjustment.

The Sprint, as defined by Scrum, has a specific structure. In this form it is best suited for use in a non-project context given that Scrum does not recognise the role of a Project Manager. AgilePM suggests some practical and pragmatic enhancements to this default structure offering value in the context of a project without contradicting or detracting from Scrum’s original intent.

The diagram below shows the structure of a Sprint as described in the Scrum Guide 2020 – the definitive guide to Scrum authored by the co-creators of Scrum Jeff Sutherland and Ken Schwaber.

It describes four key Events that most people would recognise as team meetings that occur during a Sprint. The diagram illustrates a 2-week sprint but for Sprints of a different duration most Events should scaled accordingly.

1. Every Sprint starts with a Sprint Planning event at which:

• A Sprint Goal is agreed
  • This is a collaborative process involving the Product Owner and the Developers in the Scrum Team.
  • The Product Owner is accountable for ensuring that the planned work delivers optimum value to stakeholders.
  • The Scrum Team need to negotiate a goal to which they can commit.
• What is to be done in the Sprint is negotiated
  • This is also a collaborative process involving the Product Owner and the Developers.
  • Items needed to meet the Sprint Goal and achieve a Product Goal are taken from the Product Backlog. Note that a Product Goal may take several Sprints to achieve.
  • There may be a degree of iteration between agreeing a precise Sprint Goal and the work needed to achieve it.
• How the agreed work will get done
  • This is a collaborative process in which the Developers break down the selected Product Backlog items into actionable work items and agree how they will be ordered in the Sprint Backlog.

The Sprint Backlog includes all three elements above the work to be done. By the end of Sprint Planning, the Sprint Backlog, which is ‘the plan’ for the Sprint that is owned by the Developers, is agreed.

2. The Daily Scrum

• This is a 15 minute (maximum) daily meeting of the developers
  • It is typically held at the same time every working day.
  • It does not scale in relation to the length of the Sprint.
  • Its purpose is to allow the developers to adjust their plans to maintain a focus on, and their commitment to, the Sprint Goal.

As the Sprint progresses Product Increments may be delivered, with each such Increment encompassing those the precede it. Delivery of Product Increments is the measure of the meaningful incremental progress mentioned earlier.

3. Sprint Review

• This is the forum used by the Scrum Team to demonstrate to stakeholders the value it has delivered at the end of the Sprint.
• The final Product Increment is formally reviewed in the context of its contribution to the Product Goal and any potential enhancements are discussed
• Such enhancements are added to the Product Backlog, assuming they aren’t already noted.

4. Sprint Retrospective

• The purpose of this event is for the Scrum Team to reflect on the effectiveness of their way of working
• Any ideas for improvement are discussed and prioritised. One or two of these ideas are adopted as experiments for the next Sprint with the impact evaluated at the subsequent Retrospective

The following enhancements to the Scrum Sprint are proposed by AgilePM where they add value in the context of project management. They are most likely to add value in multi-team projects where plans across teams need to synchronise into a coherent overall project plan.

5. The first of the enhancements is to replace the Daily Scrum that occurs 2 days before the end of the Sprint with a special Consolidation Scrum.

• At 30 minutes duration, this event is slightly longer than the Daily Scrum.
• In addition to the purpose of the event it replaces, the Scrum Team are asked to predict what of the outstanding work of the Sprint will be completed and what will most likely remain incomplete.

6. The second enhancement is the introduction of the Project Planning Event.

• This event is attended by the project leadership roles of Business Visionary, Solution Architect and Project Manager, each of whom have specific responsibilities in the leadership of the project in AgilePM.

Note: From a general project management perspective, the role labels are unimportant. The event should be attended by the project manager and any others responsible for shaping the course of the project Sprint-by-Sprint.

• The very near-term predictions from the Consolidation Scrum serve as an input to the event and allow for sensible planning input across all teams for the next Sprint
• The event also provides opportunity for planning towards a horizon beyond the imminent Sprint and for any project activities to be carried out by project team members who may not be members of a Scrum Team.

I have been working with agile approaches to project management and delivery since 1997. I know how well they can work and, equally well, how poor performance can be if things don’t work as they should.

If you want to embrace agility in project management, the best advice I can offer is to run your Sprints in accordance with Scrum guidance. This means that if you are a project manager you need to keep a bit of distance from the planning and execution of Sprints. You need to be close enough to ensure they work as they should while allowing the most powerful aspects of agility to turbo-charge their delivery.

Here are 6 ‘top tips’ for the successful use of Sprints

1. Try to leave Scrum alone.

• It is tried tested and effective if operated properly in line with Scrum Guide guidance. That said, understanding what makes it work, rather than just following it in a procedural way, is essential for getting the most out of it.

2. Use fixed length Sprints in a regular cadence

• In theory you can vary the length of each Sprint in a sequence and occasionally it makes sense to have an irregular length Sprint now and then. For example, an occasional Sprint may be longer or shorter than usual to fit in around seasonal holidays or to meet a delivery date that would otherwise land mid-Sprint.
• Defaulting to a fixed length Sprint does, however, make planning stakeholder engagement and tracking progress easier.

3. NEVER slip a Sprint end date

• One of the key benefits of using Sprints is the predictability of delivery it offers. On-time delivery of a valuable product can be virtually guaranteed by:
  • Respecting the end date of the Sprint, and
  • Prioritising the work to deal with the highest value and/or riskiest aspects before lower value and/or more straightforward aspects.

4. Don’t skip events.

• Every event in a Sprint has a purpose keyed to the empirical underpinnings of agility. Specifically:
  • Transparency of what is being done and how
  • Inspection of the evolving product and ways of working
  • Adaptation of these to make the product increasingly valuable and to improve efficiency and effectiveness of working practices

5. Try to ‘live’ the concept of team empowerment.

• Understand and embrace the values that underpin the agile way of working and encourage everybody associated with the project to do so. Scrum defines these values as Commitment, Focus, Openness, Respect, and Courage. Quoting from the 2020 Scrum Guide:

“When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.”

Bear in mind that you don’t need to be following a Scrum approach to adopt its values. Embracing them will add value in any team-based endeavour.

• Don’t dictate, lead collaboratively.
  • Team ownership and commitment are significantly diminished in an environment where a single individual, like a project manager, dictates what should be done and when
  • A collaborative approach to leadership that embraces the Scrum values described above will lead to enhanced quality and productivity.
• Influence plans (for both the solution and the delivery schedule) via the Product Owners. This requires recognition by the Product Owner that project leadership roles are key stakeholders.

And if your teams aren’t best placed to perform in an agile way…

6. Coach them towards it

• The agile way of working leans heavily into the idea that the people doing the work are best able to make detailed decisions about what needs to be done and how. Combined with a clear detailed definition of what is needed and why from a Product Owner working collaboratively as part of the team, this works very well. I have personally witnessed significant productivity increases that can only be attributed to a shift to empowered teams from a centralised ‘command and control’ approach.
• Empowerment must, however, be recognised as a two-way street, with leaders being willing to empower their teams and teams being able to embrace that empowerment. In situations without competence and commitment from team members, I have seen productivity plummet.
• The theory of situational leadership evolved by Paul Hersey and Ken Blanchard in the 1970s describes how a leader, perhaps in our context a project manager, can transition towards an optimum leader/team dynamic for agility.

Sprints are a cornerstone of many agile approaches, providing structure, focus, and rhythm to the delivery of value. While their roots lie in Scrum, the concept has been successfully adapted by a range of frameworks and scaled models, often under the broader term "iteration." Regardless of terminology, the principles remain consistent: timeboxing work, enabling frequent inspection and adaptation, and empowering teams to self-organise around clear goals.

When used thoughtfully, Sprints can dramatically improve project delivery — but only if they're respected. Treating Sprints as more than just a schedule, and embracing the discipline, values, and collaborative spirit that underpin them, is what unlocks their potential.

For project managers working in agile environments, the challenge is to support without controlling — to create space for empowered teams while ensuring alignment and focus. Done well, this balance leads not just to successful Sprints, but to consistently high-performing teams and enduring project success.