Iterative process modelling on a kanban board

Question

Kanban does assume a more-or-less linear flow. Most of the time this models software development quiet well: we crate a user story, we code it, we test it, and we deploy it. However, some internal stages are iterative in nature and thus not so obvious. Take this (simplistic) board:

||   Planning   ||  Development ||     Test     ||     Deploy   || Done ||
|| doing | done || doing | done || doing | done || doing | done ||      ||
||       |      ||       |      ||       |      ||       |      ||      ||

Let's focus on the Planning column. If this is where user stories are developed, clearly some sort of iteration is needed: write story, refine/conversation, improve story, customer feedback, etc ... These stages are not modelled on the board at all.

Let's focus on the Test column. Once a story (or task/whatnot) is being tested: some tests will pass, some will fail. Thus the story needs more work. Should it go back into the develop column? Stay in a special test/development? Should there be Test/Fail and Tests/Pass columns? Over complicating the board is not an optimal solution.

Should you model iterative processes using Kanban?

If so, how? If not, why not?

Answer 1

I think the purpose of a Kanban board is to very quickly display where is everything at this moment along with an easy way to move things from on area to another.

There are some details especially about the history or the path taken by a particular story. You may want a separate feature to your board that is more of a log a story.

Here are two stories that let's say they both started step #2 (Very first Development) at the same time. Example: Story "A"

1. Planning
2. Development
3. Testing
4. Development
5. Testing
6. Development

Example: Story "B"

1. Planning
2. Development

Both Story "A" and "B" are in Development, but there is clearly something different going on with both of these stories. Is story A being sent to testing too quickly or is it much more complicated? When another person gets involved with these delayed stories, the kanban board is only going to provide enough information to indicate they're still in development, but not show the details of the iteration between testing and development.

If this is a problem, you may need some other type of report. Unfortunately with a paper system, you'd need to track the date/time when stories are moved from one place to another. It may be more practical to just ask those involved,"How's it going?"

Answer 2

From what you're saying in both situations the work item is still going to be in the "Doing" column, there seem to be different stages of "Doing".

Perhaps if you want to track down to this fine level of detail you could have boards for each stage. So a planning board may look like:

|| Write Story  ||     Refine   || Customer Feedback ||
|| Doing | Done || Doing | Done || Doing | Done      ||

Then move your work items back and forth in these boards while leaving the high level ones in the doing column until the lower boards are complete?

Answer 3

Should you model iterative processes using Kanban?

If so, how? If not, why not?

What do you get out of modeling/tracking that? Unless development gets started on stories which aren't ready yet (never seen by customers, ambiguous, etc), you'd be solving a problem you don't have.

Practically: you don't need to track every single phase of coding (wrote tests, wrote API, wrote code, wrote more tests, local validation, pushed, CI in progress, CI results verified) because you expect whoever is in charge of the story to take care of that properly. Why not have the same kind of expectation on the PO?

Answer 4

There are two ways to deal with iterative processes on a KanBan board:

1. The progression over the columns on the board from left to right indicates the ideal flow of a task. If a task can't follow the ideal flow (for example, if the verification test failed), then the task's marker can be moved back to a column on the left, indicating that that stage of the process was not really completed.

2. For small-loop iterations, you can just make the granularity of the column such that the entire loop stays within that column. For example, the preparation of a story for implementation could be a single step in the process, regardless of how often you go back-and-forth with the customer.

With that in mind, I think your 'simplistic' board is already too complex. I would change it to

||          TO DO              ||                            DOING                   || DONE ||
||   Planning | Ready for      ||  Development | Ready for | Test | Tested | Deploy  ||      ||
||            | Implementation ||              | Test      |      |        |         ||      ||

Here, the 'Ready for XXX' and 'Tested' columns are buffers so that the different stages of development can work in relative isolation from each other. On this board, a task should not be moved to 'Ready for XXX' or 'Tested' until it can be picked up from that buffer by the next team. If, for example, a test fails, then that task should be moved back to 'Ready for Implementation' so it can be picked up again by the development team.