“Free Kanban Board Template for Notion (Download + Guide)”

What does a Notion Kanban template actually need?

free Kanban board template for Notion is a key topic in modern project management and teamwork. Five properties and two databases. That is the whole system, and adding the sixth, seventh and eighth property is what turns a working board into a configuration project.

The Projects database holds one row per project with a status, an owner and a target date. The Tasks database relates to it. That single relation is what makes the rest work: a rollup on the project row can count open tasks, sum estimates and show the percentage complete without anyone maintaining a second list.

Why the Status property instead of a select?

Notion’s Status property is grouped: every option belongs to To-do, In progress or Complete. Groups give you a “complete” percentage that survives renaming an option, they let automations target a group rather than a specific value, and they keep the board sane when someone adds “In review” as a new option — it lands in the right group instead of becoming a fourth column nobody owns.

A plain select works, and many templates use one. The difference shows up in reporting: with a Status property you can ask “how much is complete” without writing a formula that lists every option name.

Should each project get its own board?

No, and this is the structural decision that determines whether the template survives. One Tasks database with a Project relation, then one board view filtered per project. Ten projects become ten filtered views over one dataset, which takes seconds and keeps reporting intact.

Ten separate databases look tidier in the sidebar and cost you every portfolio question you will ever ask. They also duplicate every property change ten times, which is the reason so many Notion workspaces end up with four incompatible definitions of “Done”.

How do you build it in Notion step by step?

About 40 minutes for the first build, then ten minutes per project because the template does the work.

1. Create the Projects database with four properties: Name (title), Owner (person), Status (status), Target date (date). Add a rollup later; start minimal.
2. Create the Tasks database with Name, Status, Assignee, Due date, Priority, Estimate and a Project relation pointing at Projects. Enable “two-way relation” so the project row shows its tasks.
3. Configure Status options as exactly: Not started, Next up, In progress, Blocked, In review, Done. Assign each to a group. Six options is the practical maximum; beyond that, columns become a filing system.
4. Build the board view and group by Status. Notion orders columns by group, then by option order; drag the options into the sequence you actually work in, not alphabetical order.
5. Turn on “Show on card” for Assignee, Due date, Priority and Project. A card that shows only a title forces people to open it, and opening cards is the tax that kills adoption.
6. Add a sub-group by Priority. This gives you swimlanes — P1 across the top, P3 at the bottom — which is how a board communicates what matters without a second board.
7. Save as a database template. In the database’s template menu, create a template called “Standard task” with Status set to Not started, Priority to P2, and a checklist in the body. New cards then arrive consistent.
8. Create the filtered views: `My tasks` (Assignee is me, Status is not Done), `This week` (Due date within 7 days), `Blocked` (Status is Blocked), `Backlog` (table view sorted by Priority).
9. Add a Calendar view by Due date and a Timeline view by Start and Due date if you track both. These are views, not copies; nothing needs re-keying.
10. Duplicate the whole page as the master template, then archive the sample tasks. Keep the views, the property order and the template card.

How do you make the board readable on a laptop?

Set card size to small, hide empty groups, and keep the property row on cards to three items. Then use filters rather than scrolling: the board is a working surface, and a board showing 300 cards is a database with columns drawn on it.

Two Notion-specific settings do a lot: “Fit to width” for the board so columns do not run off-screen, and per-view property visibility so the backlog table can show Estimate while the board does not.

How do you handle WIP limits without native support?

Notion does not enforce a work-in-progress limit. What it does give you is enough visibility to enforce one socially, which is how Kanban limits actually work in small teams anyway.

Show the group count. Every board column displays a count of cards. That number, agreed in advance, is the limit. If “In progress” is capped at three per person and the column shows nine for three people, the stand-up has its first agenda item.

Build a rollup counter. In Projects, add a rollup on the Tasks relation with the Count function, filtered to Status group “In progress”. The project row then displays live WIP. For a team view, create a small “Team health” database with a relation to people and a rollup counting their in-progress tasks.

Add a formula flag. On each task: `if(prop(“Status”) == “In progress” and prop(“Due date”) < now(), "Overdue WIP", "")`. Filter a view by that string and you have the exact list of work that is both started and late — the most expensive category in any project.

Use automations on paid plans. A rule such as “when Status changes to Done, set Completed date to today” or “when a card moves to Blocked, post a comment tagging the owner” removes a surprising amount of manual bookkeeping. On Notion’s paid plans these rules run per database; the free plan is more limited, which is one honest reason teams upgrade.

Make the limit visible in the template itself. A callout at the top of the board page that says “WIP limit: 2 per person, 6 total” is not enforcement, but it is the cheapest possible intervention and it works for about 80% of small teams.

Does a Notion board handle dependencies?

Partially. Notion’s Timeline view can show dependencies between tasks on paid plans, and a self-relation can record “blocked by” links. What Notion will not do is reschedule a chain when one card slips, or compute a critical path. If your schedule logic matters, the board is the wrong surface for it — use the timeline for communication and a proper Gantt tool for the maths.

What do the numbers look like?

Four worked examples, using a team you can scale to your own size.

Example 1 — WIP and cycle time. Little’s Law: average cycle time equals work in progress divided by throughput. A team finishing 2 tasks per day with 18 cards in progress has a cycle time of 9 working days. Cut WIP to 10 cards without changing throughput and cycle time falls to 5 days. Nothing about capacity changed; the team simply stopped starting work it could not finish. That is the entire argument for WIP limits, expressed as arithmetic.

