Custom workflow definitions: Your process is lying to you

If your board says To Do / Doing / Done, your metrics are already compromised.
They are not just slightly off, and "good enough for now” is not good enough at all. Your metrics are actively misleading you.
And before you blame your tools, this isn't a tooling problem, it's a thinking problem.

Most organisations claim to be "data-driven" while collecting flow metrics from a workflow that bears only a passing resemblance to how work actually gets done. Then they act surprised when the numbers don't line up with reality.
When Kanban metrics fail, they don’t fail because the maths is hard but because the workflow is wrong.


Workflow definition comes before metrics

Kanban starts with a deceptively simple question: when does work start, and when is it finished?
If you can't answer that clearly, everything downstream becomes ambiguous.
Cycle time? From when, exactly? Age? Based on which state, what start date? WIP? Counting what, and where? Throughput? Finished by whose definition?
When teams argue endlessly about metrics, it's almost always because they skipped this step or started with something they thought is “good enough”.


Generic workflows hide everything inconvenient
To Do / Doing / Done is easy and it sure has its use but probably not in your complex context.
When the work requires a team or a few to be fully complete, it collapses waiting, rework, dependency delays, handoffs, review queues, and approval lag into a single comforting blur called "Doing".
From a flow perspective, that's catastrophic. You can't manage what you can't see, and you can't see anything meaningful when half of your process is hidden behind a single column.
I hear some say “but it’s miles better than what we had before” - sure, get some credit for the improvement but don’t stop there!


Your metrics are only as honest as your workflow

If your workflow definition is wrong, your metrics will faithfully report the wrong thing.
Cycle time might look fine because review delays aren't counted. Age might appear low because "started" is defined conveniently late. WIP might look controlled because queues don’t show on your board.
It’s easy to blame it on the organisational constraints, ancient processes and slow change. But when you design the workflow and if you hid waiting, dependencies, handoffs, etc then it’s doing exactly what you told it to do.


"Our process is too complex to visualise"

Ever heard this one? (also did you mean complicated?)
And no, it is not.
What you mean is: visualising it would be politically inconvenient, would expose uncomfortable truths, or would challenge existing accountability structures.
Most processes are not simple. Kanban doesn't require simplicity, it requires honesty.
A workflow definition isn't a documentation exercise. It's a declaration of how value actually flows, and it requires complete visibility of everything.


Start and finish are policy decisions

One of the most common workflow mistakes is treating "start" and "finish" as obvious.
But they often aren’t.
Does work start when it's requested? Or when someone picks it up? Or when analysis starts? Or when it's "ready for development"?
And then when is it finished? Code complete? Deployed? In production? Used by a customer? Paid for?
These are not semantic debates. They are policy choices that directly affect predictability and risk. If leadership hasn't explicitly agreed on these, metrics become political weapons instead of decision aids.


Most elapsed time is spent waiting

Another misleading signals some workflows tell is pretending work is always being worked on. That happens when your Doing state incorporates multiple activities and the handoffs between them.
The reality is that most time is spent waiting. Waiting for reviews, for decisions, for other teams, for clarification, for environments, for approvals, etc.
If your workflow doesn't make waiting visible, work item age will rise and no one will know why. What’s worse, people will blame it on execution instead of workflow design.


Custom doesn't mean complicated

A custom workflow doesn’t mean an inconveniently large number of steps.
The goal is not to model every micro-step, but to make flow-relevant delays explicit so that it reveals queues, highlights handoffs, exposes policy boundaries, and makes blocked states unambiguous.
Here is a simple test: if adding a column wouldn't change any conversation, you probably don't need it however if not having a column hides a recurring issue, then you definitely do.


Why leaders should care

The work teams produce lives inside workflows. Leaders can help design or influence the conditions around the workflow.
If the workflow hides decision delays, obscures dependency risk, or masks approval bottlenecks, that means leadership will repeatedly get the signals too late and may interfere in the wrong place or in the wrong way.
Better workflows shift conversations from "why is the work late?" to "why is work waiting here too often?”. The early signal makes all the difference. And that’s the difference between managing people and managing systems.


More metrics won't fix a bad workflow

This is what many organisations don’t get.
They try to compensate for poor workflow definition with more metrics, more charts, more dashboards, more reporting. All that does is waste effort and perhaps worse, increase confidence in bad data.
If your workflow doesn't reflect reality, improving metrics sophistication just helps you delay important decisions until it’s too late.


If your workflow hasn't changed, neither has your thinking

There is a signal sign worth mentioning.
If you struggle with delays, missed forecasts, escalated risks and your teams are frustrated then have a look at your workflow. Has it changed to try and improve the struggles?.
Kanban workflows are not meant to be static. They must evolve as understanding improves. If they don't, it usually means people stopped asking the difficult questions.
Don’t get me wrong, I know many organisations that avoid asking difficult questions and have been running like that for years. But is that what you signed up for? Is that the best you want to achieve?


Treat your workflow as a hypothesis

A workflow definition is not something you get perfect at the first guess. It's a hypothesis about how value flows.
Metrics exist to test that hypothesis. If the data doesn't match reality, don't argue with the data. Fix the workflow.

In the next post, we'll look at Blocked Item Visualisation and why treating blocked work as a footnote instead of a signal for action is one of the fastest ways to destroy flow without noticing.