What to do for the developer when the WIP limit is reached

#agile #kanban #management #development

Did you reach WIP limits and don’t know what to do? And you don’t want to procrastinate, do you? Keep reading this article in order to find out the perfect solution when you or your teammates-developers reach WIP limits.

Photo by Clark Tibbs on Unsplash

What is WIP and what are the WIP limitations? #

WIP is an abbreviation of work in progress, which means activities have started but are not yet completed (e.g., task waiting for review). WIP determines how many tasks can simultaneously be at a particular stage.

The limitation prompts you to complete the task before moving on to another one. This quality makes the work in progress limitation so attractive in Agile and Kanban methodologies.

Photo by Joshua Hoehne on Unsplash

Toyota uses several methods to limit work in progress, incorporating them into its corporate standard practices called Toyota Production System . One WIP limiting method is called Just in Time Manufacturing , a philosophy that avoids starting work until “the last responsible moment.”

Our limitations #

Our limitations for the development process are:

  • In Progress list limit: 1 issue per developer

  • Developer’s issue limit: 2 items per developer from In Progress, Review/QA until Done

  • Time limit per issue: 2 days per issue from In Progress, Review/QA until Done

How to understand when the WIP limit is reached? #

When the developer has 2 issues on Review/QA, it means that he reached WIP limits, and he can’t get a new task before he finishes one from Review/QA.

What to do after you have done your part #

Here is the list, ordered by priority:

  1. Help other developers with a Review or In Progress. It means that we deliver functionality in time, and your colleagues can work on the other tasks. If someone is stuck with a task in progress, you can offer help, write down possible solutions, or establish a pair programming session.

  2. Check the next tickets from the backlog. In this stage, you need to check all tasks in the backlog list, close old issues, check whether everything is clearly described in the task, and ask questions about unclear things.

  3. Group small tasks into Epics. In this step, you need to check if there are small tasks that are linked or interrelated (e.g., 3 similar linter issues) and group them into one Epic task, where you need to mention small tasks.

  4. Help with Documentation. Here you need to check if there are no issues with your project Wiki or other similar stuff(researches, experiments, performance analysis, vulnerability search). You can always get them delivered because they don’t affect the code, and there is no need in a review.

  5. Low priority tasks. If you have not found anything from above (and want to cheat the system) — then you could work on less critical smallest stuff like small refactorings, formatting, linting, package upgrades.

Taking everything into account #

This list is quite simple, and this should be enough, the main rule: *whatever your team chooses, do not add new logic. *Limitations prevent overloading your work processes, allowing you to deliver value to end customers as fast as possible. Big companies such as Toyota use this technique.

Check out useful links if you want to be advanced in this theme:

Paul Keen is an Open Source Contributor and a Chief Technology Officer at JetThoughts . Follow him on LinkedIn or GitHub .

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories .

Comments