Describe the initial columns for a new Kanban board and their purpose

What's really being asked

This question checks if you see a Kanban board as a living map of work flow rather than a static task list. Interviewers want to know whether you start simple and evolve based on actual bottlenecks, or whether you impose heavyweight process prematurely. At the senior level, they also listen for how you teach the team to visualize blockers, limit work in progress, and improve cycle time.

The full answer

A good answer hits four things in order. First, name four starter columns: Backlog, To Do, In Progress, and Done. Second, explain the purpose of each. Backlog holds unprioritized ideas or requests. To Do contains work the team has committed to starting. In Progress covers active work and is where you introduce a WIP limit to prevent multitasking. Done marks completed items that deliver value. Third, emphasize that columns should represent real state changes or handoffs in your specific workflow, so you do not add columns like Code Review or Testing until the team actually identifies them as distinct steps. Fourth, mention that the board is a team tool for spotting blockers and measuring flow metrics like cycle time and throughput, not just a reporting dashboard for managers.

The mistakes people make

Common wrong answers include listing Scrum-specific columns such as Sprint Backlog or In Sprint, which confuse Kanban with Scrum. Another red flag is proposing 6 or more columns upfront without team validation; this suggests a preference for process over people. Candidates also err by describing the board as a personal productivity tool rather than a shared visualization of system flow. Finally, omitting WIP limits or any discussion of how to spot bottlenecks signals a shallow understanding of Kanban principles.

What usually comes next

Interviewers often ask how you would introduce WIP limits and who sets them. They may ask what you do when work piles up in one column, or how you handle urgent unplanned work like production incidents. Another common follow-up is how you differentiate a Kanban board from a Scrum board, or how you measure improvement after the board is in place.

A concrete example

Imagine a platform team launching a new API. You start with four columns. During the first two weeks, cards sit in In Progress for days because every change requires a security review, but there is no place to visualize that wait. The team adds a Waiting for Review column between In Progress and Done, sets a WIP limit of 3 items there, and assigns a security champion to pull from that column daily. Cycle time drops by 30 percent in the next iteration because the bottleneck is now visible and managed.