How to Run Scrum in Notion: Backlog, Sprints & Retros

Most scrum teams juggle separate tools for their backlog, sprint board, and retrospectives. Notion lets you build all three in one connected workspace, with full visibility across your agile workflow. You’ll spend less time switching tabs and more time shipping features.

If you’ve tried scrum or kanban boards in other tools, you already know the drill: user stories go into a backlog, you pull them into sprints, and you track progress until they meet your definition of done. Notion’s database system makes it easy to link everything together without duplicating work.

This guide walks you through building a working scrum setup in Notion, from backlog structure to sprint views and retro templates. Whether you’re a solo founder or a small dev team, you’ll have a system that grows with you.

Why Use Notion for Scrum?

Notion combines databases, kanban views, calendars, and docs in one place. That means your sprint board sits next to your meeting notes, your retrospectives link directly to the sprint they review, and your roadmap updates automatically when you tag stories with epics or releases.

You also avoid monthly subscriptions per seat. Once you build or buy a Notion scrum template, you own it. Teams under ten people often find Notion’s free plan covers their needs; paid plans start at a predictable rate with no surprise fees.

The downside? Notion requires more manual setup than dedicated agile tools like Jira. You’ll need to build your own views, formulas, and relations. But that flexibility means you can adapt the workspace to your exact process without waiting for a vendor to add features.

Setting Up Your Product Backlog Database

Create a new database and name it “Product Backlog” or “Stories.” This database will store every user story, bug, and task your team might work on. Each item becomes a page where you can add acceptance criteria, design files, or technical notes.

Add essential properties:

• Story Points (Number): Estimate effort using Fibonacci numbers (1, 2, 3, 5, 8, 13).
• Priority (Select): Use MoSCoW labels—Must Have, Should Have, Could Have, Won’t Have—to guide sprint planning.
• Status (Select): Options like Backlog, To Do, In Progress, Review, Done.
• Sprint (Relation): Link each story to a sprint database (you’ll create this next).
• Assignee (Person): Tag who owns the story.
• Epic (Relation): Group related stories under larger initiatives.
• Type (Select): Differentiate user stories, bugs, technical tasks, and spikes.

Create a “Backlog” view filtered by Status = Backlog. Sort by Priority, then Story Points, so high-value work sits at the top. This view becomes your grooming and planning workspace.

You can add a formula property to calculate effort-to-value ratios or flag stories missing acceptance criteria. Notion’s formula syntax takes practice, but basic calculations are straightforward.

Building Your Sprint Database

Create a second database called “Sprints.” Each page represents one sprint cycle—typically one to three weeks. You’ll link user stories from your backlog to the active sprint.

Add these properties:

• Sprint Name (Title): Use a naming convention like “Sprint 12” or “Week of Mar 10.”
• Start Date and End Date (Date): Define the sprint window.
• Goal (Text): Write a one-sentence objective for the sprint.
• Status (Select): Options like Planning, Active, Complete.
• Stories (Relation): This two-way relation connects to your Product Backlog database.
• Total Story Points (Rollup): Sum the Story Points property from all linked stories to see committed capacity.
• Completed Points (Rollup): Filter by Status = Done and sum points to track velocity.

Use a formula to calculate sprint progress: Divide Completed Points by Total Story Points and format as a percentage. This gives you a quick health check during standups.

Inside each sprint page, embed a linked view of your Product Backlog database filtered by Sprint = [this sprint]. Group by Status and display as a board so you get a classic kanban layout for the current sprint.

Creating Your Sprint Board View

Go back to your Product Backlog database and create a new view called “Sprint Board.” Set the layout to Board and group by Status. Your columns will be Backlog, To Do, In Progress, Review, and Done.

Filter this view to show only stories where Sprint = [current sprint name]. You’ll need to update this filter at the start of each sprint, or use Notion’s “Relative Dates” filter if you set up date properties on stories.

Add sub-groups by Assignee if your team wants to see who’s working on what. This nested grouping shows status columns split by person, which helps during standups.

You can also create separate views for different story types—one board for bugs, another for features. Notion lets you save unlimited views of the same database, so experiment until the layout clicks for your team.

Sprint Planning in Notion

Open your current sprint page and review the backlog view. During planning, drag stories from the Backlog status into To Do, and set the Sprint relation property to link them to the active sprint.

