Kanban
Make work visible and manage flow rather than only starting more tasks.
The idea
Kanban-style working visualizes stages, limits work in progress, and improves flow through a defined process. Teams examine bottlenecks, blocked work, and completion patterns. A board is useful when states have clear meanings and the team acts on what it reveals. Work-in-progress limits encourage finishing and resolving constraints. Security operations and project work may use different policies and service expectations.
In practice
A vulnerability team limits simultaneous remediation tasks so owners finish validation before opening many more incomplete changes.
A common misunderstanding
A colorful task board is not enough; unmanaged queues and hidden blockers can still grow.
Check your understanding
Why limit work in progress?
Think it through: Too much concurrent work can increase delay, context switching, and the number of unfinished items.
Improve flow by limiting simultaneous work
A board makes work visible, but visibility alone does not improve flow. Work-in-progress limits encourage a team to finish and unblock existing items before starting more. The appropriate limit depends on the team's capacity and work type. A limit that is routinely ignored becomes decoration rather than a useful operating policy.
Define what each column means and when work can move. A review column might require a reproducible test result and an available reviewer, while done requires the agreed completion evidence. Measure elapsed time through the workflow and look at aging unfinished items. A large number of completed easy tasks can hide one important item that has been blocked for weeks.
A fictional security queue
A small team handles access-review findings. Its board shows many items in progress and few resolved. Investigation reveals that engineers start new findings while waiting for service-owner decisions. The team introduces a visible blocked state, limits active engineering work, and establishes a regular route for obtaining those decisions.
The improvement comes from changing the constraint and operating policy, not from choosing a prettier board. Urgent work may need an explicit service policy, but labeling every request urgent defeats the purpose. Track whether exceptions displace planned work and whether they indicate an unresolved underlying problem.
Examine a stalled item
Sketch a workflow for a fictional dependency-remediation queue. Mark the point where application-owner approval is required and choose a reasonable work-in-progress policy. Then describe what the team should do when that column reaches its limit. The response should involve finishing or unblocking work, not simply moving cards to another label so the limit appears satisfied.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
UK Government: Project Delivery Functional Standard