How to reconcile WIP limits with tasks done in parallel by one dev?

Question

Let's say we have five Stories, A, B, C, D, and E. However, while D and E are clearly separate business requirements and should be tested/documented separately, the technical requirements are related/similar, and so it would make sense for them to be worked on together at the same time by one person/pair.

Let's also assume that Stories A, B, and C are in-progress, and the Work In Progress (WIP) limit is 4. We also have a dev/pair that just finished working on something else and now wants to work on D/E.

What would be the best approach here?

1. Just take both D and E into in-progress, violating WIP limits
2. Take only D or E into in-progress, and thereby work less efficiently on them
3. Don't take either into in-progress, and instead help to get A, B, or C out of the way asap
4. Get one of the other devs to stop working on A, B, or C
5. Something I've missed?

Answer 1

I would say it really depends on the context - there are no "rules" that Kanban enforces - it is up to the team and the business stakeholders to decide. If it is happening on a regular basis, then, they should look at the WIP Limits and enforcement related policies to see if these need to change to accommodate this phenomenon.

For the example you have outlined, assuming that the team has got the story prioritization/ selection right, Stories A, B, and C are more important to finish first - and I would go with Option 3 to get them done faster than they would otherwise and get them out of the In-Progress column. Then, take up D and E.

If D and E have equal or more importance, then I would also look at Option 1 - violate WIP Limit this one time and get the available dev pair to work on them together. We ourselves track the reason why we choose to violate WIP Limits when we do - so that at each retrospective, we can do a Pareto analysis of why and how often do we violate WIP Limits and discuss whether something (WIP Limit values, replenishment policies, etc.) needs to change.

If respecting WIP Limits is critical, AND D and E have priority or higher Class of Service, then I would Block one of A, B or C and get D and E in, and work on them first. However, this would be my least desirable option. That doesn't mean it doesn't happen in our environment.

Answer 2

I just wanted to add a little to Mahesh's excellent answer.

As well as making value based decisions in this kind of situation it is also worth considering how to avoid the situation in the first place.

One aspect of team synchronisation is to think about the sequence in which the work will be done. There are many factors in this, including:

• Availability of staff (e.g. a team member with db experience is about to go on holiday)
• The relationship between development and testing (e.g. not overloading specialist testers)
• The size and nature of the work items
• The dependencies between work items (including where it makes sense to do work items together)

By talking about the work items often, perhaps at a daily stand-up or planning sessions, the team can improve the way they synchronise.

The team won't get things right every time, but by careful synchronisation they can avoid a lot of issues like the one you have raised.