Watch your Total Story Points rollup. When it approaches your team’s average velocity, you’ve probably committed enough work. Velocity is the number of story points your team completes per sprint; track this over three to five sprints to find your baseline.

Write the sprint goal at the top of the sprint page. This one-sentence objective keeps the team focused. Examples: “Launch user profile editing” or “Reduce page load time below 2 seconds.”

You can embed a checklist or toggle list for your sprint ceremonies: planning, daily standup agenda, review demo script, and retrospective. Templates inside Notion let you duplicate this structure for every sprint so you don’t rebuild it each cycle.

Running Daily Standups and Tracking Progress

Create a “Standup Notes” database or use a simple page per sprint. Each day, team members add a quick bullet under their name: what they did yesterday, what they’re doing today, and any blockers.

Keep the sprint board view open during standups. Walk through the In Progress column to spot bottlenecks. If stories pile up in Review, you know your QA process needs attention.

Notion doesn’t generate burndown charts automatically, but you can build a simple progress tracker using a table or formula. List each day of the sprint in one column, manually log remaining story points in another, and create a line chart in a separate tool if leadership wants visuals. Alternatively, a pre-built template can include burndown automation using rollups and date formulas.

If you want a ready-made system with automated reports and sprint planning built in, the Scrum Board PRO template includes a sprint planner with burndown tracking, a bug tracker, and meeting note templates—all set up in about ten minutes.

Conducting Sprint Retrospectives

Create a “Retrospectives” database with a relation to your Sprints database. Each retro page links to the sprint it reviews, so you can trace improvements over time.

Add three main sections inside each retro page:

• What Went Well: List wins, smooth processes, or helpful collaboration moments.
• What Didn’t Go Well: Note blockers, missed estimates, or communication gaps.
• Action Items: Turn insights into concrete tasks. Assign an owner and a due date.

Use a toggle list or columns to keep the page scannable. During the meeting, everyone adds their thoughts under each heading. You can vote on action items using emoji reactions or a simple numbered list.

Track action items in a separate view or database. Create a filtered view that pulls all Action Items with Status ≠ Done, so they don’t disappear after the retro ends. This accountability loop makes retrospectives more than a venting session.

Connecting Epics, Roadmaps, and Releases

Create an “Epics” database to group related stories. Each epic is a larger initiative that spans multiple sprints—think “Onboarding Redesign” or “API v2 Migration.”

Relate epics to your Product Backlog database. Inside each epic page, embed a linked view of stories filtered by Epic = [this epic]. You’ll see all work tied to that initiative, regardless of sprint.

Add a Rollup property to count total and completed stories per epic. This gives you a quick progress bar for leadership updates or roadmap reviews.

You can also create a timeline or calendar view of your Sprints database to visualize release cadence. Map sprints to quarters or milestones so stakeholders see when features will ship.

Tips for Scaling Scrum in Notion

Use templates for recurring pages. Notion lets you save any page as a template. Create a sprint template with pre-filled sections for goal, planning notes, standup logs, and retro structure. When you start a new sprint, duplicate the template instead of building from scratch.

Automate with relations and rollups. The more you link databases, the less manual updating you’ll do. A story’s epic, sprint, and assignee can automatically populate reports or roadmaps without copy-paste.

Keep your backlog groomed. Schedule a weekly grooming session to update story points, refine acceptance criteria, and archive completed work. A cluttered backlog slows planning and hides priority.

Document your definition of done. Create a page or checklist that lists what “done” means for your team—code reviewed, tests passing, docs updated, deployed to staging. Link it from your sprint board so everyone has the same standard. Read more about defining done in scrum to avoid scope creep.

Review Notion’s changelog. Notion releases new features regularly—automations, buttons, and chart blocks—that can simplify your workflow. Check periodically to see if a manual process can now be automated.

Common Pitfalls and How to Avoid Them

Over-engineering your setup. Start with a backlog, a sprint board, and a retro template. Add complexity only when your team asks for it. Too many properties and views overwhelm new users and slow adoption.

Forgetting to filter views. If your sprint board shows every story in the backlog, it’s useless. Always filter by sprint or status so each view serves a single purpose.

