A ceremony Scrum practitioners are familiar with is Sprint Planning. It’s an important ceremony for a Scrum team in which the team plans for the next Sprint. It typically is a 1-3 hour meeting when team members come together, understand the work needed to be done, and commit to user stories they will work on for the next Sprint. The (quantity and kind of) work committed to is typically based on 1) the duration of the Sprint 2) history of the team’s velocity 3) cumulative size (relatively sized typically by team consensus using planning poker) 4) the team’s learnings (from the other two important ceremonies – Sprint Review and Sprint Retrospectives) – and of course – 5) the Product Owner’s directions.

What we noticed though was that there is a “time cost” of the ceremonies and the amount of work pulled in may not fit the Sprint well from either a too much or too little perspective. What’s more, Sprint Planning meetings may not even be necessary when there is already work in progress.

By applying Kanban practices and principles in a Scrum context, Scrumban addresses some of these common issues including the Kanban practice of WIP (Work In Progress) limit. A WIP limit typically signifies the upper limit. This means that the number of cards in the respective column, row or board should not exceed that number.

Minimum WIP limits

Teams can reduce the amount of waste by evolving Sprint Planning to a more interrupt-driven planning triggered by the minimum WIP limit while still using the Sprint as a gauge to help size and plan work. How? By not using the Sprint duration as a hard and fast duration policy. Planning triggered by the minimum WIP limit allows for a few different benefits:

  1. The flow of work becomes smoother rather than having peaks of demand at the beginning of the Sprint and the possibility of starvation at the end of the Sprint.
  2. The planning event tends to be shorter, allowing for waste reduction. One reason is because of less estimation discussion and more user story centric discussions.
  3. Work may still be taken in batches and setting Sprint length goals, but the planning event is triggered if and only if there is a need for it. This is why we still prefer to call it a Sprint Planning event.

This technique can also be used for connected Kanban systems, like a Program or Portfolio Kanban system, to ensure there is adequate work downstream. In very large enterprises, this may mean additional coordination outside the team and will need careful consideration before implementing minimum WIP limits.

Here is an example of a team using minimum and maximum WIP limits by number of cards. In Figure A and B the minimum WIP limit is 3 and the maximum WIP is 10. The WIP limit indicator has turned red in Figure A to indicate that the number of cards (2) in the column has fallen below the WIP limit policy of 3. When this happens, the team triggers a Sprint Planning session to pick a couple of cards from the prioritized queue to bring it to normalcy. The cards picked are based on a cost of delay priority and the cumulative size of work in the queue. Historically, this is anywhere between 5 and 9 days. So there is still a cadence just not hyper synchronized. Allowing a range allows the planning event to be more meaningful and the personnel to be more ready. This team still calls it “Sprint Planning” after its historical name and because the cumulative size target for each replenishment are cards that the team thinks that can be completed in 8-10 days. Sometimes, we call this a “Replenishment Meeting” which is more accurate. Whatever name is used, the important thing is getting to that shared understanding of user stories.

figure_a_6-6-16 figure_b_6-6-16
Figure A Figure B


The boards in are very flexible when it comes to setting WIP limits. It allows both minimum and maximum WIP limits by cards or by points, as well as, setting of WIP limits by columns, rows and any combination thereof.

 Figure C

Share your experience with us if you’ve ever implemented minimum WIP limits and, of course, contact us if you need help understanding or maximizing this potential. Want to learn more about Scrumban? Get the Scrumban [R]Evolution today or download our free eBook – Scrumban 101.

About the author

Ajay Reddy has spent more than a decade helping technology teams and organizations improve how they work. His engagements emphasize a hands-on approach, collaborative experimentation, verified business outcomes, and improved team satisfaction. After discovering agile approaches as a software engineer, he transitioned to coaching others in adopting agile. In 2010, he co-founded to provide cloud-based project management tools to facilitate better Scrum and Kanban implementations. As its managing partner, chief product strategist, and lead coach, he helps teams in 145 countries realize Scrumban’s benefits. He recently co-created the GetScrumban game to help people discover Scrumban’s capabilities.