Kanban Planning Assessment

Every question on the Kanban Planning Assessment maps to a habit that separates teams whose work flows steadily from teams whose board is full, whose queues keep growing, and whose delivery dates are guesses. Below is a breakdown of each scored question: what it measures, why it matters, and concrete steps to improve if your team scored low.

Score Interpretation

How to read your total maturity score (0 to 100).

1 to 20: Struggling. The board is a status display, not a system. Work is assigned rather than pulled, WIP limits do not exist, and nobody can say how long an item usually takes.

21 to 40: Developing. Some Kanban practices are in place but they are not enforced. Limits are informal, flow metrics are anecdotal, and aging items sit in a column for weeks without anyone raising them.

41 to 60: Norming. The mechanics hold. The board is current, limits are documented, and the team meets on a rhythm. The next gains come from acting on what the metrics show instead of only reporting them.

61 to 80: Performing. Flow is managed on purpose. The team pulls work, respects limits most of the time, reviews aging items, and addresses bottlenecks. Tune classes of service and replenishment so priority and capacity stay honest.

81 to 100: Thriving. Kanban is a genuine advantage. Work enters on a predictable cadence, moves without stalling, and the team can forecast delivery from its own cycle time data rather than from optimism.

Team Size

What is the number of team members including the Scrum Master, Product Owner, and Tech Lead?

Why it matters: Team size sets the natural ceiling on how much work can be in flight at once. Six to nine people is the range where a single board still tells the truth and every item has a clear owner. Below six, one absence stalls an entire column and specialist knowledge concentrates in one person. Above twelve, the board fragments into parallel streams that share a queue but not a conversation, and WIP limits become impossible to set honestly.

To improve your score: If you are at thirteen or more, check whether you are really running two value streams on one board. Split them and give each its own board, its own limits, and its own flow metrics. If you are under six, confirm you have the skills to carry an item from start to done without handing it to another team, because every external handoff shows up later as queue time you cannot control.

Attendance

How many team members were in attendance?

Why it matters: Kanban planning is where the team decides what to pull next and who unblocks what. When half the team is missing, the people in the room make sequencing decisions for people who never heard the trade off, and the absent half quietly reorders their own work later. Partial attendance is also how bottlenecks stay invisible, because the person sitting in the constrained column is often the one who could not make it.

To improve your score: Track attendance for four sessions and look for the pattern rather than reacting to one bad week. If the same people miss every time, the session almost certainly collides with another standing commitment, so move it. Keep the session short enough that attending is easy, and open with the aging items so anyone who joins gets value in the first five minutes.

Tech Lead Presence

Was the Tech Lead present?

Why it matters: The Tech Lead is usually the person who can say whether an item is genuinely ready to pull or is waiting on an environment, a dependency, or a design decision nobody has made. Without that voice, the team pulls work that looks ready on the board and discovers the blocker two days later, at which point it is already occupying a WIP slot.

To improve your score: Make the Tech Lead a required attendee rather than an optional one, and name a backup so a single absence does not leave the technical view empty. Give them a specific job in the session: review the ready queue and call out anything with an unresolved technical unknown before it moves. If they genuinely cannot attend, have them mark risky items on the board beforehand so the team is not guessing.

Facilitation

Was the Scrum Master present and did they facilitate?

Why it matters: Someone has to keep the session focused on flow rather than on status. A Scrum Master who actively facilitates walks the board right to left, asks what is blocked, protects the WIP limits when someone wants to start one more thing, and makes sure the quiet voices get heard. When nobody facilitates, the meeting turns into a round of updates and the systemic problems never get named.

To improve your score: Give the Scrum Master explicit ownership of facilitation and a repeatable flow: review aging and blocked items first, then walk the board right to left, then replenish the ready queue only if capacity exists. If your Scrum Master is present but not facilitating, that is usually a role clarity problem worth a direct conversation. Name a backup facilitator in advance so the pattern survives vacations.

Cameras On

Were cameras on?

Why it matters: Flow problems surface through hesitation. Cameras are how a facilitator catches the pause before someone says an item is fine, or the look that says a blocker has been sitting longer than anyone admitted. Audio only sessions hide that, and silence gets recorded as agreement. Camera off sessions also make multitasking easy, and a distracted team will let an aging item pass without comment.

To improve your score: Set a team norm for cameras on during planning and explain the reason rather than just stating the rule. Keep the session short enough that being on camera is reasonable. If people consistently opt out, find out what is driving it, whether that is meeting load, home setup, or discomfort, and solve that instead of repeating the request. In person sessions satisfy this automatically.

Session Length

How long did the meeting last?

