From my understanding, in non-agile settings, the project manager is responsible for assigning work to individual team members, but in a (self-organized) Kanban team, team members do this when they have slack, in accordance with the team's capacity (WIP limit).


Our product/tech team doesn't have much experience in an agile environment, it is cross-functional, and we have a variety of projects, which may require input from the specialists (UI/UX designer, front-end developer, GIS specialist) that are on the team. Sometimes, entire projects can only be worked on by specific team members.

Hence the following questions (really 2 ways of looking at the same issue, IMHO):

1) As a PO, while planning the work, should I take into consideration who can work on the product backlog items (thereby "pre-assigning" work), or should I just sort them by priority (business value and other factors)?

2) As a team member, what should I do if I don't have the technical expertise to pull what's at the top of the "Ready to work" column into build if...

a) ... we haven't reached our WIP limit yet

b) ... we have reached our WIP limit

  • 2
    If you have multiple questions, you should ask them as multiple Questions.
    – Sarov
    Commented Mar 23, 2018 at 20:13
  • 2
    I believe it's the same issue looked at from 2 different perspectives. I thought of separating them but didn't think it was worth it in the end.
    – Balala
    Commented Mar 24, 2018 at 14:22
  • 2
    Also I'd be curious to hear from those who downvoted this question. Does it not belong here, is the wording unclear, or are they just having a bad day, etc.?
    – Balala
    Commented Mar 24, 2018 at 14:24

2 Answers 2


As @Daniel has already said, Kanban is not prescriptive - it asks you to start with what you today - and make incremental changes to your process to improve flow.

On a slightly different note, Agile teams with not too much experience initially have this issue of team members not being able to pull - or self-assign - work, because they are too used to being told what to do. Even in longer running Kanban teams, young/ new team members not used to Kanban have the same problem. In most cases, at least for some initial period of time, the team - the PO, the Scrum Master or the Engineering Manager - and the team member themselves will jointly decide in a standup meeting what work can be taken up by that team member. This can continue until such team members feel confident enough or empowered enough to pull work whenever they are ready to start on the next one.

Finally, it is the reality for many small and medium teams that specific people become experts in specific modules of a software they have built and maintain - or have specific technology skills such as front-end, backend database or some such skills. The PO and the team have no alternative but to wait for the right set of people to be available to work on tasks that need those skills.

As a Kanban-based dev shop, we do what you have outlined. We populate the Ready column with the next set of the highest priority/ business value items - and whenever the team members who are to (and can) work on those items become available, they will pull those items.

As for the team members who don't have skills to do the next set of items sitting in the Ready queue, whether your WIP Limit has been reached or not is a moot point. They just can't work on those tasks because they don't have the skills. They can either work on some intangible (class of service) work - such as some refactoring of code, perhaps documentation, or some such work - or ask the PO to identify something new they CAN do, since sitting idle is usually not an option. Here's a board design by class-of-service that you might consider -

Kanban Board by Class of Service

In the meantime, as a team, as @Daniel suggested, you have to work on cross-training of team members so you reduce your people-dependency to some extent, and enable more people to take on more kinds of work that they would typically not consider to be "their work".

  • Thanks for this great answer. I have a follow-up question: You said "They can [...] work on some intangible (class of service) work". We've been wondering what to do with those kinds of tasks, which include continuous improvement work, and non-urgent but important tasks, etc. Where do you store those tasks? Are they in a different board? From my perspective it would not be a good idea to leave them on the main Dev board, since they will likely only be worked on when people have time, and they may or may not have a clear completion date/point.
    – Balala
    Commented Mar 24, 2018 at 14:54
  • 1
    In our experience, a team should ideally have all of its work on a single board (unless they are doing work for different clients and also using the board to collaborate with the client - in which case each client’s work needs to be kept confidential. On a single Board, it’s best to use Kanban’s “class of service” concept to separate out urgent work (expedited), normal work (standard) and important but non- urgent work (intangible) in separate swim lanes of the same board. That way, they are able to visualize all work they have and be aware of it - and take it up when bandwidth allows. Commented Mar 25, 2018 at 17:02
  • 1
    Sorry - didn't mean to sound repetitive about the Class of Service concept. I have added an image to my answer to explain what I am describing. You might also be interested in reading our extensive Kanban Guide (digite.com/kanban) and this whitepaper on important factors to consider while designing your Kanban board (bit.ly/2IRJRbM). HTH. Commented Mar 25, 2018 at 17:39
  • OK, in that case would you take into consideration intangible work in your WIP limit(s)? Thanks for the 2 links, I'll check them out.
    – Balala
    Commented Mar 26, 2018 at 1:06
  • I’d say that given the nature of the work, the Intangible lane or columns won’t need a maximum WIP limit - since rarely will you have anyone taking on too much intangible work :) But at the individual level, you certainly want to make sure no more than 2-3 work items are assigned to any person at any time. So, you should definitely have person-level WIP limits to encourage people finahbwhat they have started before taking up anything new. Commented Mar 26, 2018 at 2:27

Kanban should be a pull system, so you should not assign work. However, one of the core principles of Kanban is to start with what you do today and make small incremental improvements. If today people pull the work they can do, then ok, start with that. However, another thing Kanban requires is that we manage and measure flow. This is what I commonly see teams discover almost immediately:

When you pull work based on what you can do rather than what needs to be done, you increase the lead time for valuable work you can't start on. Many teams also immediately discover that there is a pile of important work waiting on one or two people who know how to do it. If you see this and do not acknowledge it and make small moves to improve this area, then you aren't practicing Kanban. A lot of teams will skip this step and just start sorting the backlog by priority. In fact, almost all teams I've coached at least tried to do this. It is bending the rules a bit, but the benefit usually outweighs the damage and I've never once known of a team who got more benefit out of keeping their silos where there was more valuable work to do.

  • Great points. Prioritizing pulling what needs to be done first will hopefully highlight bottlenecks caused by scarce skill sets. Would you go so far as to say that people should strictly adhere to FIFO (first in, first out) when pulling work from Ready to build, or as long as it's in that column they can pull something they're able to work on?
    – Balala
    Commented Mar 24, 2018 at 15:02
  • 1
    FIFO is a common prioritization technique, but not the only one. Highest-value-first is also very common, or a more complicated sort of weighted shortest job first. Either way, most teams find it helpful to order the backlog with the most important work to do at the top. Once work is started though, there is usually a focus on minimizing cycle time, which means the really would rally around finishing something before moving on to the next thing. There are always exceptions of course.
    – Daniel
    Commented Mar 25, 2018 at 17:32
  • Thanks for the clarification. I guess I should have mentioned that whatever would make it to Ready to build would already have been prioritized according to the Highest-value first (or something like Mountain Goat Software's relative weighting tool). I was wondering specifically if I should encourage people to use FIFO from that point onwards. I was thinking that it would be useful to use FIFO as a base, and then allow for exceptions.
    – Balala
    Commented Mar 26, 2018 at 1:10

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.