2

Let's say we have a team consisting of a developer and a tester. And we have a Kanban board consisting of "Development(WIP=1)", "Testing(WIP=1)", "Done" columns.

When the developer has implemented a task he moves it to the "Testing" column.

Everything is OK so far.

But tester can also write new tests. Should he put this task in "Development" column?

If yes, then the tester can be working on two tasks at the same time despite the WIP = 1 (one task in "Development" column and one task in "Testing" column).

If no, then a Kanban board represents the division of a team into developers, testers etc, but not a team's workflow.

Improve this question
1
  • Columns represent state, not people or resources.
    – Todd A. Jacobs ♦
    Commented Dec 23, 2019 at 18:57

2 Answers 2

Reset to default
2

I think it is easier to answer your question if we separate out some of the topics.

First, the columns on the board, represent the workflow of items. So, if the steps for delivering an item are development and testing, then an item in the development column is under development and an item in the testing column is currently being tested. From a kanban board standpoint, what team member is doing the work is completely irrelevant.

Next, let's talk about WIP. If the WIP for both columns is 1, then there can never be more than one task in either column. This is good from a flow standpoint. Any bottlenecks or impediments will become immediately apparent. On the other hand, it is very inflexible. A long-running test would immediately block the system. However, there are other ways of applying WIP. For example, you could apply a WIP of 2 to the whole process, which would give you just a bit more flexibility.

Finally, you mention that when the developer is done developing, they would put the card in the testing column. This is a subtle thing, but this is incorrect. The card moves when the work on the next step starts, not when the current step finishes. It may seem like semantics, but it results in very different team behaviors.

Improve this answer
2
  • Thank you, but why is it irrelevant? Let's suppose that both WIPs are equal to 2. Let's further suppose that a developer works on one task, and a tester develops new test and tests two implemented tasks - the tester works on three tasks at once. It doesn't seem to be good. Instead it seems to be more reasonable to limit the number of tasks one person works on.
    – Chris Brettini
    Commented Dec 23, 2019 at 15:52
  • 1
    Sorry for the lack of clarity. It isn't irrelevant in the overall conversation of teamwork, but Kanban does not specifically disallow it. One of the core principles of Kanban is that you manage the work, not the people. So in Kanban, WIP limits on work don't have anything to do with which people do that work. However, it is of course still important that the team has healthy conversations about the work and it is expected that if someone is juggling many tasks, other team members will point out that they are the bottleneck and ask to help out.
    – Daniel
    Commented Dec 23, 2019 at 16:00
0

WIP limits are applied to tasks and not to people.

If you regard writing new tests as a development activity then it would contribute to the WIP for the development state.

If you regard writing new tests as a testing activity then it would contribute to the WIP for the testing state.

It doesn't matter what the skill set of the individual is (i.e. if they are a 'developer' or a 'tester').

The important point here is that it is up to the team to define what activities represent what states in the workflow.

Improve this answer
2
  • I thought Kanban forces us to finish our current tasks before taking new ones. So it sounds strange that WIP limits apply to tasks and not to people.
    – Chris Brettini
    Commented Dec 26, 2019 at 10:51
  • I think you may be combining two different concepts here. The first concept is if somebody has partially completed a task then switching to another task will come at a cost. We call this context switching and we try to keep it to a minimum. The second concept is WIP limits, which are applied to stages of a workflow. The idea with WIP limits is to avoid bottlenecks as this tends to reduce overall throughput of completed work. It is up to the team how and when they apply these two concepts to maximise throughput.
    – Barnaby Golden
    Commented Dec 26, 2019 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.