Notion Kanban Boards for Engineering: What You Give Up
By Sebastiaan Jansen · · 7 min read
A notion kanban board is a database view that groups pages into columns. It shows status well and runs engineering delivery poorly, because it does not enforce work-in-progress limits, measure cycle time, or turn ticket history into a forecast.
Teams use it because their specs, notes, and board already live in Notion. Ask whether the release lands this cycle and the board can only show a pile of cards.
What a Notion kanban board is
Notion does not ship a separate kanban product. A board is a database view, each card is a page, and the columns are groups, usually by Status or Select. You can also group by assignee, cycle, or any other property.
Add a Status property and switch to Board. Filters and a second view share the same rows, and a view only displays those rows. It does not cap "In progress," define "Done," or flag a card that has sat for three weeks. Those rules live in people's heads.
It pays to understand a kanban board notion view before you outgrow it. What Is a Kanban Board? A Practical Guide for Software Teams covers columns, WIP, and pull.
What you can set up in an afternoon
Give each card a title, a short page body, Status (Backlog, Ready, In progress, In review, Done), Type (bug, feature, chore), assignee, priority, and a target cycle. Filter the board to the current cycle and keep a table sorted by priority. Five people can see who owns what.
What the view will not do
- Nothing stops a seventh card from entering "In progress."
- Nothing records when a card entered a column unless someone types the date.
- Sub-tasks are nested pages or toggles, and the board does not roll them up.
- No column has a policy. "In review" means whatever the last editor decided.
Where a notion kanban works well
A notion kanban fits writing, research, and light coordination, where the work is the page inside the card. Status has three or four values and rarely moves backward. One person updates the board while doing the work, and the only question is whether it is done.
Engineering outgrows that setup once the card only points at a pull request, a Sentry issue, or a client thread. The page turns into a status sticker, and stickers go stale.
What engineering teams give up
Past one quarter, almost every engineering Notion kanban board runs into the same four losses.
No enforced WIP limits
Kanban only works as a pull system when each column has a cap. When "In progress" is full, you finish or unblock a card instead of starting one because Slack made it urgent. In Notion the cap is just text in the column name, such as "In progress (3)," and a fourth card still drops in. Kanban Flow: How Work Should Move Across Your Board describes the practice. If the board cannot refuse work, the limit will not hold.
Weak cycle time
Cycle time runs from started to done, and percentiles separate a normal ticket from a slow one. You cannot get them from current status. Notion stores a date only if someone types it, and people update Status while forgetting "Started on." A formula can subtract two dates, but it cannot fill in the blanks, so you never see which stage eats the week.
No forecast from your own history
A useful forecast is cards finished per week, given as a range. That needs a completion log, and the board only knows where each card sits now. A one-off export goes stale, and the next meeting reuses last quarter's round number.
Status drifts away from the code
GitHub, CI, and review comments change the real status. The Notion card changes when someone remembers, so standup turns into reconciliation. Trello Kanban Boards for Development Teams: Where They Work and Where They Break names the same failure: the card is not the system of work. And because the card is also a document, a stale spec travels with the stale status.
A worked example: one squad, six weeks
Six people track features in Notion. Headers say Ready (5), In progress (4), In review (3). In week 3 a production bug lands in Slack and a new card goes into In progress. Nothing warns anyone. Two cards are waiting on review, their owners start new work, and In progress climbs to seven.
In week 5 someone asks what will finish before Friday. Nine cards are Done and eleven are open, but Done has no dates, so the guess is "about eight." Friday ships six. Three cards were never split and had no pull request, and two were waiting on a client answer buried in a meeting note on another page.
The board showed columns. It did not record transitions, enforce a WIP cap, or keep the request next to the ticket. Falrow can turn a Slack thread, a client call, or a Sentry error into a ticket and plan it from the git repository under the team's rules. Cycle time percentiles and a Monte Carlo forecast then turn Friday into a range. Six people do not need all of that on day one.
Notion versus a board built for delivery
| Need | Notion board | Delivery tracker |
|---|---|---|
| Spec next to the status | Strong. The card is a page. | Usually a link or a field. |
| One person's tasks | Strong, via an Assignee filter. | Strong, if per-person views exist. |
| Enforce a WIP cap | No. The cap is column-name text. | Only if the tool can reject a move. |
| Cycle time percentiles | Only with hand-kept dates. | Native when status changes are events. |
| Forecast from throughput | Export, then calculate elsewhere. | Native when completion history exists. |
| Status matches GitHub or Sentry | Manual, unless you add a sync. | Closer, when tickets start from those sources. |
Stay if the first two rows are what matter. Move if the last three are how you answer leadership. How to Set Up a Jira Kanban Board (and When to Use Something Else) covers the other comparison: Jira records transitions and cycle time, but it can bury a small team in configuration. Notion has almost no configuration and almost no delivery math. Before you migrate, read Choosing a Kanban Board App: 9 Things That Matter for Dev Teams.
How to run a Notion board anyway
- Keep Status to four to six values.
- Put the WIP number in the column name. When a column is over the cap, finish, split, or unblock.
- Require Started and Finished dates, and do not backfill them later.
- Tie each card to one pull request.
- Count finished cards every Friday. Atlassian's overview of kanban boards explains why the policies matter more than the columns.
Run that for a month before you switch tools.
When to leave
Leave the Notion kanban board when two of these are true: more than one squad shares it and standup is a hunt for the real cards; a lead needs a date the board cannot give; bugs from Sentry or clients arrive faster than cards get made; or a spreadsheet already holds cycle time or the roadmap.
Move to a tool that counts the roadmap from tickets, keeps triage in defined stages, and stores forecast history. Falrow keeps that in one SQLite database. Access and pricing are on request during the private beta. Write the column policy first, though. Seven cards in "In progress" are still seven cards in a new tool.
Keep specs in Notion if people still write there. Compare types, stages, and triage on Falrow's tickets and workflow rules and the delivery loop. A "drag the card" policy will not produce an estimate.
FAQ
Can Notion make a kanban board?
Yes. Create a database, add a Status or Select property, and open a Board view grouped by it. Each row is both a card and a page, and filters and other views share the same database. That is all the feature does.
Is a kanban board in Notion good for software teams?
It fits a small team whose work lives on the page and who only need current status. It fails when you need WIP limits that stick, cycle time, or a forecast, because those depend on stored transitions. A Notion kanban board does not store them unless you type the dates.
How do I add WIP limits on a kanban board in Notion?
You cannot enforce them. Put the number in the column name, such as "In review (3)," and send the extras back in standup. Notion will still accept the drag. If that breaks down every week, the board is the wrong control.
Should we move from Notion to Jira or another tracker?
Move when status has to follow the code and someone owns a date range. Jira covers transitions and reporting, with more admin. A delivery workspace covers the request, the ticket, and a plan against the repo. Keep Notion for specs and leave the old board read-only.