Why it matters: Thirty to sixty minutes is the range where a team can review aging work, address blockers, and replenish the queue with real attention. Under thirty minutes usually means the team skimmed the board and skipped the uncomfortable questions about what has been stuck. Past an hour usually means planning turned into design work or item by item status reporting, and attention drops long before the meeting ends.

To improve your score: Timebox the session to sixty minutes and give the board walk a firm limit. When one item consumes the timebox, that is data: it is too large or too ambiguous, so split it or take the discussion offline with only the people involved. Move technical design and root cause analysis into a separate working session rather than letting them absorb the whole meeting.

Backlog Readiness

Was the Backlog ready for the meeting?

Why it matters: Kanban planning assumes there is a set of understood options to choose from. If the backlog is not ready, the session becomes refinement under time pressure, and the team pulls work it has not sized, scoped, or questioned. That work then sits in progress far longer than expected, which is the single most common reason cycle time balloons without anyone noticing.

To improve your score: Give the Product Owner a standing expectation that the top of the queue is prepared before the session, with a clear outcome, acceptance criteria, and known dependencies. Hold a short separate refinement block rather than refining during planning. Keep a visible ready column with an explicit entry standard, and let the team decline to pull anything that does not meet it.

Product Owner Presence

Was the Product Owner present?

Why it matters: Sequencing is a value decision, and the Product Owner is the person accountable for it. Without them, the team either pulls in board order, which may be months stale, or pulls what feels most interesting. Both produce the same outcome: a stakeholder later asks why the important item did not move, and nobody in the room can answer.

To improve your score: Make Product Owner attendance non negotiable, and reschedule rather than replenish without decision authority. Ask them to state why the top items are on top so the team hears the trade off instead of just seeing a rank. If they are stretched across several teams, agree on a fixed slot and protect it, and give them a delegate with real authority for the rare miss.

WIP Limits Defined

Were the WIP limits defined?

Why it matters: A WIP limit is the mechanism that turns a board into a pull system. Without documented limits per stage, there is nothing to stop work from piling into development or review, and everything ends up started while nothing finishes. Informal limits that live in someone’s head fail exactly when they are needed most, which is when pressure arrives and everyone wants to start one more item.

To improve your score: Set an explicit numeric limit on every in progress column, including review and testing, and display it in the column header in your tool. Start from what the team actually runs today rather than an ideal number, then lower it deliberately once flow stabilizes. Write the limits down where the team and stakeholders can both see them, so the constraint is visible rather than a matter of opinion.

WIP Limit Adherence

How consistently did your team adhere to established WIP limits during daily work and planning activities?

Why it matters: Defining limits is easy, respecting them is where the benefit lives. A team that breaches its limits most of the time has a documented policy and a push system, and its cycle time will behave exactly as if no limits existed. Frequent breaches are also a signal worth reading: they usually mean the team is unblocking by starting something new instead of finishing what is stuck.

To improve your score: Make a breach visible and talk about it the same day rather than at the next planning session. Adopt one rule the team commits to out loud: when a column is at its limit, the next action is to help finish an item in that column, not to pull a new one. Count breaches for two weeks and review the count in planning. If the team breaches constantly for the same reason, the limit may be wrong, so adjust it on purpose rather than ignoring it in practice.

Classes of Service

Does the team define and use distinct Classes of Service (e.g., Standard, Expedite, Fixed Date, Intangible) to prioritize and manage work?

Why it matters: Without classes of service, every urgent request is negotiated from scratch and the loudest requester wins. Classes give the team an agreed policy for how different kinds of work are treated, so an expedite is a rare, bounded exception rather than a weekly event. Teams without them tend to treat everything as urgent, which means nothing is, and important but quiet work such as reliability or compliance never moves.

To improve your score: Define three or four classes with written policies covering how many can be in flight, how they are pulled, and who can invoke them. A common starting set is Standard pulled in queue order, Expedite limited to one at a time and allowed to break WIP limits, Fixed Date scheduled backward from the deadline, and Intangible pulled when capacity allows. Mark each card with its class using a color or tag so the policy is visible on the board, and review at planning how many expedites you used, because a rising count is a demand problem, not a team problem.

Flow Metrics

Were flow metrics tracked regularly?

Why it matters: Flow metrics are how a Kanban team replaces opinion with evidence. Cycle time, throughput, work in progress, and flow efficiency tell you whether changes are helping, and they let you answer delivery questions with a range instead of a guess. Teams that track nothing debate whether things feel faster. Teams that track but never review collect data that changes no decision.

