Is Your “Done” Column Lying to You? Rethinking What Done Means11 Aug 2026

When looking at a teamworking Kanban board - digital or physical - the last, “Done” column tends to be one of the most satisfying, even comforting, to view. A whole bunch of colorful cards stacked like trophies of the team's accomplishments makes progress feel tangible. But very often, if you spend a little time asking questions, you may discover something a little awkward: many of those done cards don’t represent truly finished work.

Yes, they’re technically completed: someone wrote the code, polished the design, ran the tests, completed the checklists. Yet the final work hasn’t reached the customer, hasn’t delivered value, or hasn’t been validated in the environment where it matters the most. In that case, the “Done” column may have become an illusion that presents progress but not outcomes.

Of course, the problem isn’t the board itself, it’s how the team defines and communicates what's done. Without absolute clarity, we risk tricking ourselves into believing we’re completing work faster than we truly are, while in reality, we’re only shuffling cards across process steps.

Let’s break down the different meanings behind done and explore how your team can make their board reflect reality instead of wishful thinking.

1. Technically done: The mirage of completion

Here's the most common interpretation of done: a developer closes a ticket after the code has been written, a designer moves a card to “Done” when the mockups are finalized, a tester marks the job as finished after the test case has run green.

It's all perfectly logical on the surface: the individual contributor has done their part, the card moved, and everyone can feel the progress happening.

But technically done is very fragile due to the implicit assumption that the rest of the system will flawlessly manage deployment, integration, compliance checks, sign-offs, and customer adoption. In reality, those steps usually introduce new blockers, in turn causing the supposedly finished work to bottleneck underneath the surface, outside of the board.

In this way, a team can accumulate invisible work-in-progress: items completed in isolation but waiting for packaging, integrating, release, or validation. It's the reason why managers sometimes feel blindsided when the process output doesn’t translate into business results; the team looks busy and productive, yet outcomes do not reach the customer.

Done-done: Functional, integrated & shippable

The done-done, or truly done expressions emerged in push back against the ambiguity of technically done. It means the work is not just completed in isolation but finished and integrated into the broader product or system.

For example, in software development, this definition could mean:

• The code was merged into the main branch.
• All automated tests have run successfully.
• The feature works OK in a staging environment.
• The documentation has been updated.
• No blockers remain for deployment in production.

In a design process, done-done would typically mean the designs are not only approved but also implemented, tested, and accessible within the core product.

This definition reduces the gap between team activity and process outcome, acknowledging that finishing one's personal part of the process won’t matter unless the work subject in its entirety is deliverable.

Still, even the strong done-done definition can mislead. It has the potential to stop short of what truly matters in Lean management: has the value been realized by the customer?

Value-delivered: The only done that counts

A software feature sitting in a staging environment, no matter how innovative and polished, creates exactly zero value. A brilliant marketing campaign draft has no impact until it goes live. The value-delivered flavor of done means that the work has crossed the boundary into your customer's reality.

Considering what is done at this level can be uncomfortable for teams, as it forces them to measure outcomes, not just outputs.

Value-delivered means:

• The feature has been deployed to the production environment.
• Your customers can use it.
• The problem the feature was to address has actually been solved, or customer feedback reveals it hasn’t.

In line with this understanding of done, it can no longer hide behind completion checklists. It confronts the real-life test: has the investment of time and resources produced an effect for customers?

That is the level of done that both executives and customers care about, and one that most boards fail to represent.

How are boards capable of lying?

The goal of implementing visual process boards is to create transparency. Ironically, when used without a high process overview-driven awareness, they are perfectly able to fuel a false sense of completeness. Here’s why:

• Overly simplistic workflows: A layout that jumps straight from “In Progress” to “Done” completely ignores the reality of deployment, testing, rework, and release.
• Conflated or missing definitions: Teams use done to mean different things. One person means “I wrote the code”, another means “It’s live in production”. Without an explicit agreement, a policy guiding what each stage represents, confusion reigns.
  
• Psychological relief: Moving a card to “Done” feels great. Team members may crave the dopamine hit, so they adopt the easiest possible definition of completeness.
• Pressure to illustrate progress: Leaders and stakeholders enjoy seeing new things reach “Done”. Consciously or not, many teams adapt their workflow to keep that column looking full and growing.

In each case, the result is a “Done” column that appears impressive but ignores uncertainty and incomplete value.

Making done transparent

To truly see when work is done, and done for good, it's necessary to design your board in a way that distinguishes the different layers.
Here are a few practical approaches:

Break done into multiple sub-columns, i.e.:

• Ready for review
• Integrated
• Released to production
• Value confirmed

Each step shows how far the work has truly progressed. Stakeholders can instantly learn whether a task is finished just locally or if it’s already impacting customers.

Use explicit definitions of done

Agree as a team on what done means at every stage. For complete clarity, write it down on the board itself. Example:

• “Ready for integration”: code merged, peer-reviewed, tests passed.
• “Released”: available in production.
• “Customer approved”: validated by customer feedback and/or metrics in terms of value delivery.

Track value separately

All Kanban boards show the flow of work, but it's not always possible for them to also illustrate value. Consider pairing the board with a separate view, centered around value alone: a metrics dashboard, feature adoption curves, customer outcomes, or feature scoring. Then, link each task card to the value hypothesis it’s supposed to meet.

Resist cosmetic wins

Train the team not to move cards to “Done” for the sake of progress appearance. If “released” is the true done definition, it's better to leave the card in limbo until it actually ships. Though it may feel demoralizing at first, this practice exposes bottlenecks and forces improvements in deployment and delivery processes.

The cultural shift behind redefining done

Carefully considering what done means isn’t only about workflow mechanics and the board's layout. It’s a cultural shift, requiring teams to:

• Take ownership of the entire lifecycle: Work isn’t complete when one team member's part is over; it’s complete when it delivers value across the board.
• Embrace outcome over output: The number of tasks completed is of less importance than whether those tasks solve real problems of your customers.
• Confront uncomfortable truths: A column full of done cards with little or no customer impact is, in fact, less meaningful than a handful of cards with verified, delivered value.

Adopting this mindset means resisting the allure of false productivity and replacing it with the much harder discipline of impact-driven work.

Rethink your “Done” column today

If your team's “Done” column looks suspiciously full, ask yourself:

Are these items usable by our customers right now?
Do we distinguish between a finished activity and value delivered?
Would our stakeholders get an accurate view of progress from this board, or would they get a comforting illusion?

A working Kanban board exposes the reality, rather than painting a pretty picture. Reality is usually messy to some degree: work stalls before it's released, designs get abandoned before they can make an impact. The point of relying on a Kanban board is to surface the truth, so the team can act on what matters.

Once you rethink what done means in your process, you stop chasing cosmetic advancement and start optimizing for real-life outcomes. Your “Done” column can stop lying and start telling a more powerful truth: whether what you work on is making a difference.