Todo, Doing, Done

31st August 2026 · Matteo Merola

As an Engineering Manager, I have spent an embarrassing number of hours in rooms (and calls) where a group of smart, well-paid people argued about whether a ticket was really done, or whether the next sprint should last two weeks or three. Not once did any of those discussions ship anything.

Scrum, Kanban and the whole agile family have permeated the business world over the last years, steered especially by large organizations that needed a common language to coordinate thousands of people. For a while it was beneficial: it gave teams a vocabulary, it made work visible, and it killed (some of) the waterfall madness. But it also produced a nasty side effect that nobody likes to talk about: an enormous amount of time wasted in senseless ceremonies.

Process for the sake of process

I have seen many teams mandated to use Jira board templates so complicated that onboarding a new engineer meant onboarding them to the board before onboarding them to the codebase. Three-week sprints, custom workflows with eight statuses, mandatory story points, epics nested in initiatives nested in themes, and whatnot.

In many of these cases the kind of work was inherently not estimable. Research, platform migrations, incident-driven work, anything where the unknowns outnumber the knowns: you can put a number on it, but the number is a guess dressed up as a commitment. Worse, the organization itself was often badly designed, with interdependencies all across the board. Team A could not finish anything without team B, which was waiting on team C. In such a setup neither Scrum nor Kanban can work efficiently, no matter how disciplined the ceremonies are. The process was not the problem, and it was not the solution either.

The old but good way

If you strip away the vocabulary, a tracking tool serves one purpose: making sure the pace of work is sustainable. This comes straight from Andy Grove’s playbook in High Output Management, and it is embarrassingly simple.

Measure two things:

  • the rate of work that gets done – shipped, in production, fully finalized, nothing left to do;
  • the rate of work that gets added – new things that need doing, wherever they come from.

Make sure the former is higher than the latter. That’s it. If it’s not, you have a problem: work accumulates and doesn’t get done, and no amount of retrospectives is going to fix that. When this happens you only have two choices:

  1. Increase the rate of work done. Careful here, there’s a hidden tax. The Mythical Man-Month taught us fifty years ago that adding people to a late project makes it later. Throughput does not scale linearly with headcount, and every extra person adds communication overhead.
  2. Reduce the rate of work added. This is the unpopular one, and the one that actually works. Less is more. A lower volume of higher quality work pays off every single time, both for the business and for the sanity of the team.

In other words: if you or your team spend huge amounts of time arguing about the definition of done, whether 2, 3 or 4 weeks is the best sprint length, what to include in the next sprint, or what the sprint goal even is, reconsider. Cut it to zero. Cut the bullshit. None of those questions moves the needle on the only two numbers that matter.

What actually brings value

So what does a tracking tool need to give you? What is a meaningful transition for a work item? In my experience, you need visibility on five things and five things only:

  • What – what everyone is working on, right now.
  • When – a due date, a timeline, a roadmap. Something.
  • How – the list of things that will be done. It doesn’t need to be complete, as long as there is a single assignee fully responsible for completing it.
  • Why – how this piece of work fits into the bigger strategic discussion.
  • Who – a single assignee, one person responsible for it. Not a squad, not a pair, one name.

Given this, there are exactly two transitions worth sharing. When a piece of work goes from todo to in progress, that’s meaningful: somebody has started, and others can plan around it. When it goes from in progress to done, that’s even more meaningful. That’s the key event, the one that feeds the rate you are measuring.

All the rest (“in review”, “blocked”, “ready for QA”, “waiting for deployment”) is not so meaningful for anybody but the assignee. If you want to know more about a work item, contact the assignee. There is a name on it for a reason.

Communication does the heavy lifting

Why do some teams get away with a dead simple board while others drown in process? Communication plays a massive role. Teams and organizations that communicate well suffer much less from this, because the board is not their only source of truth: people are.

The ideal communication setup I strive for looks like this:

  • Each team has an open channel where they discuss all matters. Anybody in the organization can join, read and ask. There’s nothing to hide.
  • DMs and 1-to-1 conversations are limited to the bare minimum. Everything that can be discussed in the open, is. Transparency and engagement follow naturally: people learn by reading along, and decisions don’t get lost in somebody’s inbox.
  • Written, asynchronous communication over synchronous meetings. It’s much more efficient, it leaves a trail, and it respects everyone’s focus time (I wrote about this in Write things down).
  • Document only when needed, no more. A document nobody reads is a cost, not an asset.

When these are in place, the daily standup, the refinement and the sprint planning mostly become redundant. The information is already flowing.

Three columns

Most teams can thrive with a much simpler setup than today’s complicated Jira board templates. All you need is three columns: todo, doing, done. One assignee per card, a due date when it matters, a link to the why. Measure what comes in, measure what goes out, keep the second higher than the first.

That’s mostly it. Everything else is ceremony.