12

One of our developers has gone on holiday with some tickets associated with them on the Kanban board.

We were faced with the following two options:

  1. Keep the work in progress limit the same for that team, and keep those tickets on the board, but not have them move until the developer returns.

  2. Park the tickets off the board, and reduce the work in progress limit for the duration of their holiday.

In the end we determined which tickets were needed by the respective project and reassigned some other tickets in that team's column. The decision above forced us into having those priority discussions, but I am interested in hearing how others deal with this kind of issue.

Improve this question

7 Answers 7

Reset to default
7

David Anderson suggests, "Make process policies explicit." Part of your process is that developers go away, leaving work unfinished and in progress. While the developer is on holiday, his/her knowledge will degrade, so the policy may not actually be a good one, but it's happening anyway!

Therefore, make that process policy explicit by leaving the work on the board. Now everyone can see that the policy may not be useful and address it. Parking the work off the board hides the implicit policy, so the team can't act to improve it.

I've not been faced with this particular situation, but in general I find it useful to make the board reflect reality rather than what we wish reality was.

Improve this answer
3

For my teams, we always leave the tickets on the board, and generally keep the WIP limit the same.

However, over time, the team has learned to be aware of when each other are planning vacations, and will usually work to ensure that an item can be handed off to someone else rather than the item being blocked by the vacation.

Obviously, this solution depends upon a lot of factors coming together.

Improve this answer
3

I would recommend combining it with Collective Code Ownership. And if you do it the best solution would be leave the tickets where they are.

If anyhow during the vacation you will reach the limit another person would have to continue the task started by the member who is already on vacation.

In fact if you read the Kanban board from right to left another team member should just take this task because it is already opened and is more to the right than another item in the todo column.

Improve this answer
1
  • +1 for your last point "In fact if you read the Kanban board from right to left another team member should just take this task because it is already opened and is more to the right than another item in the todo column."
    – CaffGeek
    Nov 23, 2011 at 20:30
2

I have seen this problem a couple of times. First of all I think it is good to address this in a retrospective to see how the team wants to deal with issues like this. You might already have done this though.

In teams I coached team members came up with the following solutions:

  • There is still plenty of time after his vacation: parked it in a buffer column. Kept the WIP limits (this one worked best when there was not much (or no) time preasure)
  • Made an exception to WIP limits. Clutters the board. Same effect as the previous one, but the board got much messier
  • (Team members had their own wip limits aswel) Lifted a personal limit. This didn't help that much because the person started multitasking

Since it is a team effort i would always prefer the team solved the problem without having to tamper with priorities. You can always use classes of service to determine if you can expedite them...

-Cheers!

Improve this answer
2

"Stuck" Tasks Belong on the Board

By definition, kanban is a pull model. If work is on the board, it is being pulled by some person or process. If the work sits on the board because it isn't being pulled through the swim-lanes, then the kanban card is doing its job by making that issue visible. The fact that it's due to someone being on vacation is irrelevant.

Don't Tamper with Visibility

If there's no one else to pull a kanban through the swim lanes, then that's a process problem that needs to be solved. If the kanban isn't actually critical enough to take up a work-in-progress slot, then it somewhat begs the question of why it's being tracked that way at all.

Kanbans should make work (and process bottlenecks) visible. Please think long and hard before treating a kanban card like a fungible unit that can be swept under the rug when its presence is embarrassing or inconvenient.

Think of it this way: if you're down a team member, replacing the card is effectively increasing your WIP limit. The work is still in-progress (e.g. pulled by some process, but not completed) regardless of whether it's physically on the board or not. Why would you want to make that fact invisible to the team or to management? (Hint: There's never a good reason for that, so please don't.)

Improve this answer
2

Have someone work together with the developer that is taking a vacation a week before he takes off. That way, the one that stays can continue work without any interruption. As a matter of fact, take a look at swarming and pair programming.

Improve this answer
1

Pair programming has aided my team in maintaining their velocity even during iterations where a developer/developers were ill for some of the time.

Plus, it helps with fighting knowledge silos.

I would keep the task on the board and the policies you have for ready for development should state that developer holidays have been considered.

Improve this answer

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.