What is a Sprint Backlog?
The sprint backlog is the collection of work items that the development team selects from the product backlog during sprint planning and commits to completing during the sprint. It includes user stories, tasks, bugs, and any technical work needed to achieve the sprint goal.
Unlike the product backlog (which the PM owns), the sprint backlog belongs to the team. They decide which items they can realistically complete based on their capacity and velocity.
Why the Sprint Backlog Matters
The sprint backlog transforms a prioritized wish list into a concrete delivery plan. It answers the question: "What are we actually building this sprint?" This clarity enables focused execution and protects the team from mid-sprint distractions.
For PMs, the sprint backlog is the commitment. Once items are in the sprint, the team is expected to deliver them. This creates a predictable rhythm of delivery that stakeholders can rely on.
How to Build a Sprint Backlog
During sprint planning, the PM presents the highest-priority items from the product backlog. The team evaluates each item's complexity and pulls items until they reach their velocity-based capacity.
Each item should meet the Definition of Ready: clear acceptance criteria, understood dependencies, and reasonable size. Items that are too large should be split into smaller stories.
The team then creates a delivery plan: decomposing stories into tasks, identifying dependencies between tasks, and determining the work sequence. This plan is visible on the sprint board.
Sprint Backlog in Practice
In Scrum, the sprint backlog is one of three artifacts alongside the product backlog and the increment. It is updated daily during stand-ups as the team moves items from "to do" to "in progress" to "done."
At companies using Kanban-style sprint boards (like Linear or Jira), the sprint backlog is visualized as a board with columns representing workflow stages. Work-in-progress limits prevent the team from starting too many items simultaneously.
Common Pitfalls
- Overcommitting. Teams that consistently pull more work than they can finish erode trust and create carryover. Use historical velocity as a realistic guide.
- Mid-sprint additions. Adding work mid-sprint disrupts focus. If something truly urgent arises, swap it for a lower-priority item rather than just adding.
- No sprint goal. A sprint backlog without a unifying goal is just a list of tasks. The sprint goal provides purpose and flexibility.
- Incomplete items at sprint end. Partially done work carries forward as waste. Break stories small enough to complete within a single sprint.
Related Concepts
The sprint backlog is selected from the product backlog during sprint planning. It is executed during the sprint and measured by velocity. Each item should have a Definition of Done and be sized using story points.