July flash sale
Jira can display a Kanban board without giving a team a Kanban system. Columns, filters and automation are implementation choices. KMP 1 starts earlier: What service are we managing? What demand arrives? Where do we commit? Which risks need different treatment? What policies control starting and finishing? Tool configuration should express those answers, not invent them.
KMP 1 Kanban System Design training is valuable for Jira teams that have customised the board repeatedly while lead time, hidden queues and interruptions remain unchanged. The course helps separate a service-design problem from a screen-layout problem.
Do this thinking outside Jira first
- Name the service and the customers or stakeholders it serves.
- Study demand, capability and sources of dissatisfaction.
- Map the real workflow, including waiting, rework and blocked states.
- Identify work-item types and risk that require different treatment.
- Choose initial WIP, pull and explicit policies as hypotheses.
- Decide which feedback and flow evidence will help the system evolve.
Then map design decisions to Jira carefully
| System decision | Possible Jira expression | Configuration trap |
|---|---|---|
| Workflow state | Status and board column | Creating a status for every minor action |
| Work-item type | Issue type or field | Using issue types that reflect documents, not demand |
| WIP policy | Column constraint plus working agreement | Treating a visual warning as enforcement |
| Blocked work | Flag plus blocked reason | Removing blocked items from the board |
| Commitment point | Agreed status transition | Assuming backlog entry means commitment |
| Flow evidence | Control chart, CFD or exported data | Reporting averages without distributions or context |
Keep policies readable outside the tool
If only the Jira administrator understands the workflow, the policy is not explicit to the people using it. Write entry, pull, exit, expedite and blocked-work rules in plain language. Link the rules from the board and review them when reality changes.
Avoid turning WIP limits into permissions
A Jira column limit can signal that the system exceeds an agreed condition. It should trigger a conversation about finishing, helping, blockage or policy. Automatically preventing every move may create hidden work in comments, documents or another project. The behavioural agreement matters more than the red column.
Use data without pretending Jira contains the whole service
Requests may wait in email, discovery tools, approval systems or release queues before and after Jira. Decide whether the service boundary requires that waiting to be represented or measured. A clean Jira chart can still omit most customer lead time.
Include the Jira administrator without handing over the design
Administrators can explain workflow constraints, fields, automation and reporting options. Service participants must still own the operating policies. A technically elegant configuration can fail when it encodes decisions the team never made. Agree the design in plain language, let the administrator propose the smallest implementation, and test whether people can use it without a private map of Jira internals.
A practical outcome for the first month
Change one design element with a stated reason and review date. For example, expose review waiting and add a pull policy before adding automation. Observe age, behaviour and unintended effects. KSD supports evolutionary change; it does not require rebuilding every workflow immediately.
Use the Kanban board design mistakes guide and WIP limits in KSD before reconfiguring the project.
