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?
  • 1
    What creates value in your organization? Strictly enforcing WIP limits, or getting work done? WIP limits are there to signal that you're probably wasting time due to context switching or excessive buffering. If working on D/E is the best use of your developer's time, they should do it. Of course, if by doing so they would create pressure in a later stage, it's probably better to finish items there, but this depends on the full context. Feb 5, 2020 at 15:43

2 Answers 2


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.


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.

  • 1
    Perhaps we should also "re-visit the WIP limit" to avoid such situations. With best practices recommending to have the WIP limits below the number of team members, a higher number may result in multi-tasking which the team should avoid anyway. Feb 6, 2020 at 11:15
  • Absolutely agree. Feb 6, 2020 at 13:42

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.