I may oversimplify here but the way I look at flow I want to have as few steps as possible but at the same time I want to be able to say what is happening with a feature at every moment. And I mean meaningful parts of process here.

When I look at the board and see a feature at ‘ongoing testing’ station I know:
- testing has been started
- testing hasn’t been finished
- either some parts of feature haven’t yet been tested or there are bugs which haven’t yet been fixed

And yes, it adds value after all because ‘before’ a feature isn’t good, i.e. there are bugs in there, and ‘after’ it is good to deploy.

It is really hard for me to describe that way tagging, but it is easier with pre-production deployment which is a part of discussed stage. When I see a feature at this station I know it is deployed (or under deployment – we have no data whether there are ‘ongoing’ and ‘completed’ sub-columns) in pre-production environment and possibly basic sanity checks have been done.

In terms of adding value pre-production deployment is an ultimate test for production deployment which is crucial in systems which can’t have long outage (or can’t have outage at all). Before you aren’t sure whether deployment will go smooth and after you’re pretty sure it will.

However I could imagine doing test deployment during testing. It all really depends who does this (if these are separate teams it is a good idea to split columns), how much time it takes (if deployment is time-consuming you may want to know whether a team performs functional testing or test deployment) or if this is an important milestone for one of stakeholders (and you want to explicitly show it).

Anyway I wouldn’t tell there is a definition of ‘simple enough’ or ‘as simple as possible’ – it all comes down to team’s judgement in every specific case.

The reason it made me think of this post because considering something like tagging your source to be adding value is interesting to me. I’m not sure if tagging your source adds value or is secondary waste. It may indeed value if part of adding value is being able to track versions etc (typically this would satisfy a system administrator stakeholder).

How do you define value as simply as possible? If you start off with a value statement of ‘deliver software’, do you add terms such as ‘maintainable’ to it?

I’m not certain but I think its the first time I’ve read about a documentation column on a board.

But you stressed one crucial thing – it doesn’t really matter whether there is column or not. What is crucial here is how well people understand value stream – you nailed this one.

By the way, on the very beginning we didn’t have documentation as explicit stage in our process – it appeared because team preferred to see it this way.

My point is, you’ve got documentation as a column on your board. I.e., in your context, you specify documentation as a step in your value stream. I imagine the documentation step could be specified as part of the requirements for moving a card to a column on the right (i.e. a ‘done contract’) instead of as an explicit column. Having it as a column makes sense to me becuase it makes sense in terms of adding value.

This led me to ask the question, do people sometimes have criteria in their ‘done contracts’ that should rather be explicit columns in their board?

I guess this question becomes ‘how well do people understand their value stream?’

Development is completed when:
- code is written
- unit tests for the code are created
- developer performed set of manual tests and in all went good
- if something can’t be easily tested (i.e. integration interface) there is a testing tool (simulator or something) created

Bug is fixed when:
- fix is applied to specified version of the application; if we want to fix a bug in a couple of versions we submit a couple of bugs to our bug tracker
- unit test following reproduction scenario is created
- fix is retested by QA folks in one of official builds; we also have unofficial, quick, dirty builds but they don’t count here

Feature is tested when:
- there’s no known bugs or, in very special cases, we agree that version can be shipped with specific minor bug(s)
- all planned functional tests were performed
- whenever change or bug fix affects any part of the application, the affected part is fully retested

Feature is live when:
- version is deployed
- all sanity-check tests pass; these verify all basic fucntions of the app
- our customers can access the feature

Documentation is done when:
- our maintenance guy is happy with it

It would be hard to have each of these details having its own column on the board. We just collectively worked out the way we do our jobs.

The other thing is I believe the Kanban Board should have as little columns as possible but at the same time the board should reflect real workflow.

If we document our features and we do that after deployment and it takes significant time (up to a couple of days in some cases) there should be a column where a sticky note spends these two days.

If it happens, rarely but it happens, that a feature is at research and design stage for a week we add a column which shows it because that’s not really development since work isn’t progressing here in terms it is while the feature is in development.

But we don’t add deployment stage since it takes on average less than hour to deploy the app. We don’t move a feature between testing and bug fixing stages because these two happen in parallel and even if they didn’t we would need to move a sticky notes up to few times an hour which doesn’t make any sense.

It all depends on how you work. Consider the way of work as a hand and make Kanban Board a glove. It should just fit.

This also implies to me that to deliver value its not sufficient to just deploy a feature, but also to document it. This leads me to the question: ‘what else is required to provide value?’

Also, what is your opinion of including the documentation requirement as part of the ‘done is done’ contract for a specific column, perhaps dev or test (I’m not sure). Should certain requirements be part of ‘done’ contracts or have their own columns on the board? How do you distinguish between them?