[Jtsummers]

> DONE means DONE, if it needs QA, Documentation, install script, whatever, it stays in DOING until it's truly DONE.

Once you have this, you can expand the DOING with additional columns to represent those other stages.

If you implement a new (particularly user-facing) feature, you need to update your manuals. That may be a technical writer, it may be the developer or the tester, may be a team effort, doesn't matter really. So your columns (if this is a requirement for your business) become:

  | TODO | PROGRAM | UPDATE MANUAL | REVIEW | DONE

This is one of the nice things about kanban. It's very fluid, really nothing is set in stone. Allow the board to represent the real process as you discover it.

[memborg]

This is no different than agile. I have to define DONE. And I will probaly end of with several degrees of done

[Jtsummers]

To be clear, kanban cannot be directly compared to agile. Kanban is a tool, not a process, framework, or manifesto.

In all work, you have Done, and done. Capital-D done is when something is ready to be shipped (note: doesn't mean error free, just means it's as far as you're getting). Lower-d done is intermediate states. The kanban board allows you to capture those and relate it to your workforce and workload.

If I have 5 developers, practically speaking we cannot be working on more than 5 development tasks at a time. The kanban board visualizes how much we have going on and allows us to see when we've overreached. If I have 2 tech writers, again we can practically only work on up to two changes to the manual at a time. The kanban board visualizes this, and makes a useful tool within any production or development workflow.

Capital-D Done is that final column (integrated into the master branch, sitting on the loading dock, whatever). Lower-d done is captured by movement between states (Dev -> Test -> Review -> Manual Update -> Done). Of course, it also should be noted that movement can be backwards. This isn't Waterfall, we know that something may move back to dev or test from test or review.

The particular utility with agile is that it helps address the agile manifesto preference for people over processes. A process expressed on a kanban board is not set in stone (as a formally signed off Capital-P Process document would be in a typical enterprise shop). It's much more fluid, and can be redefined to capture the level of information needed by the team and those they work with (partner teams, or management).