Notion Project Management Template for Software Teams (Sprints & Agile)

A generic Kanban board isn’t a sprint board. This guide covers the Backlog/Sprint split, story-point rollups, and velocity tracking that make Notion work for agile software teams — not a task list with “To Do / In Progress / Done” pretending to be scrum.

Why a generic Kanban board falls short

The standard Projects/Tasks structure works fine for linear project work, but software teams need two things it doesn’t provide out of the box: a clear separation between “everything we might build” (backlog) and “what we committed to this cycle” (sprint), and a capacity number — story points — that turns planning into arithmetic instead of a vibe check.

The five-stage pipeline: items live in an unpointed Backlog until sprint planning pulls, points, and assigns them.

The Backlog / Sprint split

Two related databases instead of one. Backlog holds every feature, bug, and chore — pointed or not, assigned to a sprint or not. Sprints holds one row per two-week cycle, related to whichever Backlog items were pulled into it. The sprint board view is then just Backlog filtered to the current Sprint relation, grouped by Status — the same “one database, many views” pattern from the main tutorial, applied to agile work specifically.

Story points and velocity

Add a Story Points number field to Backlog, and a Type select (Feature / Bug / Chore). On Sprints, add a rollup summing Story Points from related Backlog items where Status = Done. Track that number across 3–4 sprints and you have a real velocity figure — not a guess — to plan the next cycle’s capacity against.

Setup roadmap

Setup Roadmap

1

Build a Backlog database

Title, Type (Feature/Bug/Chore), Story Points, Status, Priority.

15 min
2

Build a Sprints database

Sprint name, Start/End Date, and a relation back to Backlog items assigned to it.

10 min
3

Add the velocity rollup

On Sprints: sum of Story Points from related Backlog items where Status = Done.

10 min
4

Build the sprint board view

Kanban grouped by Status, filtered to the current Sprint relation only.

10 min
5

Run one full sprint before optimizing further

Real velocity data after one cycle tells you more than any amount of upfront tuning.

1 sprint

Need dev-tool integrations on top of this?

We connect this structure to GitHub and Slack for teams that want commit-linked status updates without leaving Notion for planning.

See integration builds →

Launch checklist

Sprint Launch Checklist

Backlog and Sprints are separate databases, related to each other — not one combined list
Every Backlog item has a Story Points value before it enters a sprint, not after
A velocity rollup exists on Sprints, calculated automatically from Done items
The sprint board view is filtered to the current sprint only, not the entire backlog
Type field distinguishes Feature / Bug / Chore for prioritization

Common mistakes

Common Mistakes for Software Teams

Using one Kanban board for both backlog grooming and active sprint work. — Conflates “what might we do someday” with “what are we doing this sprint,” making the board too noisy to trust during a sprint.
Pointing stories after they enter the sprint, not before. — Defeats the purpose of story points as a planning input — they become a record-keeping exercise instead of a capacity check.
No velocity tracking across sprints. — Without it, sprint planning is a guess repeated every two weeks instead of a number grounded in the last 3–4 cycles.
Bugs living in a separate, disconnected tracker. — Splits prioritization across two systems and makes it impossible to see true team capacity in one place.

Free Notion Template

Agile Backlog + Sprint Tracker

The Backlog/Sprint structure from this guide, with a working velocity rollup pre-built.

Duplicate This Template →

Template link placeholder — replace href with the live Notion “Duplicate” share link before publishing.

FAQ

Can Notion replace Jira for a software team?

For small-to-mid teams without heavy dev-tooling integrations (advanced Git linking, complex workflow automation), yes. Teams deep in a Jira-integrated toolchain — CI/CD triggers, release management — usually keep Jira and use Notion for planning and docs instead.

How do I calculate sprint velocity in Notion?

A rollup on a Sprints database summing Story Points from related Backlog items where Status = Done, filtered to that sprint. Track it sprint over sprint in a simple table to see your team’s real average.

Should bugs and features live in the same database?

Yes, with a Type select field (Feature / Bug / Chore) — keeping them in one Backlog means a single prioritized view instead of context-switching between two systems.

Does Notion support burndown charts?

Not natively as a chart type, but a Story Points Remaining rollup filtered by day, exported or charted via a connected tool, approximates it. Most small teams find the sprint-level velocity rollup sufficient without a full burndown.