Short answer: A sprint backlog is the ordered list of stories the team has committed to deliver in the current sprint, plus the sprint goal and the team's plan for delivering it. It's owned by the development team, scoped at sprint-planning, and updated daily. Distinct from the product backlog, which is the open-ended list of all desirable work. Most sprint backlog failures come from treating it as a wishlist instead of a commitment.
A sprint backlog is an organized queue of stories that the group has pledged to deliver as part of the current sprint. The team’s sprint is made up of three things: the stories themselves, a sprint goal (one-line theme), and their delivery plan. The development team owns the sprint backlog, which is scoped at the planning meeting and updated as they learn daily.
What is the significance of sprint backlog? Sprint backlog is the contract of the team. A team that values the backlog ships with predictability. When teams treat the sprint backlog like a wishlist. That is to say, they add items during the sprint, quietly remove items from the backlog, ignore it after the planning meeting. In that case, their output is inconsistent, and they break stakeholder trust. The discipline starts upstream, in how the product backlog is groomed and ordered before planning ever begins.
This guide will cover the working definition, what the sprint backlog actually contains, how it differs from the product backlog, who owns it and the failure modes that make it useless. Intended for scrum masters, anchors, engineering leads that have an inherited/bought-in sprint-backlog process.
What a sprint backlog is, plainly
The outcome the development team has committed to for the current sprint. It responds to three inquiries.
- What are we delivering? The stories the team has accepted into the sprint.
- Why does it matter? The sprint goal — a one-line theme that explains what this collection of stories adds up to.
- How will we do it? The team's plan for delivery — who's doing what, in what order, with what dependencies.
The foremost of these is observable. Often, the second is avoided. Most teams implement the third but mature teams use it explicitly.
The sprint backlog is defined in the Scrum Guide as “a plan by and for the Developers.” The phrase "by and for" is significant. The team rightfully owns the product, not the PM, scrum master, or other stakeholders. The team accepts what they can do, and they aren’t assigned work.
What it actually contains
| Component | What it is | Common failure |
|---|---|---|
| Stories | The user-facing items committed to | Includes work the team doesn't think they can finish |
| Sprint goal | One-line theme | Empty, or a slogan instead of a goal |
| Plan | How the team will deliver | Implicit, never written down |
| (Optional) Capacity model | Available person-days minus holidays/PTO | Skipped; sprint capacity overestimated |
| (Optional) Risks | Things that could derail the sprint | Captured in retro instead of in planning |
The initial three comprise the basic sprint backlog. The optional items add depth for teams that want them but are not strictly required. The one-line sprint goal does more work than people expect — we go deeper on it in setting a goal for your iteration.
A practical illustration. Sprint 14 Usage of Team’s Sprint Backlog Will Look Like or will appear to like
## Sprint 14 — "Improve checkout"
**Sprint goal:** Reduce checkout abandonment by shipping Apple Pay support
and fixing the address-validation bug.
**Stories committed (29 points total, capacity 32):**
1. [LITE-451] Support Apple Pay in checkout (8) — Priya
2. [LITE-453] Fix address-validation regression (5) — Marco
3. [LITE-455] Add inline shipping calculator (8) — Marco
4. [LITE-457] Save card details for return customers (5) — Priya
5. [LITE-460] Improve checkout button labels (3) — Lin
**Plan:**
- Priya focuses on payments-flow work (LITE-451, LITE-457) week 1
- Marco focuses on bug fix and inline calculator (LITE-453, LITE-455)
- Lin handles UX polish (LITE-460) in parallel
- Apple Pay sandbox needs vendor approval; risk if not granted by day 5
A true reflection of a sprint backlog has this. It's a single-page document that's read by everybody on the team and gets updated continuously throughout the sprint.
Sprint backlog vs product backlog
Many people mix them up. They are distinct lists that have different lifecycles.
| Aspect | Product backlog | Sprint backlog |
|---|---|---|
| Scope | All desirable future work | Stories committed to this sprint |
| Lifespan | Continuous, evolves over time | Sprint duration (typically 2 weeks) |
| Ownership | Product owner / PM | Development team |
| Order | Prioritised top-to-bottom | Ordered, with dependency-aware plan |
| Mutability | Items added, removed, re-ordered regularly | Frozen at sprint start; rarely changed mid-sprint |
| Status tracking | Light (just position in list) | Detailed (in progress, in review, done) |
A snapshot of the top of the product backlog at sprint-planning time, plus a plan for execution (= expected outcome) = sprint backlog. Once the planning finishes, the two are independent the product backlog continues to evolve (new items added, re-prioritised), while the sprint backlog stays focused on the committed work.
The product backlog is open for changes. The sprint backlog should rarely change: an emergency carve-out for a burning issue, perhaps removing a story as it turns out to be impossible, sometimes a substitution. Keep it off. The product backlog stays healthy through continuous refinement at the right cadence, not through last-minute reshuffling during the sprint.
Who owns the sprint backlog
It is owned by the Development team. During planning, the PM suggests stories while the team agrees on what they can complete, and Atlassian's sprint planning guide describes the same handshake. The PM does not add to the sprint backlog after planning without team consent.
During sprint conflicts, the backlog gets messed up or violated at every sprint. We require this in the sprint, can you fit this in? – without conversation, without cutting something else, without permission. This undermines the model that the sprint backlog is meant to uphold.
The anchor or scrum mastersysrdsdrsd =dr protects the sprint backlog from items being added mid-sprint. They're the team's supporter versus scope creep. When a stakeholder urges the team to start work on something new while a sprint is ongoing, the scrum master requests that the stakeholder stop pushing for this. The scrum master says, “We can take this in the next sprint” or “We can swap this for task X; you decide which is more urgent.”
In my experience, “agile” teams similarly lack any discipline around the sprint backlog. During the planning phase, the backlog is established. Next, the product manager subtly adds items throughout the sprint. Additionally, the team quietly carries items over. Eventually, the initial commitment evaporates. The retrospective highlights this issue which follows in the next sprint. Each alteration to the sprint backlog that occurs after planning is made clear and traceable by a one-line justification.
The math of sprint capacity
The available capacity must match the Sprint Backlog. The number crunching
- Person-days available = team size × sprint days − holidays − planned PTO − ceremony overhead
- Daily throughput (rolling-3 velocity ÷ person-days)
- Sprint capacity (points) = person-days available × daily throughput
- Buffer (10–20% reserve for unplanned bug fixes)
Total committed points equals the sprint capacity multiplied by the difference of one less buffer fraction.
This has an opinion. Certain teams do not formally calculate capacity, instead relying solely on velocity (the average of the sum of the last three sprints). This approach is suited for stable teams but fails when team composition or work type changes. Formal capacity computation immediately brings those changes to light. Treat velocity as a measure of pace, not productivity — the moment a team is judged on the number going up, the number stops being honest.
The math behind smaller stories. Cycle times drop from days to hours and teams reach users up to 14× faster. So, sprint backlogs with smaller stories have more predictable totals. Big stories can have a large variance from their estimated points (a story of 13 might land at 9 or 21) but a small story (like 3 points) has a small variance. The same logic shows up in how bugs and chores get estimated alongside stories — pointing the small stuff keeps the totals comparable across sprints. Smaller stories facilitate better capacity planning.
The most common sprint backlog failure
The majority of sprints show that the backlog drifts during the sprint.
Symptoms.
- New stories are introduced during the sprint without discarding any existing ones.
- User stories that will not finish will stay in the sprint backlog. A story that will not finish is a story that doesn’t meet the definition of done.
- The criteria that define whether a story is done tends to drift to what the team actually shipped.
- Sprint review does a demonstration of any work not included in the backlog.
The solution is a procedure rule: every change to the sprint backlog made after planning is logged with a one-line reason and reviewed at retro. The team must be having a planning problem if they make 5 changes each sprint. If they make 1, that’s normal. Predictability is the metric that matters here, not raw throughput — a team that hits its committed scope eight sprints in a row earns the trust to push back on mid-sprint additions.
Another failure that occurs is the sprint backlog which does not get a sprint goal. The team has 8 individual stories that aren't related or that add up to something meaningful. The solution is to record a one-line goal at planning-time, such as, ship bug-fixes or complete the auth rewrite. The team must inquire if the stories bring us closer to the goal.
When the sprint backlog model doesn't fit
The reality-based methodology.
- Pure kanban teams. No sprint, no sprint backlog. The continuous-flow backlog with WIP limits replaces it.
- Highly reactive teams. Support, incident response, ops work. The sprint backlog approach assumes stable scope; reactive work breaks the assumption.
- Single-engineer teams. The ceremony around sprint backlog is overhead for a solo developer. Use a personal TODO.
- Pre-PMF startups. The work is too exploratory. Maintain a product backlog and pull from it as priorities shift.
All the others: yes, a sprint backlog. Honour the planning commitment. Incorporate updates day-to-day but ensure scope doesn’t change mid-sprint without any specific reason.
Tools and where the sprint backlog lives
The team tracker is where the sprint backlog lives. Usual Choices.
- Jira — sprint container at the top of the Scrum board's backlog view, with stories dragged in.
- Linear — cycle (their term for sprint) with stories assigned to it.
- LiteTracker — sprint container in the ordered backlog, with story-only points and rolling-3 velocity by default.
- GitHub Projects — iteration view with stories assigned.
- Trello — a "Current sprint" column or board.
Discipline matters more than the tool. A Trello board team with strong sprint backlog discipline outperforms a Jira team with weak sprint backlog discipline. The default structure of the tool can either support the discipline or work against it. Thus, use a tool that has default settings that will help the discipline.
A real opinion on sprint backlog tooling
In our view, most tools bloat the sprint backlog. They offer sophisticated features for capacity planning, story-point bucketing, assignee swimlanes, and a dozen other toggles that don't change the work. Martin Fowler called this pattern out years ago as flaccid scrum — going through the ceremony without the engineering discipline underneath, then blaming the tool. The most effective tools keep the sprint backlog simple, limited to an ordered list of stories, with easy visibility of status and assignee, and surfacing velocity and cycle time without configuration.
Teams that prioritise the sprint backlog first, and tooling second, achieve the most value from their sprint backlogs. The proper level of tools contributes to the least that enables the process.
Frequently asked
What is a sprint backlog?
.
The current sprint is the overall goal for the sprint, and it is complemented by the ordered list of stories that the development team has committed to delivering. It contains thoughts on how the team will deliver. This is the responsibility of the development team and will be scoped at sprint-planning.
What's the difference between a sprint backlog and a product backlog?
The open-ended list of all desirable work belonging to the PM/PO is the product backlog. The sprint backlog contains all the work that the development team has committed to in the current sprint. At the time of planning, a portion of the product backlog is the sprint backlog.
Who owns the sprint backlog?
The software development team. The product manager puts forth ideas for the job during the planning. The team accepts things they are capable of delivering. After planning, the team takes ownership of the list. PMs and stakeholders cannot alter the scope mid-sprint unless the team gives their consent.
What goes in a sprint backlog?
.
The three components are the stories we committed to (with story points and who is doing what), the sprint goal (one line theme), and a plan for execution (who’s doing what, in what order). You may consider capacity modelling and associated identified risks.
Can the sprint backlog change during the sprint?
Not often The state of stories will be updated daily, of course, but changes in scope (adding or removing stories) should be the exception, not the rule. Ensure every change has a one-line reason and review it in retro.
How big should a sprint backlog be?
The team's sprinting ability must be equal to the capacity for work, with a buffer of 10–20% for unplanned work. For a two-week sprint, a team of five to seven engineers has about 8–15 stories. Larger indicates over-commitment smaller under commit.
Does the sprint backlog include bugs and tasks?
Certainly, as long as they are part of the expansion. Certain teams solely assign story points and keep track of unpointed bugs/tasks in the same sprint container. Other teams assign story points to all the items. We can endeavor to keep the velocity of the team meaningful. We can also have simpler metrics.
What's a sprint goal?
A one-liner theme that sums up the goal of the sprint. "Launch Apple Pay support", "decrease P95 latency by 30%", and "finish auth re-write" This helps the team make trade-off decisions during a sprint without re-planning.
Still stuck
The commitment to the Sprint (ie Sprint Goal + Sprint Backlog) is made and acknowledged by the Team, including Product Owner and Scrum Master. It becomes useful when we treat it like a contract scoping during planning, respecting through the sprint, updating every day while not changing the scope underneath.
If you need a tracker like that, one where the sprint backlog has the right defaults (story-only points, one owner per card, rolling-3 velocity, no Gantt overhead) baked in, that’s what LiteTracker is for. Unlimited users for free. The formal sprint backlog model is most likely overhead for a team of less than 3 engineers a shared list and a date will suffice.
Commit during the planning phase, and follow through the sprint.