To improve your score: Start with three metrics your tool can produce without extra work: cycle time per item, throughput per week, and current work in progress. Put a cumulative flow diagram and a cycle time scatterplot on screen at every planning session and spend five minutes on what changed. Use the eighty fifth percentile of your own cycle time as your standard answer to how long an item takes, and treat any item exceeding it as an exception to discuss.

Aging Work Items

Were the aging work items reviewed?

Why it matters: Aging work is the earliest warning a Kanban board gives you. An item that has been in progress far longer than your typical cycle time is either blocked, larger than anyone thought, or quietly abandoned, and every day it sits there it occupies a WIP slot the team needs. Reviewing aging items without acting on them is the more common failure, because the team names the problem every week and the item still does not move.

To improve your score: Add a work item age view or aging report and open every planning session with it, oldest first. For each aging item, force one of four outcomes in the moment: unblock it with a named owner and a date, split it so part can finish, hand it to someone with capacity, or close it. Set an age threshold based on your own cycle time data and treat crossing that line as an automatic trigger for the conversation.

Board Visibility

Was the backlog open and visible to all team members during the meeting, so items could be reviewed for sequencing?

Why it matters: If the board is not on the screen, the team is planning from memory and from whatever one person narrates. Nothing gets updated during the session, so decisions live in someone’s head and the board is stale again by the next day. A visible board also keeps sequencing honest, because everyone can see what sits above and below the item being discussed instead of trusting a summary.

To improve your score: Share the board at the start of every session and edit cards live as the team talks, moving, blocking, and reordering in the moment. Assign a scribe so decisions land on the card rather than in meeting notes. If your tool is too slow to work in live, fix that friction first, because it silently pushes the team back toward planning from memory.

Pull versus Push

To what extent did your team operate using a pull system (starting work only when capacity is available) versus a push system (work assigned regardless of capacity)?

Why it matters: Pull is the core mechanic of Kanban. When people pull work as capacity frees up, the system self regulates and queues stay short. When work is assigned regardless of capacity, individual queues form behind each person, those queues are invisible on the board, and cycle time grows for reasons nobody can see. Assignment also removes the team’s ability to swarm on the thing that is actually blocking delivery.

To improve your score: Stop pre assigning cards. Leave the ready queue in priority order and let the next available person take the top item they can do. Write a short pull policy that says what qualifies as available capacity and what to do when the top item needs a skill you lack. If a manager or lead is assigning work, name the reason directly, because it is usually either low trust or an unclear queue, and both are fixable.

Replenishment Cadence

Did your team maintain a consistent replenishment cadence for reviewing options and pulling new work?

Why it matters: Replenishment is the decision point where options become commitments, and a regular cadence is what makes that decision deliberate. Ad hoc replenishment, where the team scrambles only once the queue runs dry, produces rushed choices, unprepared work, and idle time while someone finds something to do. A steady cadence also gives the Product Owner a predictable moment to reprioritize, which reduces the number of interruptions between sessions.

To improve your score: Put replenishment on the calendar as a standing event, weekly for most teams, and defend it the way you would defend planning. Cap how many items you admit each cycle based on recent throughput rather than on how much is asked for. Keep the ready queue small, roughly one replenishment cycle of work, so options stay fresh. If you find yourself replenishing between sessions, treat that as a signal to look at your cadence length or your queue size rather than as normal practice.

Bottleneck Identification

Were bottlenecks identified and addressed?

Why it matters: Every system has a constraint, and throughput is set by that constraint alone. A team that never looks for its bottleneck optimizes the wrong stage and sees no improvement. Identifying a bottleneck and then not addressing it is worse in one respect: the team knows exactly where work is dying and has normalized it, which quietly teaches everyone that naming problems changes nothing.

To improve your score: Find the constraint by looking for the column where cards accumulate and where wait time is longest on your cumulative flow diagram. Then take one concrete action rather than a general commitment: lower the WIP limit upstream of it, cross train a second person into the constrained skill, split the stage so review and rework are separate, or automate the slowest manual step. Assign an owner and a date, and check the same metric at the next planning session to see whether it moved.

Team Goals

Did the team identify one or more goals?

Why it matters: Kanban has no sprint boundary, so without an explicit goal a team can move many cards and still deliver nothing anyone was waiting for. A shared goal gives the team a reason to sequence one item ahead of another and a basis for saying no. Goals set without full agreement are a weaker version of the same thing, because the people who did not agree will still make their own sequencing choices when pressure arrives.

To improve your score: Set one or two goals per replenishment cycle, stated as an outcome someone outside the team would recognize rather than as a list of cards. Check agreement out loud before closing the session and ask directly whether anyone sees a reason it will not hold. Post the goal at the top of the board and open the next session by asking whether the work in progress is actually serving it.