Sprint

Avi Siegel

•

7 min read

What is a sprint?

A sprint is a fixed-duration period of time during which Agile teams work toward completing an agreed upon set of tasks. Typically sprints are two weeks long, although some teams choose to operate in four week or one week increments.

Sprints create a natural rhythm for the team, with clear start and end points. This cadence helps teams maintain focus toward the regular delivery of added value within their products. It also provides for frequent opportunities for feedback and adjustment.

During each sprint, a number of specific Agile ceremonies occur to help the sprint run smoothly. This ranges from Sprint Planning to kick off the sprint, Standups for the team to stay aligned, Sprint Review to close out the sprint, and Retrospectives to discuss how to make the process run more smoothly next time.

What are the goals of a sprint?

The primary goals of sprints are to:

  • Deliver iterative improvement and value within the product

  • Keep the team focused on clear, achievable objectives

  • Maintain a sustainable, predictable pace of development

  • Reduce risk through frequent delivery and validation

  • Continuously improve the team’s way of working

Pro Tip: Don’t underestimate the value of the sprint cadence on the team’s mental well-being. Having clear start and end points helps prevent burnout and creates natural breakpoints for reflection and celebration.

What is involved in a sprint?

Each sprint consists of several key components and activities that occur in a regular cycle.

Preparation

Technically, preparation comes before a sprint starts, but it is an important piece of the puzzle to ensure sprints happen smoothly.

There are several ways in which the entire product development team - the Product Manager (PM), Engineering Manager (EM), and developers - collectively prepare for a sprint:

  • The PM regularly performs the backlog grooming activity to be continually prepared for work that is coming down the road.

  • The team together runs through the formal Backlog Grooming ceremony to refine tasks to a point where they are ready to be pulled into a sprint.

  • (Recommended) The PM and EM meet ahead of the sprint to get aligned during Sprint Prep. This is not an official Agile ceremony, but is a key way for the PM and EM to get on the same page before discussing plans with the team, so as to be more efficient regarding people’s time within Sprint Planning itself.

Pro Tip: Sprint Prep adds a missing connection point to the process, and allows deep debates to happen ahead of time. Note, though, that the intent is not to hide the conversation, but rather to properly utilize people’s time. Transparency is still key. Wherever helpful, still provide the team with explanations as to why certain decisions were made. This allows them to be acknowledged, involved, utilized, and appreciated.

Sprint Planning

At the start of each sprint, the team meets during the Sprint Planning ceremony to:

  • Review and commit to specific work items from the groomed product backlog

  • Ensure shared understanding of the planned work

  • Identify potential risks

Pro Tip: Don’t over-commit during Sprint Planning. It’s easy for teams to get overzealous and overconfident. It’s better to pull in additional work mid-sprint than to consistently under-deliver. Leave some buffer for the unexpected - it will inevitably arise. This strategy will greatly help manage expectations.

Daily Work

Of course, amidst all these Agile ceremonies, the team must execute on the assigned tasks. This is the most fundamental responsibility of the developers: deliver working code that provides value to users.

And so, during the sprint, the team will:

  • Work on their committed tasks

  • Collaborate on code reviews

  • Keep tasks updated with current status and progress

  • Help remove blockers from others’ work when possible

Pro Tip: Protect the team’s focus during the sprint. Some degree of interruption is inevitable, but try to defer non-urgent requests to already-scheduled meetings and ceremonies. Context switching pain is real. Allow developers to get into a state of flow, and help them stay there.

Standup

Each day, the team will meet in a 15-minute Standup to:

  • Share progress on assigned tasks

  • Discuss upcoming work

  • Surface any blockers or risks

  • Identify needs for collaboration

Pro Tip: Utilize the sprint board during Standup to provide context as individual team members share their updates with the team. This visual aid will help team members remember their work, and thereby keep the meeting moving.

Sprint Review

There are two main components of the Sprint Review ceremony:

  1. Close the sprint in preparation for the next sprint

  2. Discuss and showcase work that was completed in the sprint

Closing out the sprint consists of:

  • Ensuring all tasks are assigned the correct status, with the most important update being to mark completed work as done so it is not brought into the next sprint

  • Discussing any incomplete work - how much work is left to be done in the next sprint, as well as any new tasks that must be created to properly log additional required work now that the core task is more intimately understood

Showcasing completed work consists of:

  • Technical discussions regarding newly implemented architecture

  • Live demonstrations of new features and product improvements

Pro Tip: Pull demos out of the agenda. The days where sprints are being closed and started can already be meeting-heavy and overwhelming - let the team focus on transitioning from one sprint to the next by scheduling demos on a different day.

Retrospective

After a sprint is closed, the team reflects on:

  • What went well during the sprint

  • What could be improved

  • Specific action items to take to improve processes

  • Follow-up on action items from the previous Retrospective

Pro Tip: Create a safe space for honest feedback to be provided during Retrospectives. The most valuable insights often come from team members feeling comfortable enough to discuss failures or concerns openly.
Pro Tip: Don’t do Retrospectives on the same day as Sprint Review and Sprint Planning. The days where sprints are being closed and started can already be meeting-heavy and overwhelming - let the team focus on transitioning from one sprint to the next by scheduling Retros on a different day.

Who should be involved in sprint activities?

Each role on the team will be responsible for and involved in a different set of overlapping activities during each sprint.

Product manager

The PM:

  • Facilitates or participates in all ceremonies (with the possible exception of Retrospectives)

  • Owns the product backlog in relation to priorities, scope decisions, and requirements, and ensures all the above are formalized by continuously performing backlog grooming

  • Represents the interests of both internal and external stakeholders - this includes users, customer-facing teams, sales, marketing, engineering, design, product, and leadership, as well as other teams depending on the organizational layout

Engineering manager

The EM:

  • Facilitates or participates in all ceremonies

  • Removes blockers and provides support as needed

  • Manages team capacity and assignments

  • Ensures technical quality and standards are maintained

Engineering team

The developers:

  • Participate in all relevant ceremonies (excluding Sprint Prep in particular)

  • Execute on sprint commitments

  • Collaborate on technical solutions

  • Perform code reviews

  • Raise concerns and blockers promptly

Best practices for sprints

  • Add Sprint Prep to your list of ceremonies. It will serve as an important touchpoint between the product manager and engineering manager to keep said team leadership aligned on priorities and expectations.

  • Document decisions and important discussions as you go. Often, teams will have deep, technical discussions regarding how to accomplish certain work, and then part ways and leave it to the assignee to take care of the rest. A common result ends up being that details are forgotten, with no paper trail to remind anyone of what was agreed upon, which in turn means the conversations have to later be had again. Take notes within the task comments and descriptions in your task management system - your future self will thank you.

  • Only pull new work into the sprint when absolutely urgent (or when someone runs out of work to do). Keep the team focused on the agreed upon priorities.

  • Maintain a sustainable pace. If the team is consistently scrambling to get work done by the end of each sprint and/or is working overtime to attempt to meet expectations, that means task estimates are off - address this in Retrospectives.

  • Don’t skip Retros. Many teams tend to skip the Retrospective meeting because they don’t see value in it, which often occurs because they focus too much on back-patting and complaining, and not enough time on collaborating on and assigning action items to improve the situation. Iterative improvement is important to keeping your sprints moving efficiently and productively. So again - do not skip Retros.

  • Keep ceremonies timeboxed. It’s easy for meetings to run long - enforced timeboxes will help the team stay focused.

  • Simplify the sprint closing/starting meeting(s). Some teams choose to, on a single day, close a sprint, showcase progress from said sprint, collaborate on how to improve processes, perform last minute task refinement, and start the next sprint. This, of course, can lead to long days of endless meetings - an exhausting endeavor for the entire team. As such, some teams choose to pull demos and Retrospectives out of the agenda, and schedule them on a different day. By doing this, the team can fully focus on the main goal of the day - transitioning to the next sprint - while also giving more space for demos and Retros to occur in less rushed environments.

  • Do not allow multitasking during Agile ceremonies. These aren’t times to accomplish other work. That will result in having to reiterate information repeatedly throughout the meetings, as well as missed insights when the knowledgeable party wasn’t paying enough attention to speak up.