If it seems like your agile team constantly bottlenecks during a certain stage of a workflow, Work In Progress (WIP) limits may be your solution. Agile teams implement WIP limits to control the number of active items within each stage of an agile workflow. This control allows a team to concentrate on a concise amount of tasks to make sure each task is completed correctly and on time. WIP limits also allows an agile team to respond to change efficiently.
Before implementing WIP limits, an agile team must define the acceptance criteria that will be used to move a backlog item from one stage to the next. A backlog item must pass all criteria on a checklist before a team member moves the item to the next stage. The primary goal of these checklists is to ensure the integrity of backlog item movement.
WIP limits can play a very critical role in the development stage of an agile workflow. Let’s be honest, we have all run into that developer who thinks they can complete every task in no time. Having WIP limits in place keeps this kind of person focused and on task. All backlog items require some sort of ramp up time whether it is knowledge transfer or further refining requirements. Constant switching between multiple tasks before an individual task is complete can lead to a lot of time being lost during a sprint solely based on ramp up time and we all know time is money. And no one likes losing money!
Not only can WIP limits identify key areas of focus and bottlenecks, they also can point out areas of idleness throughout an agile workflow. If a certain stage in the workflow is never reaching its limit, then the team may not be working efficiently enough during that stage or the team overestimated on determining the WIP limit.
It usually takes teams a while to adjust to WIP limits after introducing them to an agile workflow. The key after implementing the limits is to remain consistent with them for multiple sprints. This will allow you to obtain accurate metrics on whether or not you have properly set the WIP limits for each stage of the workflow. It is easy to want to adjust your WIP limits when you run into an issue or setback, but you must resist this urge. If a WIP limit is consistently being run into then there may be an opportunity to improve a skillset or process within the team. You should only adjust a specific WIP limit after you have identified that the set limit is not benefitting the team overall. This adjustment should only be done after completing multiple sprints.
It also helps to gather WIP limit feedback from the entire team on each limit and not solely the team members directly affected by it. For example, as an agile team manager I would ask the quality assurance testers for their opinion on what the QA stage work in progress limit should be as well as developers and business analysts. Every team member should provide his or her input to ensure the chosen limit is unbiased.
Using WIP limits should help ensure every team member is working at a highly efficient rate but not overly multitasking. As mentioned before, your WIP limits will probably require fine-tuning after completing a few sprints. A best practice to keep in mind is never set the maximum work in progress limit above the number of team members. I hope this overview of work in progress limits in agile was informative and helpful.