Why use WIP limits

Scrum is not only about the ceremonies considering that by following from the agile-bible-book all the artifacts, we assume that we are agile. One of the continuous challenges that a Scrum Master has to deal with, is to enable such an environment within the Scrum Team that the team members are self-organized and self-managed by being open, transparent and honest to each other.

Of course a Scrum Master needs to make sure that the Scrum Team get things done and if not, tries to find ways to do so, via the right tools and artifacts. For example via a good exercise in Retrospective reflecting the reality back to the team so they understand what really went wrong and take one or two action items for the next iteration. A Scrum Master acts more like a coach at this meeting and tries to help the team to understand the value of improving on certain areas, otherwise the Scrum team either is going to ignore the action items or we end up pushing solutions to the team which is not recommended.

Among many things, when we refer to the "Get things DONE" we mean that the Scrum Team needs to deliver what has been committed during the planning of the iteration. It is very common for Scrum teams to have unfinished stories at the end of the iteration and the Scrum Master needs to get into the root cause of that via some techniques such as the 5 whys. Many options are available to deal with that challenge, as some teams just push the User Story to the next Sprint or split it into two. Both of the options are not either right or wrong but they have some side effects which affect the culture we are trying to cultivate in an agile environment. And that is one of the points that someone could highlight and distinguish the difference between doing and being agile.

WIP (Work In Progress) limits is one of the many ways to deal with that situation. Based on the kanban board in your team's war room, you set some working limits on development, testing, review etc (depending on the columns) For example the team pulled 5 user stories for the Sprint and there is a WIP limit on development, which is the number 3. At this case, the developers are allowed to pull and start developing 3 stories only and not 4. That helps the team to focus on those stories, get them DONE and then start working on another story. WIP limit, is a KanBan technique which actually is very commonly used in teams that use Scrum to het things Done. The reason is because the team, starts the pulling from the right to left and not from left to right.

To make it more clear, lets assume we have a KanBan board with the following columns from left to right : To Do / Development / Testing / Done. Development column has WIP limit 3 and testing WIP limit 2. If we already have 3 stories in development then we wont pull from the To Do column another story but focus on pulling to the Testing column a story from Development.

A Scrum Master needs to be active all the time and act accordingly. There is no right or wrong thing to do, but what fits best to the team.

Konstantinos Kareklas