Scrum with Kanban - why use WIP limit?

what benefit would it bring to the Sprint cycle by limiting the WIP (i.e. the backlog items being worked on during the Sprint)?

What would be good measurements for a team to use, if they were to gauge their progress towards the Sprint Goal?

What would be good measurements for a team to use, if they were to gauge their progress towards the Sprint Goal?

Thanks Ian for the response. Wouldn't the daily scrum meeting help the development team collaboratively track the progress (including discussion around any impediments) towards the Sprint goal? Velocity can be a lagging indicator by the team to decide how much work it can take in the upcoming Sprint....maybe WIP limit can help bring a little more discipline in the way the work is executed during the Sprint but beyond that, I am not sure what other gains it can provide.

WIP limits in Kanban are to help the team maintain a steady pace of delivery and prevent any bottlenecks/delays from entering into the workflow. WIP limits help a team focus on moving items across the board in as short a time as possible without sacrificing quality or value.  They do the same thing with a Scrum Team within a Sprint.  How many times have you seen your teams pile up work in a Code Review or Ready for Test column?  WIP limits can help to prevent that.  If one of those columns reach it's limit, the team focuses on clearing out the work blockage.  I have seen this prevent work from not being completed because of the focus on keeping items moving across the board.

I'd suggest that in their Daily Scrum a team may wish to consider indicators such as work item ageing. The longer an item remains in progress, the greater the risk of it not being completed at all and of the Sprint Goal not being achieved.

In lean and agile practice, work being completed is the best evidence of progress. There is no value to be had in merely starting it. Hence the limitation of WIP, so work is completed early and often, is of application at many levels.

-- "Stop starting, start finishing".

Thank you Ian and Daniel.

While I absolutely agree to the advantages kanban practice brings towards making the process to deliver value more efficient & effective in general, I think in the context of scrum, WIP limits may not always be necessary.

Scrum uses time-boxes, which limits the time-frame to deliver an increment (in turn value) in short iterations. Since that control is already established, how the team works within that time-box becomes irrelevant. Of course, optimization would not hurt but is it really necessary? The development will work as self-organizing unit to finish the committed backlog items as there is a plan established to do it and a time limit set (Sprint time-box).

Kanban on the other hand works in the context where the flow in continuous. There is no time-box set as to when a specific unit of work has to be delivered. Therefore, WIP limit may be needed in such environments to help optimize the flow to avoid aging, bottlenecks etc. That way there is an optimal flow of work resulting in turn in optimal deliver of value.

Having said that, I agree that there is no harm is using both practices together but I think each has a specific constraint to address. And using it in that context would be ideal to attain maximum benefit from the framework.

Best Regards,

Mohit

maybe WIP limit can help bring a little more discipline in the way the work is executed during the Sprint but beyond that, I am not sure what other gains it can provide.

Don't underestimate the power of discipline.

I work with teams that are using Kanban, although to be fully honest our WIP limits are high enough in places that they aren't really limiting flow. It's actually the choices and behaviour of the Development Team members that are doing that.

I think we can use these limits more effectively, but given that we are paying attention to flow, we do still see many benefits.

The biggest change I observed when the team initially defined WIP limits was a greater focus on finishing work in progress, rather than starting new work. Tangibly I observe team members more frequently asking "Is there anyone who can use my help, before I pick up something new?".

This is of direct value to us, because we typically release several times per day, and so by focusing on finishing work sooner, we realize potential value sooner, and gain far more learning opportunities throughout each sprint.

Furthermore, this attention to flow has helped us highlight bottlenecks. One team in particular takes time each week to review the slowest ~15% of items to move across its board. They look in Jira for the history, and any comments they added, as well as sharing the insights of the team members who worked on that item.

They then track their observations in a spreadsheet, and are keeping count of how often an item was slowed down by a particular factor. e.g. "switched focus because of critical incident", "blocked by dependency on another team", "technical impediment with deployment pipeline", etc.

This puts us in a very strong position to measure the effectiveness of our own continuous improvement, but also to start data-driven conversations with other teams and management, when help is needed.

Thank you Simon. I absolutely agree to the numerous benefits kanban can bring to the team and the ones you have stated from a real life experience seem relevant & very helpful. Thank you for that.

The biggest change I observed when the team initially defined WIP limits was a greater focus on finishing work in progress, rather than starting new work

My question is more towards using kanban with scrum framework. The biggest change you mentioned above may not be relevant in the context of Scrum because ideally once a Sprint starts, the Sprint backlog is usually unchanged - unless there is a valid rationale to add or remove work. And this is always done in collaboration with the PO to maximize value. So, starting new work outside of the committed items will not be a regular practice (I assume). Now, yes within the committed backlog items, the development team may start work of multiple items in parallel - but isn't that the benefit of being a cross-functional team?

Having said that, I am not denying the benefits of using Scrum or Kanban. I agree to all the good points shared in this forum so far. I am just trying to understand the mix better.

-- Mohit

The biggest change you mentioned above may not be relevant in the context of Scrum because ideally once a Sprint starts, the Sprint backlog is usually unchanged - unless there is a valid rationale to add or remove work.

I disagree with this. I would expect a Development Team to inspect and adapt as much as needed. The Sprint Backlog represents a forecast of remaining work, which should be updated as more is learned.

Also, depending on the context, and the type of Sprint Goal that the Scrum Team has chosen, the work may be incredibly variable.

If the Sprint Goal represents completion of predetermined work, as scoped, then there is likely to be very little adaptation of the Sprint Backlog; but I'd also argue that Scrum is of considerably less benefit in such a circumstance.

However, if the Sprint Goal is more outcome-focused, such as "Increase by 5 percent, the number of visitors who make a purchase after coming to our online shop", and if the Development Team has responsibility and skills to carry out UX work such as user interviews, data analysis and rapid prototyping, then I could very easily imagine that work on the Sprint Backlog would be changing multiple times per day.

In such a circumstance, the Development Team may want to front-load the items that allow the most rapid learnings, and as team members report back the results of user interviews or other experiments, it might emerge that new development work is needed, such as changing the visual layout of the online shop, or modifying the algorithm that helps visitors find what they're looking for. Old plans might be removed from the Sprint Backlog, as priorities change or hypotheses being disproved; or the Development Team might have begun the Sprint with very little work planned, because it knew it would learn more along the way.