6

I do understand that the concept of the Work In Progress (WIP) of a column counts for both, the "in progress" and the "done"-subcolumn to keep the flow stable and force the team to identify and solve bottlenecks.

We have an interdisciplinary team where most people can work in most of the available columns. We have an overall WIP for the board and WIP-Limits for each column.

I got a question which I could not find an answer for anywhere: Do you keep people assigned to a task when it enters the done column? If you do so, the columns WIP-Limits match the overall WIP. Sounds logical.

On the other hand, if people stay assigned to a done task, they cannot be assigned to another column where they could potentially help while actually having time to do so. If I unassign them from a done task and assign them to another tasks while respecting the overall limit of the board, then we would have other people being idle, because less people would fill up the overall WIP-Limit than are actually available.

How do you do it?

Sarov
  • 14,768
  • 5
  • 33
  • 62
Dennis
  • 61
  • 1
  • I believe I haven't understood the idea on the 'done-subcolumn', would you mind adding a bit more detail on it? Assuming we have the standard to-do | in-progress | done columns, why would one have WIP applied to the 'Done', if the idea is to have as much items 'Done' as possible? Besides, the 'work in progress' limit, as the name says... should apply for the work in progress, not for the work completed, right? – Tiago Cardoso Apr 12 '17 at 22:54
  • 1
    @TiagoCardoso A common practice is to have something along the lines of: "TODO | Development Started | Development Done | QA Started | QA Done | Documentation | Ready to Ship" with certain columns (ie. Dev started/Done, QA started/done) sharing a WIP limit between them. – Sarov Apr 13 '17 at 00:51
  • Got it, thanks @Sarov. Assuming that the same team is doing both Dev / QA, then the 'Dev Done' could also be interpreted as 'Ready for QA'. They mean the same, without the idea of 'Done' in interim states. Is that the case? – Tiago Cardoso Apr 13 '17 at 07:43
  • 1
    @TiagoCardoso Yes, aside from the situation where you might not need QA for that particular issue, in which case it would be 'Ready for Documentation'. That is the reason why 'Dev Done' is used instead of 'Ready for QA', I think. – Sarov Apr 13 '17 at 12:32
  • Exactly... in this sense, the only 'done' we'd have would be the final done.. all other 'interim' dones are actually 'ready for' the next stage. I'm bothering with these details just because I believe that's a really good question which is 'not optimally' phrased and thus won't be helping as much people as it could. – Tiago Cardoso Apr 13 '17 at 12:48

1 Answers1

2

Kanban Work In Progress (WIP) limits are for the Team.

Whether or not someone is assigned to a task should have no bearing whatsoever as far as any WIP limits are concerned. If your WIP limit for development is 3 issues, and you have two issues in 'Dev Done' for developer A and one issue in 'Dev Started' for developer B, then no one, not even developer C, can start development work on a new issue. This does not change if the two issues in 'Dev Done' are unassigned.

That being said, to answer your question: what my team currently does is remove the assignee from issues that are 'done' (whether that's Dev Done or QA Done). This indicates that no one is currently working on that issue. If we, for whatever reason, need to find out who worked on an issue, then the system we use (JIRA) allows us to look at the issue's history and view who had previously been assigned to that issue. That being said, it doesn't really matter; as long as everyone understands what an assignee (or lack thereof) on a 'done' task means, and everyone consistently follows that, then there shouldn't be a problem. My suggestion: ask your Team, do what they prefer.

if we remove people from done tasks, and make them work in another column, for example the design column which has still 2 free slots (so the system is not stuck yet)

Not all teams will have all individuals able to perform all tasks. In general, once a column (or multiple related columns) have reached their WIP limit and someone wants to put more in, rather than just automatically shifting to something else, the person wanting to put more in should look at the board to identify the roadblock and attempt to help fix it. Just because there is 'room' somewhere on the board doesn't mean you can/should ignore that you have a roadblock.

Likewise, teams should always try to work towards the right-most side of the board whenever possible. The idea is not to make sure everyone always has work to do (optimizing for utilization). The goal is to make sure issues reach 'Done' as soon as possible, or in other words, to reduce lead time (optimizing for flow).

Also:

If I deassign them from a done task and assign them to another tasks

Kanban only works as a Pull system. Not as a Push system. You do NOT assign tasks to developers, nor unassign them from developers. Developers assign tasks to themselves. Removing Kanban's self-organizing team structure rips out a large part of the benefit of Kanban, and of Agile in general.

Sarov
  • 14,768
  • 5
  • 33
  • 62
  • Hi, thx for the quick answer. We assign tasks together in our standup. When I'm talking of me than that's not because I push tasks, but more due to my poor English. – Dennis Apr 12 '17 at 18:08
  • I read that the WIP of all columns should equal the overall WIP of the team/board, if we remove people from done tasks, and make them work in another column, for example the design column which has still 2 free slots (so the system is not stuck yet), then we would have 2 idle slots. Or we would have more cards in the system than the overall WIP due to the Done columns. – Dennis Apr 12 '17 at 18:17
  • See my updated answer for response. – Sarov Apr 12 '17 at 20:00