DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

How does AI transform chaos engineering from an experiment into a critical capability? Learn how to effectively operationalize the chaos.

Data quality isn't just a technical issue: It impacts an organization's compliance, operational efficiency, and customer satisfaction.

Are you a front-end or full-stack developer frustrated by front-end distractions? Learn to move forward with tooling and clear boundaries.

Developer Experience: Demand to support engineering teams has risen, and there is a shift from traditional DevOps to workflow improvements.

Related

  • A Non-Technical Guide To Adopting Agile Methodology for Your Non-Software Team
  • What Is Agile Methodology?
  • Top Software Development Tools Used by Agile Teams
  • Scrum Smarter, Not Louder: AI Prompts Every Developer Should Steal

Trending

  • Why 99% Accuracy Isn't Good Enough: The Reality of ML Malware Detection
  • Scrum Smarter, Not Louder: AI Prompts Every Developer Should Steal
  • When Agile Teams Fake Progress: The Hidden Danger of Status Over Substance
  • Converting List to String in Terraform
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. The Importance of WIP Limits

The Importance of WIP Limits

Regardless of what sort of beliefs you have around Agile, if teams focus, they will get more done and deliver value faster, which leads to improvement.

By 
Daniel Barreto user avatar
Daniel Barreto
·
Sep. 12, 17 · Opinion
Likes (3)
Comment
Save
Tweet
Share
10.0K Views

Join the DZone community and get the full member experience.

Join For Free

A team member once came to me and said that their team was currently using Kanban, but that they wanted to switch to Scrum. When I asked why their response was: "we need the two-week time-box because in Kanban everything goes into the in-progress column and just stays there." There are clearly many issues that would need to be addressed in this statement (how the team sizes stories, for example), but one that is very important that seems to be ignored on a regular basis is WIP Limits.

What Are WIP Limits?

WIP stands for Work In Progress, which is pretty much any work in a project that has been started but, for whatever reason, has not been completed. With that in mind, a WIP limit would be the maximum amount of work in progress that is allowed at a time in a team or system. A very simplified example of a WIP limit would be, if you have two developers and the team has decided to set a WIP limit of one for each developer, then the total number of development tasks that can be in progress at one time would be two. Although this sounds simple enough, many teams don't seem to place enough emphasis on why they are important which typically leads them to be ignored or used incorrectly. 

Why Are WIP Limits Important?

As much as everyone wants to believe they can multitask well, the truth is that it is always less effective than focusing on one task at a time. In addition, when people work on multiple tasks at once they will typically jump multiple times from task to task which leads to big losses in productivity every time they have to refocus on a task they had previously been working on.

Having a limit on the amount of work that can be handled at any one time prevents people from starting new work when there are tasks that are not finished. Instead of starting a new task when something becomes blocked or too difficult, WIP limits force teams to look at why a particular piece of work has not moved forward (is it too big? Is outside help needed? Are the requirements unclear? Are more developers needed?) and then focus on doing whatever is necessary to finish it so that more work can start to come in and so that the flow of work through the system can resume.

Does Scrum Use WIP Limits?

WIP limits have typically been associated with Kanban, but is it something that Scrum teams can apply? Of course! Isn't the Sprint backlog itself a WIP limit that the team collectively sets for themselves based on their capacity or historical velocity? Scrum teams can take this a step further by introducing Kanban concepts into their Sprints (Scrumban) and setting additional WIP limits for each individual on the team or the types of work they will have to do.

Getting Started With WIP Limits

One of the most important principles for any team working in an Agile fashion (regardless of what Agile frameworks they choose to use) is a focus on continuous improvement. Much of a team's continuous improvement will come from experimenting, inspecting, and then adapting. 

When starting to implement WIP limits for a team this will be no different. At the beginning of any project, especially for a team without much Agile experience, it can be tricky to set an appropriate WIP limit. Make the limit too strict in the beginning and people will get discouraged, frustrated, or even worried. Make the limit too big and then people will be able to work on too many things at once which will, in turn, defeat the whole purpose of having a WIP limit in the first place. 

In order to start, the team should pick initial limits that they feel comfortable with and can commit to following for a period of time. The team can then commit to holding a retrospective session to discuss whether their initial approach has been effective and whether they should revisit the limits that they have set. As the team matures, the WIP limits should get smaller. Ideally, the WIP limit for everyone should be one, but that can sometimes be unrealistic, so the team should always use their best judgement and work on finding a solution that is best for the team as a whole. 

A good place to start may be to set a limit of two tasks per person/role. So if you have two testers on the team, the WIP limit for a testing column on a Kanban board would be four. Regardless of whatever limit the team decides on, the important thing is to always keep revisiting the number and see if there is any way to change it that will help improve a team's process and keep work flowing through the system.

Summary

Although WIP limits are easy enough to understand, too often teams will either ignore them or misuse them. Regardless of what sort of beliefs you have around Agile, Waterfall, Lean, or any other process or framework, the truth is that if teams can learn to focus, they will be able to get more done and deliver value faster, which will then leads to continuous improvement. The power of WIP Limits to help teams maintain this focus makes them a vital tool for any team while on their Agile journey.  

agile scrum Task (computing)

Opinions expressed by DZone contributors are their own.

Related

  • A Non-Technical Guide To Adopting Agile Methodology for Your Non-Software Team
  • What Is Agile Methodology?
  • Top Software Development Tools Used by Agile Teams
  • Scrum Smarter, Not Louder: AI Prompts Every Developer Should Steal

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: