The Board Is a State Space

There is a recurring argument in teams using Kanban boards, and it runs roughly like this. Development declares a work item complete. QA picks it up. QA finds reason to question whether the item is ready. The work item is moved back to Development, and the team is left to debate whose process failed, whose handover was sloppy, whose standards need raising.

The argument is sincere, the frustration is real, and the conclusion is wrong. There is no backward movement. The work item did not return to Development, because the board does not show what the argument assumes it shows.

This essay is about what a Kanban board actually models, what it does not model, and why getting that distinction right dissolves the backflow argument before it can be had. The argument matters here because it is unusually persistent, unusually corrosive to team dynamics, and unusually traceable to a single conceptual confusion. Other arguments about flow, about feedback, about the linearity of boards, will keep for other essays. This one stands on its own.

obviously created by AI

What the board actually represents

A Kanban board is a representation of the state space of the work items flowing through a system. Each region of the board corresponds to a state. Each work item resides in exactly one state at a time. Movement of a work item between states is a state transition, and state transitions are governed by policies: the conditions under which a work item is permitted to leave one state and enter the next.

This is a precise claim, and it has formal grounding. The mathematics of state spaces and transitions is among the most worked-over territory in computer science and operations research. Finite-state machines, statecharts, Petri nets, workflow nets: these are different formalisms, but they share a foundational distinction that the board inherits whether we acknowledge it or not. They distinguish between the state of an object (what it is, where it is in its lifecycle) and the actions that operate on that object (what is done to move it from one state to another).

A state is a property of the work item. An action is something a person does. The two are not the same kind of thing, they do not live on the same plane, and confusing them produces exactly the dysfunctions this essay is about.

A board models the state space. It does not model the action space. The action space is what people are doing, which person is doing what, which skills are being applied, which roles are involved. None of that belongs on the board, because none of it is a property of the work item. It is a property of the team’s response to the work item, and the response is not the work item.

This is not a stylistic preference. It is a categorical distinction. Putting actions on the board is a category error, in the technical sense: it conflates two kinds of object that the underlying model treats as separate, and the conflation creates problems that no amount of practice discipline can clear up, because the problems are baked into the model.

A note on vocabulary, while we are being precise. The word column is convenient and visually accurate for most boards as they happen to be drawn, but it carries a table-like connotation that the underlying model does not share. A workflow is not a table. The board is a depiction of states and the transitions between them, which is a structure better described as a graph than a grid. The visual choice to lay states out as vertical regions is just that, a visual choice, and nothing in the model requires it. Where this essay refers to states, the reader can substitute the visual region of the board they happen to inhabit. The substitution is in the right direction; the reverse one is not.

What this means for the famous backflow

Return to the opening scene. The work item is in Verification. A finding has surfaced that calls its readiness into question. Common practice is to move the work item back to Development and call this a backflow.

There is no backflow. The work item does not move.

Consider what is actually happening. The item entered the Verification state because the policy governing the previous state’s exit was satisfied: the development work met the criteria for advancing out of that state, which is necessarily not the same as “the item is verified to be fit for release.” That second condition is precisely what the Verification state exists to establish. The item is now in Verification, and the work of Verification is in progress. That work is a co-production: it sometimes involves the people who specialise in testing, sometimes the people who specialise in implementation, sometimes both, sometimes others. The actions vary. The state does not. The item remains in Verification until the policy governing Verification’s exit is satisfied, which is when Verification has produced the outcome it is responsible for: a defensible claim that the item is fit to move on.

When teams move the work item “back” to Development, they are not modelling reality. They are modelling their own role assignments, projected onto a board that was never the right surface for that projection. The mental move runs roughly: “a developer needs to do something, therefore the item is in Development, therefore the work item belongs in the Development region of the board.” Each step in this chain is wrong. The item is in Verification because the Verification work is not complete. A developer doing something during Verification is not unusual; it is the ordinary case, because verifying non-trivial work routinely requires the people who built it. We do not move the item back to Refinement when QA has a question for the Product Owner. We do not move it back to Discovery when a developer needs to clarify intent. We accept, in those cases, that the item is in its current state and that the work of that state requires participation across the team. We should accept it for Verification too.

The reason we don’t, I think, has to do with how the activities behind these states actually work. “Developing” is a single state on the board because the activities inside it — designing, coding, refactoring, integrating, reviewing, debugging — do not decompose into a meaningful linear sequence of sub-states. They interleave. The same is true of “QA”: planning, executing, investigating, validating, regression-checking, all of these interleave rather than queue. Each activity-cluster stays a single coarse state on the board because no finer decomposition holds up. Other activity-clusters work differently. Forming a hypothesis, validating it, splitting it into deliverable units, specifying acceptance criteria: these are distinguishable activities that can meaningfully sit in sequence, because each produces what the next needs. Where activities decompose, finer states on the board are available; where they don’t, they aren’t. And once an activity-cluster is a single coarse state, it becomes natural for a single role to inhabit it. One role, one state. Developers develop, in Development. QA engineers do QA, in QA. The collapse is not a mistake anyone made; it is what happens when an undecomposable activity meets a board that prefers clean states. And from that arrangement, all the rest follows.

What follows for how to design a board

If a board models the state space of work items, then the design rules are not aesthetic choices. They are consequences.

States are named for the work item, not the activity. A state is a condition the work item is in. “Development” is not a state; it is what some people do for a living. “Build in progress” is a state, awkward as it sounds. “Ready for verification” is a state. “In verification” is a state. “Awaiting deployment” is a state. The grammatical hint is that states attach naturally to the item (“the item is in X”), whereas activities attach naturally to people (“a person is doing X”). When the label only completes the sentence about the person, the label is misnamed.

