Most agile teams of any appreciable maturity understand that limiting Work In Progress - or WIP as it is often abbreviated - is a good thing. The problem they often encounter is that it isn't always apparent who is working on what.
In theory, this is a problem that shouldn't happen. An agile team should be highly collaborative and it ought to be quite clear, to all team members at all times, what each other are working on. They are expected to have a shared goal and a joint purpose that makes collaborative awareness and teamwork essential, and this should make explicit mechanisms for tracking each other's work redundant.
Moreover, WIP should ideally be limited to one item in progress at a time, a pattern known as Single Piece Flow. Having multiple pieces of inventory on-hand is a form of waste, since each incurs a handling cost, and any work done on one of them will depreciate while another is being worked on.
In theory at least, restricting WIP to one item at a time will reduce this waste and get value out of the door as quickly as possible. If a team can achieve this practice it should be quite clear to all who is working on what. Everyone is working on the same thing in order to expedite its completion.
This principle of Single Piece Flow (SPF) is central to Lean-Kanban ways of working, especially in a manufacturing context. In a software context the accepted WIP limits tend to be rather higher than one. It is often limited to one item per developer, such as by allowing each developer an "avatar" to place on an item. An avatar is a symbol which represents that person and shows what they are doing. Cartoon characters are popular.
It's important to recognize that when an avatar is placed on an item, it merely indicates who is actioning it at that moment in time. It does not represent ownership of that requirement or task, as items are owned by the entire team. Everyone on a team is responsible for each item's completion, regardless of who may be currently actioning it.
Remember that seeing multiple avatars on the same item can be a good thing, as it ought to evidence the limitation of work in progress. Conversely, witnessing someone place their avatar in such a way that multiple items are spanned is a matter of concern, as it implies that too much work is in progress. By the same logic each person on a team should only have one avatar, since an individual should not be working on more than one thing at a time.
Cherry Picking is an antipattern where a team member might place his or her avatar on an item in a backlog, effectively "booking" it for themselves to action later. This is inefficient because the item should be actioned by whichever team member is available at the necessary time. It also encourages the development of specialisms and skill-silos, and puts the cross-functional capability of a team at risk. There is never a good reason to place an avatar in a backlog, since this would imply that the item was being actively worked on by that person in some way.
Avatar is January's Pattern of the Month at agilepatterns.org
Intent: Have a signal on an information radiator that indicates who is working on what
In a transparent world it is best to be transparent
Honesty is the best policy
Also Known As:
Motivation: Misunderstandings can arise as to who is currently responsible for work that is in progress. A means is needed for showing that work is actively being done and by whom. Queries about that work can then be directed to the appropriate team member. Conversely, work that is no longer clearly represented can be actioned and completed before additional work is drawn from a backlog.
Structure: Enqueued items are taken off the backlog by developers, at which point they become work in progress. A developer will immediately attach his or her avatar to the item to indicate that they are progressing it. Once the item is complete, they will remove their avatar from it, and are free at that point to progress another item from the backlog assuming that the Work In Progress limit would not be exceeded. Note that each developer has only one avatar, and can therefore only take off one backlog item at a time before completing it. The Work In Progress limit cannot therefore exceed the number of developers. Developers are allowed to collaborate on the same item; it is therefore permissible for an item to have multiple avatars. No item that is in progress should ever be without an avatar.
Applicability: Avatars can be used on both Scrum and Kanban boards to show which team member is progressing each item. Single Piece Flow obviates the need for avatars since all developers will, by definition, be working on the same item.
Consequences: Avatars reduce the potential for confusion in the team regarding who is progressing work. They also encourage the limitation of WIP since each developer only has one avatar to attach to an item.
Implementation: Cartoon characters are a popular choice of avatar. They can be printed out, potentially laminated, and then attached to index cards on a physical Scrum or Kanban board. Fridge magnets can be used on magnetic boards. Electronic boards may not always support avatar images, but most will allow the name of an item’s assignee to be registered and displayed instead.
Board Avatars, by Corinna Baldauf
Lego scrum board avatars, by Helen Emerson
Sign Up for Tasks, Agile Alliance