The environment
A team of three runs a product that has been self-sustaining for years. The business model is contract-based, not SaaS. Customers arrive with requests that override whatever was planned. There is no roadmap. There is no sprint. There is no predictable sequence of work.
The visible problem was chaos. Tasks appeared without warning. Priorities shifted mid-execution. Status was unclear because work passed through multiple people and nobody knew where it stood. The team tried to plan, but every plan was invalidated by the next customer request.
The instinct was to fix the flow. Introduce sprints. Prioritize the backlog. Adopt a framework. But the environment rejected all of these. Sprint planning assumes a stable scope for a fixed period. Prioritization assumes the ranking will hold. Neither condition existed here.
The problem was the absence of a definition.
The undefined unit
The team operated with a task list. Tasks had names. Some had descriptions. None had a formal structure. A task could mean a customer bug, a new feature request, a technical debt item, or a multi-week initiative. All of these lived in the same list, moved through the same columns, and were treated as interchangeable units.
They were not interchangeable. A bug for one customer required one person for two hours. A new interaction pattern required three people across multiple stages over weeks. Both occupied the same row on the same board with the same status labels. The system had no way to distinguish them.
When the unit of work is undefined, every process built on top of it inherits the ambiguity. Status becomes meaningless because “In Progress” means something different for a two-hour fix and a three-week initiative. Ownership becomes unclear because nobody knows whether a task belongs to one person or passes through several. Progress becomes invisible because there is no shared model of what “done” requires.
A system cannot be governed if its atomic unit is undefined.
The entity model
The structural move was not to change the flow. It was to define the unit. I modeled the task as a formal entity with properties that served as governance rules, not metadata.
Type determined the structural category: a standalone task, a bug, a user story containing subtasks deliverable within an iteration, or an epic requiring decomposition across departments. The rule was simple. If the task required multiple departments, it was an epic. If it contained subtasks achievable in one cycle, it was a user story. If neither applied, it was a task or a bug. These were not labels. They were routing rules.
Priority established sequence, from Minor through Blocker. Not as a planning tool. As a triage instrument for an environment where interrupts were constant and the question was never “what do we do next month” but “what do we do now.”
Department declared ownership at the discipline level: Design, Coding, or both. This made visible what had previously been implicit: which discipline a task currently required, and when it transitioned to another.
Scope declared estimated duration at the moment of creation: hours, days, or weeks. Not as a commitment. As a sizing signal that determined whether a task could be executed as-is or had to be decomposed.
Component classified the task by functional category: bug, new feature, technical debt, improvement. This enabled clustering. The team could see how much of its capacity was consumed by reactive work versus structural investment.
No property was optional. A task without a type could not be routed. A task without a department had no owner. A task without scope could not be sized. The definition was the governance.
The state machine
Status columns followed from the entity definition, not from a methodology template. I defined six states, each with an entry condition.
To Do. The task was defined and its properties were set. If no assignee existed, the task was in the backlog by definition. No separate backlog column was needed. The distinction between planned and unplanned work was not a column. It was whether the task had an owner.
In Process. Work had begun. One constraint applied: no more than one task per person in this state. In a team of three where everyone handled both support and development, this was not an agile principle. It was a survival rule. Without the WIP limit, every interrupt created a context switch and no task reached completion.
In Review. The task required input from someone other than the executor. A stakeholder decision, a colleague’s assessment, internal testing. The task was not blocked. It was waiting for a specific input from a specific person.
Blocked. The task could not proceed. Missing information, dependency on another task, external factor. Different from In Review: Blocked meant no one could act. In Review meant someone specific had to act.
Waiting for Deploy. Completed, tested, ready for production. This existed as a separate state because deployment in a contract-based product was not continuous. It depended on customer schedules, release windows, and integration constraints.
Done. In production.
A status is not a column on a board. It is an entry condition. If the condition is not met, the transition is not valid. That is what separates a state machine from a to-do list.
The resolution layer
One structural problem remained. A task in “In Process” could mean requirements were being gathered, analysis was underway, or implementation had started. Three fundamentally different activities shared one status. The state machine resolved macro-transitions. It did not resolve what was happening inside a state.
I introduced a second layer: tags as sub-states within statuses.
In Process carried three possible tags: gather requirements, analyze, in progress. In Review carried: in waiting, in progress. Blocked carried: needs clarification, in waiting.
To Do and Done had no tags. A task that had not started had no internal state. A task that was finished had no internal state. Tags existed only where ambiguity existed.
This was a state machine inside a state machine. The outer layer governed flow across the board. The inner layer governed activity within a column. Neither layer alone was sufficient.
Visibility is not produced by adding resolution everywhere. It is produced by adding resolution at the point of ambiguity. Where the state is unambiguous, additional structure is noise.
The reduction
The first draft I proposed looked different. It included nine columns instead of six. It used ICE and MoSCoW for prioritization. It borrowed a lifecycle from Waterfall: six sequential phases from requirements through integration. It carried more structure than the environment could sustain.
I removed what the environment rejected. Prioritization frameworks were dropped. Not because prioritization was wrong, but because in an interrupt-driven context any ranking was invalidated by the next customer call. What remained was a simple priority field on the entity itself: enough to triage, not enough to pretend a plan existed.
The Waterfall lifecycle was absorbed into the tag system. Instead of six sequential phases as stages of the board, the activities became sub-states inside In Process. The sequence still existed. It was simply no longer a pipeline. It was internal to the task.
The reduction was the design. Every element that survived did so because removing it would make the system unreadable. Every element that was cut was cut because the environment would not enforce it.
A system that requires discipline the team cannot sustain is not a system. It is a wish.
The implementation constraint
The tool was YouTrack. Not because it was the best tool. Because it was the available tool. I implemented the entity model within YouTrack’s existing structures: types, priorities, departments, scopes, components, statuses, and tags. No custom development. No integration work.
This mattered because the constraint was not to design the ideal system. The constraint was to make the team’s work visible and governable with what already existed. The system was built from the environment inward, not from a methodology downward.
The outcome
The model held. The recurring need to ask where a task stood, who owned it, or what a status actually meant disappeared. Tasks stopped collapsing into a single undifferentiated queue. Ownership became explicit. Status became interpretable without additional conversation.
One cost remained: the team needed time to internalize the rules. For roughly six weeks, old habits persisted. People skipped properties, used familiar shortcuts, or placed tasks into states that did not match the entry conditions. The system did not enforce itself. It required deliberate use until the logic became routine.
After that period, the model no longer needed constant correction. The environment itself did not become predictable. Interrupts continued. Priorities still shifted. Customer requests still arrived without warning. But each new task entered a structure that could classify it, route it, and make its state legible.
The chaos did not disappear. It became readable.
The AI layer
AI can automate task routing. It can suggest priorities based on historical patterns. It can update statuses from commit messages or customer communications. It can generate requirement drafts from interview transcripts.
None of this works without the model.
If the system does not define what a task is, what types exist, what transitions are valid, or what ownership means, then AI automation produces faster movement through an undefined space. Tasks get routed, but the routing rules remain implicit. Statuses get updated, but the states have no entry conditions. Requirements get generated, but there is no structure to validate them against.
AI scales execution. It does not scale definition. In an ungovernable environment, the first investment is not automation. It is the model that makes automation meaningful.
The principle
When the flow cannot be controlled, when interrupts are constant, scope is unstable, and planning horizons do not exist, the response is not to force a framework onto the flow. It is to define the unit that moves through it. A governed unit in an ungoverned flow produces a legible system. An ungoverned unit in any flow produces noise.
The system is not in the board. It is in the entity.
This article is based on process design conducted within a contract-based product company. Specific organizational details are confidential.