I am aware this is a battle that gets lost more often than won. Teams resist long labels, and they are not always wrong to. But the principle survives even where the labels compromise: the question to ask of every state on the board is whether its name describes the item or describes the worker. Labels that describe the worker are labels inviting the confusion this essay is about.

Roles do not appear on the board. Not as states, not as swimlanes, not as avatars permanently associated with regions. The team collaborates to produce value. People specialise, of course they specialise, but specialisation is a property of how the team chooses to deploy its capacity, not a property of the work item’s lifecycle. Worse, the boundaries that a role-structured board appears to depict are partly created by the depiction itself. A team handed a board that distinguishes “developer work” from “tester work” does not encounter a pre-existing division and visualise it; it encounters a visualisation and learns the division from it. The board is not neutral evidence of how the work is structured. It is one of the inputs shaping how the work comes to be structured, and the structure it teaches is one the team will then have to undo. The moment the board distinguishes roles structurally, it begins teaching everyone who looks at it that “this is the developer’s part and that is the tester’s part.” The instruction is wrong, and the wrongness compounds: it produces the identity-fusion that makes the backflow argument feel personal, the local optimisation that makes hand-offs adversarial, and the resistance to whole-team quality work that practitioners then have to overcome through culture work that should never have been necessary.

This is the design choice that costs the most to make and the most to defend, because it cuts against intuitions that organisations have been reinforcing for decades. But it is the design choice that most directly serves the system the board is meant to make visible.

Policies govern transitions, not occupancy. What permits an item to leave a state is a question with an answer. What is happening inside a state is, from the board’s point of view, none of the board’s business. The board cares about the boundary, not the interior. A policy that says “items leave Verification when the defined verification criteria are met” is doing the board’s work. A policy that says “items in Verification must be actively worked on by a tester at all times” is doing something else: it is attempting to regulate the action space through a model that does not represent the action space. That regulation may be a useful thing for the team to do, but it does not belong in the board’s policy set, and putting it there muddles the model.

State transitions are forward, or they are aborts. This is the formal consequence of treating the board as a state space, and it is the one that resolves the backflow argument cleanly. An item leaves a state by either advancing to the next legitimate state, or by being removed from the active flow altogether (cancelled, archived, returned to the backlog under a new identity). It does not return to a previous state, because previous states no longer exist for this item: they were satisfied, the item moved on, and what would be gained by re-entering them. If a finding emerges in Verification, the finding is information produced in the Verification state, and the item remains in Verification until that information has been acted on. The action might involve writing more code. The action does not change the state.

This sounds like a small linguistic adjustment, and it is. But the linguistic adjustment is doing real conceptual work. Teams that adopt it find that arguments about “whose fault the backflow was” simply have no place to land, because the premise of the argument has been removed. The work is in Verification. The team is working on it. There is no backflow to assign.¹

Where this argument lives, and where it does not

The argument so far is formal. It rests on a distinction that workflow modelling has been making explicit for decades, in territory rigorous enough that competing formalisms (Petri nets, statecharts, workflow nets) agree on the foundational move. The argument is robust against counter-claims of the “but in practice” variety, because the formalism is what makes the practice coherent in the first place. A team that operates under the state-space framing finds that practice questions resolve more readily, because the model gives them a place to stand.

What the argument is not robust against is identity. A practitioner who has spent fifteen years describing themselves as a developer, in an industry that has spent thirty years calling its boards “development boards,” does not experience “the item is in Verification” as a clean re-description. They experience it as a small loss: of legibility, of authorship, of the region of the board they had come to think of as theirs. That loss is real, and no amount of formal argument will pre-empt it. The argument in this essay is a design argument, addressed to people designing boards. It is not, by itself, a cultural intervention.

I think the design argument and the cultural intervention are usually run together, and that this is a mistake. The design argument is settleable: there is a right way to model a state space, and the boards we see in most organisations get it wrong in describable ways. The cultural intervention is harder and slower and lives in a different register: in how teams talk about their work, in what gets celebrated and what gets quietly tolerated, in whether quality is treated as a shared production or an audit imposed at the end. A well-designed board makes the cultural intervention easier, by giving it a model to align with. It does not perform the intervention. The intervention is its own work.

But the design argument is the foundation, and if the foundation is wrong, the intervention has nothing to stand on. A board that codifies “my step” into its very structure is not neutral with respect to the culture it sits inside. It is teaching the culture, every day, that the work is a relay and the runner with the baton is the one responsible for what happens next. The board is doing the wrong teaching, and the team is then asked to overcome the teaching through culture work. This is harder than redesigning the board.

A closing note

The state-space framing is not a new idea. It has been available, in various forms, for as long as software has been formally modelled at all. What is new, if anything, is the suggestion that it applies to the boards on the wall as much as to the diagrams in the textbook: that the same distinction between state and action that disciplines a formal workflow model should discipline the artefact a team uses to coordinate its actual work.

The board is a model. Like all models, it represents some things and not others. What it represents is the state space of the work. What it does not represent, and should not be made to represent, is the action space of the people. Confusing the two produces backflows that are not backflows, arguments that are not really about the practice, and identities that fuse to a region of the board and then defend that region against the system they were meant to serve.

The fix is not technique. It is precision about what the artefact is for.

¹ The state-space framing also keeps flow metrics conceptually tidy. Once items only ever advance or leave the flow, questions like “what counts as the cycle time when an item appears to re-enter a state” simply don’t arise. Mature tooling handles these cases in practice; teams rarely notice. But the model and the measurement agree, which is one less thing to think about.