What information belongs on a card on a Kanban board?
answer
- A token, not the document
- Readable from across the room
- Who has it, and since when
- Blocked needs a reason and a date
- Detail lives behind the link
basics
~20 sA card carries what someone needs to pick the work up: a short title, an identifier, who has it now, when it started, its class of work, and a blocked marker. The detail lives behind a link.
solid answer
~50 sA card is a **token for one piece of work**, not the place the work is written down. It should carry a title a reader recognises from across the room, an identifier linking to the detail, the person on it now, the date it entered the first activity column, its class of work, and a visible marker when it is blocked, with the reason and the date the blockage started. Anything long - the specification, acceptance criteria, design notes - stays behind the link, because a card people cannot read at a glance stops being read at all. The test is whether someone who is not on the team can walk up and say what is being worked on, by whom, and what is stuck. Every extra field is a promise somebody has to keep true by hand.
code
pseudocode · 8 linesCARD
title Retry uplink after modem reset
id TEL-4471
owner (none - card is in a queue column)
started day 12 of the release window
class standard
blocked no
detail -> linked page: spec, acceptance criteria, notesgo deeper
Be ready to say what a card is for: it identifies one piece of work and shows its state. Recall the handful of things on the face - title, identifier, owner, start date, blocked marker - and say where the longer detail lives.
Explain why each field earns its place and what it costs to keep true. An interviewer expects the blocked marker described as mark plus reason plus date, and a clear reason why long detail belongs behind a link rather than on the card face.
Show that you have watched boards go stale. Talk about fields that are silently wrong, why one stale field discredits the accurate ones, and how you would trim a card that has grown fields to feed somebody else's report.
Own the tension between what the team needs at a glance and what the organisation wants to extract. Be ready to argue that reporting demands belong outside the card, and to say how you keep the card face small when several stakeholders are pushing fields onto it.
## A card is a token, not a container A card on a Kanban board stands for **one piece of work moving through the team's workflow**. Its job is to be recognisable from across the room and to say where that work has got to. It is not the place the work is written down. The specification, the acceptance criteria, the design sketch and the test evidence live wherever the team already keeps written material; the card carries a pointer to them. Confusing the token with the container is the most common way a board quietly dies. Cards grow into documents, nobody can read the board without opening things, and within a few weeks the team stops looking at it and goes back to asking each other what is happening. A board that has to be interrogated is not a visualisation. The working test is a stranger test. Someone who is not on the team walks up to the board and, without opening anything, should be able to answer: 1. What is being worked on right now? 2. Who has each of those items? 3. What is stuck, and for how long? If the board cannot answer those three, adding fields will not fix it. ## The fields that earn their place | Field | What it buys | What it costs | | --- | --- | --- | | Short human title | Recognition at a glance | Somebody has to phrase it well | | Identifier | The link to the written detail | Nothing, if it stays small | | Current owner | Ownership is a fact, not an assumption | Must be changed at every handoff | | Date it entered the first activity column | A long-sitting card is visible without anyone's memory | Set once, never edited | | Class of work | The card's handling rule is visible where it is pulled | Needs an agreed set of classes | | Blocked marker, reason and date | A blockage is a fact rather than a rumour | Must be added the day it happens | Two of those deserve emphasis. - **The owner** matters for work in an activity column. A card with nobody's name on it, sitting in a column where somebody is supposedly working, is the board telling you that the work is really waiting. - **The blocked marker** has three parts: a visible mark, the reason, and the date it started. A mark without a date turns into wallpaper, because every reader assumes it is recent news and nobody can tell how old it really is. ## What to leave off - **Percent-complete figures.** Nobody consults them to decide what to pull, and they are wrong within days of being written. - **Fields maintained for a report the team never reads.** If the only reader is outside the team, keep the report outside the card. - **Long checklists** that make the card unreadable. If an item has ten mandatory sub-steps, that is a rule for the column, not text on the card. - **Duplicate detail** already held behind the link. Two copies means one of them is wrong and no reader knows which. The rule behind all four is that **every field is a manual promise**. Somebody keeps it true by hand, forever. One stale field is worse than a missing one, because a reader who catches a lie starts discounting the fields that are accurate. ## A worked example A four-person farm-equipment telematics team ran a board whose cards carried nine fields, including an estimate in hours, a priority number and a percent-complete. During the week the release was being lined up for an annual industry conference, two cards showed 80 per cent for eleven straight days, and one blocked card had no date on it at all: it had been waiting fourteen days for a spare test rig, and everybody assumed somebody else was chasing it. They cut the card face to five things - title, identifier, owner, start date, and a blocked marker carrying a reason and a date. Nothing about the work changed, but the board began to be read again, because everything on it was something a person would notice was wrong. ## Physical cards and cards on a screen A physical card is limited by the size of the paper, and that limit is a feature: it forces the team to choose what matters. A card on a screen has no such limit, so the team has to impose one deliberately - decide what shows on the card face, and let everything else stay one click away, unshown. The same discipline applies to colour and markers. Colour should **mean** something agreed - a class of work, an item type - and mean the same thing on every card. Colour used decoratively trains people to ignore it, and then the one time it carries information they miss it.
- A team makes six extra fields mandatory on every card. What goes wrong?Each field is a promise somebody keeps true by hand. The ones nobody consults go stale first, and a reader who catches one lie starts discounting the accurate fields as well. Mandatory fields also add friction at the moment work is pulled, which is exactly the moment you want frictionless. Keep the card face small and put the rest behind the link.
- Why record the date a card entered the first activity column?It turns 'that one has been going a while' from somebody's impression into something printed on the card. A card whose start date is far older than its neighbours is visible to anyone reading the board, including people who were not in the room when it started. It is set once and never edited, so unlike most fields it costs nothing to keep true.
- What should colour mean on a card?Something agreed and consistent - a class of work or an item type - applied the same way on every card. Colour used decoratively trains readers to ignore it, and then the one time it carries meaning they miss it. If the team cannot say in one sentence what a colour means, it does not belong on the board.
A card is the tag on a job at a repair counter: enough to identify the work and see it waiting, with the paperwork filed somewhere else.
saying these in an interview costs you the question
- Treats the card as the requirements document
- Leaves blocked work unmarked and relies on memory
- Adds fields nobody updates, so the board goes stale
- Uses colour decoratively with no agreed meaning
- Leaves in-progress cards with no owner named
- Marks a card blocked without a reason or a start date