How to Build a Notion Sprint Planning Template (For Solo Devs and Small Teams)

Jira is built for engineering organizations. It assumes you have a scrum master, a sprint board admin, multiple teams, and enough complexity to justify a $10/seat/month tool with 200 settings you'll never touch. Linear is cleaner, but it's still another tool to maintain — separate from your notes, docs, and project planning.

If you're a solo developer or a team of two to five, Notion can handle sprint planning remarkably well. Everything lives in one workspace, sprint boards connect directly to your project docs, and you're not paying for a tool you're using at 5% capacity. Here's how to build a sprint planning template that covers the full loop: backlog, active sprint, velocity tracking, and retrospectives.

---

The Sprint Board Database

Create a new database called Sprint Board. These are the properties you need:

| Property | Type | Notes | |----------|------|-------| | Task Name | Title | The main field — keep it short and action-oriented | | Status | Select | Backlog / In Progress / In Review / Done | | Sprint | Number | Which sprint number this task belongs to | | Story Points | Number | Estimated effort: 1, 2, 3, 5, 8 | | Assignee | Person (or Text) | Who owns it — use Text if you're solo | | Priority | Select | P0 / P1 / P2 (P0 = must ship this sprint) | | Type | Select | Bug / Feature / Chore | | Due Date | Date | Optional but useful for P0 items |

Two things to get right from the start:

Status values must be consistent. Every view filter and rollup formula depends on exact string matches. Don't drift between "In progress" and "In Progress" — pick one and freeze it.

Story Points should be relative, not hours. Use relative sizing (1 = trivial, 8 = multi-day) and you'll recalibrate quickly after two or three sprints.

Sprint Progress Formula

Add a formula property called Sprint Progress:

prop("Story Points") / 20 * 100

This shows each task's percentage contribution toward a 20-point sprint total. View it as a Number. At the sprint level in the linked Sprint Summary database, you'll use a rollup to sum all completed story points and track velocity.

---

3 Views to Build

1. Active Sprint Board (Kanban)

This is your primary working view — the board you open every morning.

• View type: Board
• Filter: Sprint = [current sprint number]
• Group by: Status

The result is a four-column board: Backlog → In Progress → In Review → Done. Move cards left to right as work progresses.

Tip: Use @today in a filter on Due Date to auto-surface tasks due this week on the Active Sprint board. Go to Filter → Add filter → Due Date → is on or before → @today + 7 days. This surfaces anything that needs to ship by end of week without manually scanning every card.

2. Backlog Table

Everything waiting to be pulled into a sprint.

• View type: Table
• Filter: Sprint is empty
• Sort: Priority (ascending puts P0 at top), then Story Points (descending to surface the heaviest items)

This is your refinement view. Before sprint planning, groom this table: write clear task names, set priorities, add story point estimates. Anything without a Story Points value isn't ready to pull.

3. Sprint History Gallery

A retrospective view of everything you've shipped.

• View type: Gallery
• Filter: Status = Done
• Sort: Sprint (descending — most recent sprint first)

Use this to review what got done each sprint, spot patterns in what type of work tends to complete vs. slip, and reference past work when writing changelogs or project updates.

---

Want a full Notion workspace with project tracking, task management, and sprint views pre-built? The Side Project Dashboard ($24) includes all of this and more — duplicate it in one click.

---

The Sprint Planning Ritual

Run this every Monday morning. It takes 20–30 minutes.

1. Open the Backlog table. Sort by Priority + Story Points. The top items should be obvious.
2. Drag items into the Active Sprint board — or update their Sprint field to the current sprint number.
3. Set Story Points on anything that doesn't have them yet. Don't skip this — it's the only way velocity data becomes meaningful.
4. Target 20 SP per sprint. After two or three sprints, you'll know if 20 is too high or too low. Adjust accordingly.
5. Assign tasks. Even if you're solo, being the assignee forces you to think about whether you've overcommitted.
6. Set the sprint number. Increment by 1 from the previous sprint. Continuous numbering makes historical views cleaner.

The planning session — even for a team of one — is the most important part of the system. Without it, the backlog grows untouched and the sprint board becomes a graveyard of half-finished tasks.

---

Sprint Summary Linked Database

Create a second database called Sprint Summary. Link it to Sprint Board.

| Property | Type | Notes | |----------|------|-------| | Sprint | Number | Matches the Sprint field in Sprint Board | | Start Date | Date | First day of the sprint | | End Date | Date | Last day of the sprint | | Total SP Completed | Rollup | Sprint Board → Story Points → Sum (filter: Status = Done) | | Velocity | Formula | prop("Total SP Completed") — tracks per-sprint output |

The Total SP Completed rollup is the key metric. At the end of every sprint, it automatically tallies how many story points shipped. After five or six sprints, you'll see your actual velocity — how many points you consistently deliver. Use that number instead of 20 when planning future sprints.

Retrospective Template Button

On each Sprint Summary record, add a Template Button for retrospectives. Go to the record → click the "New" button dropdown → "New template" → name it "Retro."

Inside the template, add three sections:

## Stop
What slowed us down this sprint? What should we do less of?

## Start
What should we start doing in the next sprint?

## Continue
What worked well and should stay in the next sprint?

Run this at the end of every sprint — even solo. Writing it down takes 10 minutes and prevents repeating the same mistakes sprint after sprint.

---

Putting It All Together

The full system has three layers:

1. Sprint Board DB — where tasks live, get estimated, and get done
2. Active Sprint view — your daily Kanban working view
3. Sprint Summary DB — the velocity record and retrospective home

The weekly rhythm: Monday planning → daily board updates → Friday review → Monday planning again.

What makes this Notion-native approach work for small teams is the lack of ceremony. There's no Jira ticket workflow, no sprint creation wizard, no admin access required. You update a number field to change sprints. You drag a card to update status. It's fast enough that you'll actually maintain it.

---

If you'd rather skip the setup and start running sprints today, the Side Project Dashboard ($24) has the Sprint Board, Sprint Summary, velocity tracking, and retrospective templates pre-built. Duplicate it in one click and start planning your first sprint within the hour.