When is work done?
Ever seen a Kanban board with 26 columns, or was is 22? I can’t remember. Half of them were queues anyway. (And here is a video of the full board.) How does a board get so big? Well…
After two blogs on flow and board design (It’s the workflow, stupid; When workflow isn’t column, column, column) I received a question on LinkedIn. It might not at first look like a question about workflow and board design but once you read the answer you will see how it is:
“I am writing our company’s “release process”. It is triggering quite a few confused debates internally. Some people think that the release process starts with the definition of release goals/KPIs, moves onto ideation, prioritisation, all the way to getting feedback after customer deployment. Others think it starts with a “release candidate of the product is available and finishes when the final release is given to customers. I was wondering your thoughts on the topic. Between the two “extremes”, where would you draw the lines?”
I recognise this issue and in a way both sides are right. Although such questions normally appears in the context of writing a “definition of done” or a “definition of ready” it is really question of “where does work begin?” and “where does work end?” As such it is a workflow question and this a question of “where does our board start tracking work and where does it end?”
To put it another way, the question is: where do you place the boundaries?
Wherever you put the boundaries, someone can say “but you need to look at the bigger picture.” There is always something before the first step and something after the last step. On a Kanban board you can always add a column to the left and one to the right.
If the left most, work intake column, is “To do” then it is probably a sprint backlog and therefore there could be a column left of it marked “Product Backlog.” And since backlogs are driven by company strategy and product goals there could be a column before that. And goals are set reference to things like the market and company purpose and so there might be a column before that. You see, the workflow expands to the left?
Similarly, most teams consider “Done” to be the right most column, the final step in workflow. But really when they say done they mean “Code and test complete” so there should be a release step after that. And just because it is released doesn’t mean customers are using it so we could have “In use”. And then we should evaluate the usage, see if it meets the need and delivers the expected benefits so there is another column. But then, what if it doesn’t meet the need? Or what if it is so good it opens up new ideas? Before you know it you have a circular pattern.
(Maybe you see why some teams talk about Done and Done-Done, and even Done-Done-Done, and who knows …
Now this may start to sound like a philosophical problem – how many user stories can you fit on the head of a needle? – and it sort of is. What is done for your team?
Ultimately you need to put boundaries somewhere so the question is less “where should we start and end our process?” and more “what does the organization expect of the team?” Or you might prefer to think of it as “what do customers expect?”
You might also ask the team “Where does our work begin?” The answer to this question is going to depend both on the skills on your team and what team members think they should be doing. And that in turn will depend on the culture of the organization – are you a tailor or an image consultant?
So draw the line. Set your boundaries, codify them in release procedures and your board design. Then revisit those decisions in a few months time. Once teams are seen to perform well inside their “box” they get more leverage to expand the box and ask questions which expand the box. Which is all another reason why To do, In Progress and Done might not be the right board layout.