Work-In-Progress (WIP) Limits are helpful when you are working in a true Kanban style: where work gets "pulled" as people become free, rather than work getting "pushed" onto people before the people ready.
To understand the difference between "push" vs. "pull", think back to that famous episode of "I Love Lucy" where Lucy and Ethel take up jobs at a chocolate factory, and quickly find themselves unable to keep up with all the work that's getting pushed onto them :-)
This is a perfect example of the perils of "push": as the chocolate gets prepared upstream, the work becomes ready even though the people aren't ready to work.
A pull model is different: people "pull" work and assign it to themselves when they are ready.
Each person typically has a small number of items they are juggling at any time: it may be as few as two items, depending upon the complexity of the work, but it is rarely as few as just one item. (You nearly always want to have one "background" task ready to be picked up whenever your "foreground" task gets blocked for any reason.)
When a person is able to take on a new task, she can "pull" a card from the column to the left of her on a Kerika board.
Here's a simple example, reflecting the workflow for a software project.
This board includes people with different roles: designers, developers and QA, and each group has determined it's own WIP limits, based upon the team's capacity and velocity.
In this particular example, we can see that the Deployment column has currently exceeded its WIP limit, while the Planning & Development column hasn't.
When this happens, Kerika alerts you to the condition by showing the affected columns with red text in the column headers.
WIP Limits as "soft limits": Kerika doesn't stop you from exceeding a column's WIP Limit, but it does provide a clear, visible warning to everyone that a bottleneck is about to form.
When bottlenecks start to form, the Board Admin can intervene to help manage the upstream flow, so that the WIP Limit can come back to its acceptable amount.