Ignoring team buy-in. Notion works best when everyone updates their own tasks. If the team sees it as “the manager’s tool,” data goes stale. Involve the team in setup, let them customize their own views, and keep the structure simple enough that updating takes seconds.

Skipping retrospectives. It’s tempting to skip retros when sprints feel smooth. Consistent retros catch small issues before they become crises and build a culture of continuous improvement.

Ready-Made Templates vs. Building From Scratch

Building your own scrum workspace teaches you Notion’s database features and lets you tailor every detail. Budget a few hours to set up databases, properties, relations, and views. You’ll iterate as your team’s needs evolve.

Pre-built templates save setup time and include features you might not think to add—burndown tracking, bug severity labels, or meeting note structures. Many are free in Notion’s template gallery, though advanced options like the Scrum Board PRO offer more automation and ready-to-use sprint planning flows.

If you explore Notion’s ecosystem, you’ll find project management templates for scrum, kanban, and hybrid workflows. Test a few to see which structure matches your team’s rhythm before committing.

Integrating Notion With Other Tools

Notion’s API and integrations let you connect your scrum workspace to GitHub, Slack, or Zapier. You can auto-create stories from GitHub issues, post sprint updates to Slack, or sync completed tasks to a time-tracking tool.

If your team uses Microsoft Teams for standups, you can embed Notion pages or link sprint boards in channels. Notion also supports embeds from Figma, Miro, and Loom, so design files and demo videos live alongside your stories.

Keep integrations minimal at first. Each connection adds a potential point of failure. Start with your core scrum flow in Notion, then layer in automations as you identify repetitive tasks.

Final Thoughts on Running Scrum in Notion

Scrum in Notion gives you the flexibility to design an agile workspace that fits your team’s size, industry, and workflow quirks. You’re not locked into a vendor’s idea of how sprints should run, and you’re not paying per user every month.

Start simple: a backlog, a sprint board, and a retro template. Add epics, roadmaps, and automation as your process matures. The goal is a system your team actually uses, not a perfectly architected monument to agile methodology.

If you’re managing multiple projects or want more Notion inspiration, explore the Notion templates category for workflows tailored to freelancers, small businesses, and distributed teams.

Frequently asked questions

Can Notion replace Jira for scrum teams?

Notion can replace Jira for small to mid-sized teams that value flexibility and lower cost over advanced reporting and enterprise integrations. You'll need to build or customize your own views, formulas, and sprint structure, but you avoid per-seat licensing fees and get a unified workspace for docs, wikis, and boards. Larger teams with complex compliance or audit requirements may still need Jira's specialized features.

How do I create a burndown chart in Notion?

Notion doesn't offer native burndown charts, but you can build a simple tracker using a table with dates and remaining story points, then export to a charting tool or embed a Google Sheets chart. Some premium Notion templates include rollup formulas that calculate daily progress, which you can visualize externally. Alternatively, use Notion's API to push sprint data to a dashboard tool like Geckoboard or Databox.

What's the best Notion scrum template for beginners?

Start with Notion's free template gallery or a lightweight template that includes a backlog database, sprint board view, and retrospective section. Avoid templates with dozens of properties and nested relations until you understand the basics. If you want a complete system with planning automation and bug tracking built in, the Scrum Board PRO template offers a structured setup that you can customize as you learn.

How do I track velocity and sprint capacity in Notion?

Create a rollup property in your Sprints database that sums story points from all linked stories marked as Done. Track this number at the end of each sprint and calculate your average over three to five sprints—that's your velocity. Use that average to guide how many points you commit in future sprints. You can add a formula property to compare committed vs. completed points and flag over- or under-commitment.

Can multiple teams use the same Notion workspace for scrum?

Yes. Create separate databases or filtered views for each team's backlog and sprints, or use a Team property to tag stories and filter views accordingly. Relations and rollups still work across teams, so you can build a master roadmap or epic tracker that aggregates progress. Keep permissions clear so teams don't accidentally edit each other's sprints, and document your naming conventions to avoid confusion.

Is Notion free for scrum teams?

Notion's free plan supports unlimited pages and blocks for individuals, and small teams can often stay on the free tier. The Plus plan (around $10 per user per month at the time of writing) adds unlimited file uploads and version history, which is useful for larger backlogs and long-term sprint archives. Check Notion's pricing page for current limits, as plan features change periodically.