A Kanban board is good at one thing: it shows what moves. Who works on what. What waits. What is done. It is not good at the things that stay true for longer: how you do a release, why you chose a vendor, what a new colleague should read in week one.
Most teams put that knowledge somewhere else. A docs tool, a shared drive, a chat channel. Then the two drift apart. The task says “see the spec”. The spec moved. The person who knew where it was is on holiday.
This post shows how to split the work between a board and a wiki, and how to keep them linked. The examples use Kanroo, which has a wiki built in, but the ideas work with any pair of tools.
Board or wiki: where does it go?
A simple rule helps: the board holds what changes this week, the wiki holds what is still true next month.
| On the board | In the wiki |
|---|---|
| “Fix the login timeout” | How sign-in works, with a diagram |
| “Prepare the client workshop” | The workshop agenda you reuse every time |
| “Release 2.4” | The release checklist and the release notes |
| “Decide on the new mail provider” | The decision, the date and the reasons |
| “Onboard Lisa” | The onboarding guide for every new colleague |
A task is short-lived. It moves through your lists and then it is done. A page lives on. You update it, and the next task links to it again.
Five signs your board needs a wiki
- Task descriptions get very long. Long how-tos hide in tasks that end up in the done list, where nobody finds them again.
- The same question comes up every month. “How do we deploy?” “Where is the brand guide?” The answer belongs on a page, not in a comment.
- New colleagues read old tasks to learn the job. That works, slowly. A short guide works faster.
- Decisions get lost. Six months later, nobody knows why the team chose option B.
- You send the same document to every client. And each client gets a slightly different version.
If two of these sound familiar, a wiki will save you time.
How it works in Kanroo
In Kanroo, the wiki is part of the product, not an add-on. It sits next to your boards, uses the same people and roles, and links to tasks both ways.
Spaces and pages
A space holds the pages of one team or topic, such as “Engineering” or “Client A”. Give the whole organization, a team or one person the role viewer, editor or manager. It is the same model as on boards.
Pages nest up to five levels, in the order you choose. Every page also has a fixed number in its space.
Writing
You write in a visual editor that stores Markdown. Pages can hold tables, task lists, headings, images, code and callouts for notes and warnings. You can also add Mermaid diagrams: write the diagram as text or edit it visually, and it renders on the page.
You save on purpose. Your draft stays in the browser until you save, so a half-written thought never goes out by accident. If someone else saved in between, a dialog shows the conflict. You can open saved versions and restore one later. The number of saved versions per page depends on your plan.
Links between tasks and pages
This is where a board and a wiki become one system.
- Link a page from a task. In the task description, use Link page and pick the page from the search. The link shows as a chip with the page title.
- Link a task from a page. In the page editor, use Link task in the same way. A release page can list every task of the release.
- No access, no leak. If a reader may not open the target, they see a “No access” badge instead of the title.
To find anything, press Shift + K. The search covers tasks, boards and pages together.
Sharing pages with people outside
Sometimes a page is for a client or a partner. A share is a read-only link to one page, or to a page with its subpages.
- Add a password of 4 to 64 characters and an end date.
- Create as many share links as you need. For example, one per customer, so you can revoke one customer’s access without touching the others.
- Search engines are told not to index shared pages.
- Links on a shared page send no referrer, so other sites do not see where the visitor came from.
A setup you can copy
Here is a simple setup for a small team that builds websites for clients. The agency use case shows the same setup with screenshots.
Boards
- One board per client project, with the lists Backlog, This week, In review and Done.
- Labels for the type of work: Design, Content, Development.
Wiki spaces
- Team handbook: onboarding, tools, how we estimate, how we release.
- One space per client: the brief, contacts, decisions and the handover guide.
Links
- Each project task that needs context links to the brief or to a decision page.
- The release page links to the tasks of the release.
- The handover guide is shared with the client through its own share link.
After a month, most questions have a page. New tasks get shorter, because they link to the page instead of repeating it.
Write pages that stay useful
A wiki only helps if people trust it. These habits keep it fresh:
- One page, one question. “How we deploy” is a page. “Engineering notes” is a junk drawer.
- Date your decisions. Write the date, the options and the reason. Future you will be grateful.
- Link both ways. When a task changes a page, link the page from the task. When a page describes work, link the tasks.
- Keep how-tos short. Use numbered steps and one screenshot per step at most.
- Archive, do not delete. Archived pages can be restored. Old knowledge can still answer a question later.
What the Kanroo wiki does not do yet
We want you to know the gaps before you start:
- Two people cannot type in the same page at the same time.
- There are no page comments, page templates, tags or backlinks.
- PDF comes from the print dialog of your browser, not from the server.
These may come with community interest. If one of them matters to you, request it through our feedback form.
Bring your existing docs
You do not need to start from zero. Kanroo imports Markdown files, or one ZIP of them, into a space or below a page: up to 500 files and 25 MiB per import, unpacked and including images and attachments. You can export a page, a page with its subpages, or a whole space as a ZIP of Markdown files with their attachments. Your pages stay plain Markdown, so you can take them with you.
Summary
- The board shows what moves. The wiki keeps what stays true.
- Link tasks and pages both ways, so context is one click away.
- Share pages with clients through their own links, with a password and an end date.
- Start small: one handbook space and one space per project or client.
See more screenshots and details on the wiki feature page, or read how boards and pages work together.