Mermaid kanban examples

Mermaid kanban syntax

The kanban diagram was added in Mermaid 11.4.0, which makes it one of the newer types, and its grammar resembles the mindmap’s: structure comes from indentation. A column is id[Title] at the first level of indentation; a task is id[Text] indented one level further under the column it belongs to. Mermaid’s documentation stresses three things: ids must be unique, tasks must be indented under their column, and the text goes in square brackets.

Columns and tasks are drawn in the order written, left to right and top to bottom. There is no syntax for work-in-progress limits, swimlanes or dates; a kanban in Mermaid is a snapshot of a board for a document, a retrospective or a plan, not a live tracker.

Which metadata keys does a kanban task support?

Mermaid documents three keys, all optional and all rendered on the card. Values with spaces or special characters go in single quotes; Mermaid 11.4.1 fixed a bug where a purely numeric ticket id or assignee broke rendering, so quoting those is still a good habit on platforms that may run 11.4.0.

Which Mermaid version do you need, and where does kanban render?

Kanban needs Mermaid 11.4.0 or later. That matters more than for older types, because platforms embed their own copy of Mermaid and update it on their own schedule: a board that renders on docs-md.com or in a current VS Code may show as plain code or an error in a tool that is still on Mermaid 10. GitHub renders mermaid blocks in issues, pull requests, discussions, wikis and Markdown files, and its documentation suggests rendering the one-word info diagram to see the version it runs; GitLab’s Markdown documentation states the Mermaid major version it supports. The Mermaid in Markdown page shows the version check and how each platform embeds a diagram.

When the reader’s platform cannot draw it, the fallback is the text itself, which for a kanban is still a legible list of columns and tasks. To share the rendered board with people outside your repository, paste the Markdown into the Docs MD editor and send the link, or convert the document to PDF.

Kanban, Gantt chart or timeline?

A kanban shows status now: what is waiting, what is in progress, what is done. A Gantt chart shows when: tasks with start dates, durations and dependencies on a calendar. A timeline shows what happened in order, without durations. For a sprint review or a weekly update, a kanban is the quickest to write and the easiest to read; for a plan with deadlines, use the Gantt chart; for a retrospective of a release, the timeline.

Because the board is text, it versions well: commit it with the code, diff it in a pull request, or keep one per sprint in a folder. The hub of Mermaid examples compares every chart type Docs MD covers, and the implementation plan guide shows a kanban alongside the written plan.

Which Mermaid version supports kanban diagrams?

Mermaid 11.4.0 added the kanban diagram, and 11.4.1 fixed rendering when a ticket id or assignee is a plain number. Any platform on an older Mermaid shows the code as text or reports an unknown diagram type. Render the info diagram on the platform to see its version before relying on a kanban there; docs-md.com runs Mermaid 11.16.

Which priority values are allowed in a Mermaid kanban?

Mermaid’s documentation lists four: Very High, High, Low and Very Low. There is no documented medium level; leave priority out for a task of normal priority. Quote the two-word values, as in priority: 'Very High', so that the space inside the value is read correctly.

Can tasks in a Mermaid kanban link to tickets?

Yes. Give the task a ticket value and set ticketBaseUrl under config: kanban in the YAML block at the top of the diagram. Mermaid replaces #TICKET# in that URL with the ticket value and renders the ticket id as a link. Whether the link is clickable depends on the host page’s Mermaid security settings, so test it where the document will be read.

Why does my Mermaid kanban not render?

Check four things. The platform must run Mermaid 11.4.0 or later. Each task must be indented more than its column, and each column less than its tasks. Every id, for columns and tasks alike, must be unique within the diagram. And metadata must be valid: only assigned, ticket and priority, with quotes around values that contain spaces. If the board renders but a card looks wrong, look for an unbalanced bracket in that task’s text.

Can I move a task between columns?

Only by editing the text: cut the task line and paste it under the new column, keeping the indentation. There is no interactivity in the rendered board. That is the trade-off of a text diagram, and also its advantage: the move shows up as a one-line change in version control, and the whole board can be reviewed like any other file.