Agile Sprint Backlog & Task Board Markdown Table Template
A sprint backlog table is a snapshot of the work a team has pulled into the current sprint: what each item is, who is on it, how big it was estimated to be, and where it stands. In the Scrum Guide, the Sprint Backlog is the Sprint Goal plus the selected Product Backlog items plus the plan for delivering them, and it belongs to the Developers. The Markdown version shows up in sprint planning notes, standup docs, and pull-request descriptions when the tracker itself is not the place people are reading.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
It is not the product backlog. The product backlog is the long, ordered list of everything the product might need, owned by the Product Owner. The sprint backlog is the short list the team committed to for one sprint, and its rows should change only through the team’s own replanning. Mixing the two — dumping next quarter’s ideas into this table — makes it impossible to tell at the review what was actually committed.
A useful version is small enough to read in a standup, uses statuses that match the team’s Definition of Done, and makes progress obvious at a glance: how many points are Done versus still open. In the template, items worth 7 of 15 points are Done, which is the number a Scrum Master would quote mid-sprint. A weak version is a copy of the tracker that nobody updates after planning day.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| Ticket ID | center :---: | The tracker key in backticks (MKT-101) or as a link to the issue, so readers can jump to details. Centered per the template, though left alignment reads better when keys have different lengths. Never invent IDs for items not yet in the tracker. |
| User Story / Task Description | left :--- | A short title in the team’s usual form — a user story (“As an editor, I can…”) or an imperative task (“Fix LaTeX ampersand escaping”). Left-aligned. Keep acceptance criteria in the ticket; this cell should fit on one line. |
| Priority | center :---: | Use the scheme your tracker already uses, and make the labels unambiguous. P0 conventionally means the most urgent level, so pairing it with “High” rather than “Critical” can confuse people. Centered. Within a sprint, order of rows often says more than labels. |
| Assignee | left :--- | The person currently doing the work, by the name or handle the team uses in the tracker. Left-aligned. Leave it as Unassigned rather than blank for items nobody has picked up yet, so gaps are visible in standup. |
| Story Points | right ---: | The team’s relative estimate, typically on a Fibonacci-like scale (1, 2, 3, 5, 8, 13). Right-aligned so the column is easy to sum. Points compare items within one team; they are not hours and not comparable between teams. |
| Sprint Status | center :---: | A fixed set of states that mirrors the board columns, such as To Do, In Progress, In Review, ✓ Done. Centered. Only mark Done when the item meets the Definition of Done — “code merged but not deployed” is still In Review for most teams. |
How to Fill It In
- 1After sprint planning, export the sprint’s issues from the tracker (a Jira filter on
sprint in openSprints(), or a GitHub Projects view filtered by iteration) with key, summary, priority, assignee, estimate, and status. - 2Write the Sprint Goal above the table in one sentence. Every row should contribute to it, or be a known exception like an urgent bug.
- 3Paste the rows, keep the ticket key as a link, and order them by priority or by the order the team intends to work through them.
- 4Add a footer line with committed points, Done points, and the sprint dates. Recount at each update rather than editing the total by hand.
- 5Update statuses at least before standup and before the sprint review. If the table is going back into Jira, the Markdown to Jira converter handles the wiki-markup table syntax.
Ready-to-Paste Variations
Sprint summary for the review
One row per sprint, for retrospectives and stakeholder updates. Shows commitment against completion without per-ticket detail.
| Sprint | Dates | Sprint Goal | Committed pts | Done pts | Carried over |
| :--- | :---: | :--- | ---: | ---: | :--- |
| 41 | 2026-09-14 → 2026-09-25 | Ship the syntax playground | 18 | 15 | `MKT-104` |
| 42 | 2026-09-28 → 2026-10-09 | Grid editor keyboard support | 16 | 16 | — |
| 43 | 2026-10-12 → 2026-10-23 | Bundle size under 200 KB | 15 | 0 | — |Story broken into tasks
For teams that split stories into tasks during planning and track hours on tasks while keeping points on the story.
| Story | Task | Owner | Est. (h) | Status |
| :--- | :--- | :--- | ---: | :---: |
| `MKT-102` Keyboard cell insertion | Add `Enter` handler | Alex Rivera | 4 | Done |
| `MKT-102` Keyboard cell insertion | Focus management tests | Alex Rivera | 3 | In Progress |
| `MKT-102` Keyboard cell insertion | Update shortcut docs | David Kim | 1 | To Do |Common Mistakes
Treating story points as hours or using them to compare people.
Points are relative size within one team. Use them for the team’s own forecasting only, and never rank individuals by points completed.
Counting “In Review” items toward velocity.
Only items meeting the Definition of Done count. Partially done work goes back to the product backlog at sprint end and is re-estimated if needed.
Adding work mid-sprint without telling anyone.
Scope changes are negotiated by the Developers and Product Owner. Mark added rows (for example with “(added)” in the description) so the review shows what changed.
Using GitHub task-list checkboxes in the Status column.
- [x]syntax does not render inside table cells. Use text or✓instead; see checkboxes in tables for workarounds.
Related Markdown Table Templates
Browse all 50 templatesRACI Responsibility & Stakeholder Matrix
RACI governance chart defining who is Responsible, Accountable, Consulted, and Informed across critical project workflows.
Risk Assessment & Mitigation Matrix
Identify potential technical and business risks, calculate probability and impact scores, and document mitigation strategies.
Bug & Defect Triage Severity Log
Track software defects, reproduction steps, severity levels, target components, found versions, and resolution status.
Agile Sprint Backlog & Task Board: Frequently Asked Questions
What is the difference between the sprint backlog and the product backlog?
The product backlog is the ordered list of everything that might be built, owned by the Product Owner. The sprint backlog is the subset selected for one sprint, plus the Sprint Goal and the plan to deliver it, owned by the Developers.
Are story points part of Scrum?
No. The Scrum Guide does not prescribe any estimation technique. Story points are a widely used practice from the wider agile community; teams can also use ideal days, t-shirt sizes, or simply count items.
How do I calculate velocity from this table?
Sum the story points of items marked Done at the end of the sprint. Average the last three to five sprints for forecasting, and ignore single outliers caused by holidays or incidents.
Who updates the sprint backlog?
The Developers. Each person typically updates their own items, and the table is refreshed before standup. The Scrum Master may maintain the summary line, but should not be the only person keeping statuses current.