Example 2 — the three-view cost. If each project keeps its own board and its own task list, every status change is entered twice. With 12 people making 4 status changes a day at 20 seconds each, that is 16 minutes a day, about 70 hours a year, or $3,500 at $50 an hour. One database with multiple views removes the duplicate entry entirely.

Example 3 — subscription maths. Notion’s free plan covers 10 guests with 7-day page history and 5 MB uploads. Plus runs about $10 per member per month on annual billing, so eight members cost $960 a year; Business, at about $20, costs $1,920 and includes more history, more guests and the AI features. Compare that with the $3,500 of duplicate data entry above, and the paid tier is not the expensive part of the system.

Example 4 — the setup break-even. A raw board (one database, three columns, no properties) takes five minutes and saves nothing, because it cannot answer “what is late” or “who is overloaded”. The full build takes about 40 minutes and removes roughly two hours a week of stand-up reconstruction for a nine-person team. At $50 an hour, the build pays for itself inside the first week.

How do you run a weekly board review that keeps it honest?

Fifteen minutes, one view, three questions. The review is the only mechanism that stops a board drifting into a museum, and it does not need a meeting room.

Walk the right-hand side first. Start at “Done” and read what finished since last week. This takes two minutes, gives the team a sense of progress before the complaints, and catches cards that were finished but never moved.

Then walk “Blocked” and “In review”. These are the two columns where work dies quietly. For every card, ask who or what unblocks it and set a date on the unblock action. If a card has been blocked for more than five working days, it is not blocked; it is unplanned, and it should go back to the backlog with a note.

Then check WIP against the limit. Count in-progress cards per person. Above the agreed limit, the only legitimate move is finishing something before starting something. Doing this aloud once a week is more effective than any automation, because it is public.

Then close with “what will be done by Friday”. Three to five specific cards per person, no more. That commitment is what the next review opens with, which turns the board from a status display into a forecast.

Finally, spend sixty seconds on hygiene. Cards with no assignee, cards with no due date and cards older than 30 days get fixed or archived on the spot. Notion will carry clutter indefinitely; the review is the only thing that deletes it.

Teams that run this ritual keep a board usable for years. Teams that skip it usually conclude, wrongly, that Notion is not a project management tool.

Where does the Notion Kanban template break down?

Notion is a document tool that grew a database engine, and the board inherits both strengths and limits.

No enforcement. Nothing stops a seventh card entering a column with a limit of three. Notion shows the count; a human has to care. Teams that need hard limits end up with automations and still police them manually.

Performance at scale. A database with a few thousand rows and a dozen rollups gets slow, particularly on the board view with sub-groups. Splitting by quarter or archiving completed work is maintenance, not optional.

Reporting is view-shaped. Notion can count and sum with rollups and charts, but cross-database reporting, burn-downs and time-phased capacity need formulas that become their own maintenance project. There is no equivalent of a pivot table over everything.

Permissions are coarse. You can restrict a page or a database, but not a row or a column, and a shared database with guests exposes everything in it. Client-facing boards usually need a separate, curated database rather than a filtered view.

Status drift and orphan cards. Without a weekly review, cards accumulate in “In progress” and the board becomes a memorial. Every Kanban system has this failure mode; Notion has fewer guardrails against it than a dedicated tool.

How does Notion compare with a dedicated project tool?

The pattern is familiar: Notion wins when the work is knowledge-heavy and the team is small enough that a person can hold the whole board in their head. It loses when the board must answer questions nobody is asking it out loud — capacity, dependency, forecast.

Who should use this template, and who should not?

Use it when the team is three to twelve people, the work is a mix of writing, design and delivery, and the same people need the brief and the board in one place. Editorial calendars, product discovery, agency retainers, hiring pipelines and internal ops all fit, because the card body is where the useful detail lives.

Do not use it for a 60-person programme, a schedule with hard dependencies, or anything where a client expects a capacity forecast. Also skip it if nobody will own the weekly review: a Notion board without a review is a very tidy archive.

The mistakes repeat. Creating a board per project. Using eleven statuses. Putting the due date in the card body instead of a date property. Keeping the default “Untitled” template so every card starts empty. And treating the board as a to-do list for one person while telling the team it is the source of truth.

How does Doitify fit beside a Notion workspace?

Doitify is our product, so read this as disclosure. It covers what the board cannot enforce: tasks and sub-tasks with owners and due dates, Kanban boards with real WIP views, Gantt charts with dependencies, calendars, workload, reports, automations and project documents in one workspace, plus a Copilot that turns a goal into a first-pass task breakdown.

The split that works for Notion-heavy teams is the same one that works for wikis: keep the thinking in Notion — briefs, research, decisions, client notes — and keep the execution in a tool that measures it. Link the two, then write down which one is authoritative before the first disagreement, not after.

Conclusion

A free Kanban board template for Notion is worth building properly: one task database, a Status property with grouped options, five working properties, a card template, and a small set of saved views for “mine”, “this week” and “blocked”. That version replaces the toggles-and-columns page that most teams abandon in month two.

It is still a board, not a system. Notion will show you the queue; it will not enforce a limit, reschedule a dependency or tell you who is overloaded next month. Keep it for what it does better than anything else — the thinking around the work — and put the schedule where it can be measured.

If this post on free Kanban board template for Notion was helpful, you might also enjoy How to Write a Project Status Report (5 Steps) and How to Create a Gantt Chart (Step-by-Step).