Improving Scrum Using Kanban Work-In-Progress Limits

You limit work-in-progress (WIP) in Scrum to the work items in your sprint backlog. Doing this provides focus, relief from over-burdening, shorter feedback loops, and faster delivery of value.

You can also use in-sprint WIP limits and defect policies, often used in Kanban, to promote even better focus, relief from over-burdening, shorter feedback loops, and faster delivery of high-quality value in each sprint.

When your team starts working on most or all of the sprint backlog items at the beginning of the sprint, and works on bits of each item throughout a large portion of your timebox, you run the risk of missing your sprint goal. The following is a story about a Scrum team who did just that and put their sprint goal at risk, and over-burdened the team members.

Sprint Day 1: You divide up all the work in the sprint backlog amongst yourselves and get busy!

 

Sprint Day 3: You start rocking and rolling. Each of you is multi-tasking between each of your assigned items and “burning down” your estimated task hours and you are feeling like a million bucks.

 

Sprint Day 5: All your work items are still in development. Your Product Owner and Scrum Master are secretly worrying that you may not complete all the stories by the end of the sprint.

 

Sprint Day 7 : Your burndown chart is on target, but most of your work items are still in development. The cost of context switching is causing significant delays. You are stressed. You are working like crazy, some of you are working into the wee hours of the night, to get all your work developed before day 10.

 

Sprint Day 9: You complete developing your work items and move them to acceptance testing.

 

Sprint Day 10: Acceptance testing is overwhelmed; they do their best within the short timeframe to get the work items across the finish line.

Insufficient time for work validation

When most of the work is completed toward the end of the sprint, you often don’t have enough time for thorough validation. This puts you at risk of deploying poor-quality functionality. By doing this, you risk jeopardizing your customer’s satisfaction. Completing work items incrementally throughout the sprint will allow the Scrum team to do solid testing and Product Owner review and acceptance. You will also get faster feedback on items and potentially get customer value more quickly.

Using In-Sprint Work-In-Progress Limits

“Stop starting, start finishing.” – David J. Anderson, 2004

Rather than starting everything in the sprint backlog on the first day of the sprint, take a subset of that backlog and get those items finished.

But first, if you’re not already, visualizing the work and work progress in your sprints using a Scrum board view. Create a Scrum board with columns labeled for each major step a work item flows through within a sprint.

While you could just establish WIP limits on each column of your sprint board, you may want to ensure that the highest priority work items get completed first. If that makes sense for your team, you could do something similar to this:

1. During sprint planning, collaboratively decide priorities for each user story considering business priority, technical priority, and size. Group the sprint backlog into 2-4 priorities.
2. Assign each card a priority.

3. Establish a WIP limit on the column to the right of the sprint backlog column. Add new items based on priority when you have capacity.

In-sprint defect policies and per-person Work-In-Progress limits

The team invests more time and money on a work item that is farther along towards completion than an item they haven’t started or they’ve recently started. To capture the value of that investment, the items that are close to finished should be prioritized over starting new work. Kanban teams establish a policy: when a defect is found on an item, they will shift focus to fix the defect so it can get completed. The longer you wait to fix a defect, the longer it will take you to fix it.

Defects found in a sprint are unplanned work, so they should be included in WIP limits. For defects found outside the “development” step, it’s best to leave the item with the defect in the column it was found. Then, to prevent a single person on the team from having too much work in progress due to unplanned work, and to balance workloads, you can establish per-person WIP limits.

For example, if you set a WIP limit of three per person, and Person A has two items in progress then they start working on a defect, that person won’t take on additional work until they fix the defect.

Improve the flow of value with in-sprint Work-In-Progress limits

By using simple WIP limits and WIP policies in your Scrum team, you can complete work items in a nice, even flow throughout your sprint timebox. WIP limits will prevent over-burdening team members, decrease the time cost of context switching, and allow you time for thorough inspection and adaptation within the sprint.

Learn more about using Kanban practices in your Scrum team in one of NextUp Solutions’ certified Kanban training classes.