Sprints

Plan iterations, track velocity, and manage scope.

What Is a Sprint?

A sprint is a time-boxed iteration of work — a fixed period (typically one to four weeks) during which the team commits to completing a defined set of tasks. Sprints create a predictable rhythm of planning, execution, and review that helps teams deliver incrementally and improve continuously.

Sprints are used with Scrum boards. Each Scrum board has at most one active sprint at a time, and the board displays only the tasks in that sprint. This focused view keeps the team concentrated on the current iteration's goals rather than the full backlog.

Sprint Lifecycle

Every sprint moves through three stages:

Sprint Planning

Planning a sprint involves defining the iteration and deciding what work the team will commit to:

Sprint Details

• Name — A descriptive name for the sprint, such as "Sprint 14" or "Q2 Release Hardening." Names help the team identify sprints in reports and retrospectives.
• Goal — A short statement of what the team aims to achieve during the sprint. The goal provides direction and helps the team make trade-off decisions when unexpected work arises.
• Start date — When the sprint begins. Activating the sprint records this as the official start for reporting purposes.
• End date — When the sprint ends. The time between start and end defines the sprint duration.

Selecting Tasks

During planning, the team pulls tasks from the project backlog into the future sprint. The team considers task priorities, estimates, dependencies, and team capacity to decide how much work to commit to. Tasks can be reordered within the sprint to indicate priority.

Teams that estimate tasks (using story points, hours, or other units) can compare the total estimate for the sprint against their historical velocity to gauge whether the commitment is realistic.

Committed Tasks and Scope Creep

When a sprint is activated, the system takes a snapshot of all tasks currently in the sprint. These are the committed tasks — the work the team agreed to deliver during planning.

Any task added to the sprint after activation is flagged as scope creep. Scope creep tracking is automatic and requires no manual action from the team. This separation is important because it lets the team and stakeholders understand:

• How much of the original commitment was delivered
• How much unplanned work was pulled into the sprint
• Whether scope creep is a recurring pattern that needs to be addressed

Sprint reports clearly distinguish between committed and added tasks, giving an honest picture of how the iteration played out versus how it was planned.

Closing a Sprint

When a sprint ends, the team closes it. Closing a sprint is an explicit action — sprints do not close automatically when their end date passes. This gives the team the opportunity to wrap up any last-minute work and handle incomplete tasks deliberately.

During the close process, every unfinished task must be explicitly handled. The team decides what happens to each incomplete task:

• Move to the next sprint — The task carries over to the upcoming sprint. This is the most common choice for work that is in progress or nearly done.
• Return to the backlog — The task goes back to the project backlog for re-prioritization. Use this for tasks that were not started or are no longer a priority.
• Move to a specific future sprint — The task is placed into a planned future sprint if the team already knows when it will be addressed.

No task is silently orphaned. This explicit handling ensures that nothing falls through the cracks and every piece of unfinished work has a clear next step.

Velocity Tracking

When a sprint closes, the system automatically records the sprint's velocity — the total amount of work completed during the sprint, measured in whatever estimation unit the team uses (story points, hours, or task count).

Velocity is one of the most important metrics for Scrum teams because it enables:

• Capacity planning — By looking at average velocity over the last several sprints, the team can estimate how much work to commit to in future sprints.
• Trend analysis — Is the team's throughput increasing, decreasing, or staying stable? Velocity trends reveal whether process improvements are having an effect.
• Release forecasting — With a known velocity and a sized backlog, teams can project when a set of features will be complete.
• Commitment reliability — Comparing committed work to completed work over time shows how well the team estimates and delivers on its promises.

Sprint Reports and Charts

Work Ops provides several reports to help teams understand sprint performance:

Burndown Chart

The burndown chart is the classic sprint tracking tool. It plots remaining work (vertical axis) against time (horizontal axis). An ideal burndown shows a steady diagonal decline from the total committed work at sprint start to zero at sprint end.

In practice, the line may plateau (no progress), spike upward (scope added), or drop sharply (large tasks completed). Reading these patterns tells the team whether they are on track, falling behind, or dealing with excessive scope changes.

Burnup Chart

The burnup chart shows completed work over time, plotted against the total scope. Unlike the burndown chart, the burnup chart makes scope changes visible as a separate line. If the scope line keeps rising while the completed-work line climbs steadily, the team can see that the finish line is moving away from them.

Velocity Chart

The velocity chart plots the amount of work completed in each sprint over a series of sprints. It typically shows both committed work and completed work side by side, making it easy to see whether the team consistently delivers on its commitments.

The chart also displays a rolling average velocity line, which is the number most teams use for planning future sprints.

Sprint Report

The sprint report provides a comprehensive summary of a completed sprint:

• Tasks completed versus tasks committed
• Tasks added after sprint start (scope creep)
• Tasks removed during the sprint
• Tasks carried over to the next sprint
• Total story points or hours completed
• Sprint goal and whether it was achieved

Sprint reports are valuable inputs for retrospective meetings, giving the team concrete data to discuss what went well and what could improve.

Sprint Best Practices

• Keep sprint length consistent. Whether your team sprints in one-week, two-week, or three-week cycles, stick with the same duration. Consistent sprint lengths make velocity data meaningful and comparisons valid.
• Write a sprint goal. A clear goal gives the team a shared purpose and helps with prioritization when trade-offs arise mid-sprint.
• Do not overcommit. Use historical velocity to guide commitment. It is better to finish early and pull additional work than to consistently carry tasks over.
• Address scope creep. Some unplanned work is inevitable, but if it happens every sprint, investigate the source. Can it be channeled to a Kanban board? Can better intake processes reduce interruptions?
• Close sprints promptly. Letting sprints linger past their end date erodes the sprint rhythm and makes reports less useful. Close the sprint and handle incomplete work explicitly.
• Use retrospective data. Sprint reports and charts are tools for improvement, not just record-keeping. Bring them to retrospective meetings and let the data guide the conversation.