Field Notes: Workflow Principles

Developers and designers each had four tickets in progress at the same time - and by “in progress,” I mean actually in progress: including tickets in review and tickets in testing.

That’s a direct violation of one of the most basic Kanban principles: limit work in progress.

The symptom is always the same. The board looks busy. Nothing ships. Everyone is “almost done” with something. Standups turn into a list of things waiting on someone else.

So we wrote down the principles the team should work by - optimized for flow and outcomes, not activity.

End-to-end ownership ¶

Every ticket has one clear owner who is responsible for driving it from start to Ready for Release. Ownership does not end with development.

Finish over start ¶

We prioritize finishing work over starting new work. A ticket is only considered done when it is releasable.

Limit work in progress (WIP) ¶

We keep the number of active tickets per person low to ensure focus, fast feedback, and high quality.

WIP is everything that is not “Ready for Release” ¶

Any ticket that is not yet ready for release counts as work in progress - including tickets in development, review, or testing.

No passive waiting ¶

If a ticket depends on others (e.g. review or testing), the owner actively drives progress by following up, coordinating, or collaborating.

Shared responsibility, clear accountability ¶

While review and testing involve multiple people, the owner remains accountable for moving the ticket forward.

Fast feedback loops ¶

Code reviews and testing are treated as high priority to avoid delays and keep work flowing.

Transparency over status ¶

The board reflects the real state of work. There is no hidden or “invisible” progress.