The Sprint planning meeting is one of the foundational ceremonies of Scrum practitioners. The meeting typically runs from 1-3 hour where team members come together, decide what work needs 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 these five criteria:
- the length of the Sprint
- what the team’s velocity has been to date
- cumulative size
- the results from Sprint Review and Retrospectives
- the Product Owner’s directionsWe’ve noticed 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 be necessary when there is already work in progress. 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. However, the flipside, having a minimum WIP limit can help us avoid these traps as well.
Teams can reduce the amount of waste by replacing the Sprint Planning Meeting to a more interrupt-driven planning meeting triggered by the minimum WIP limit while still using the Sprint as a gauge to help size and plan work. How? By not allowing the Sprint timeframe to be a hard and fast duration policy. Planning triggered by the minimum WIP limit allows for a few different benefits: 1) The work becomes a continuous flow 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 is shorter, allowing for waste reduction. One reason is because the discussion becomes more user story centric. 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 Figures A and B the minimum WIP limit is 3 and the maximum WIP is 5 and 10 respectively. The WIP limit indicator has turned red in Figure A to indicate that the number of cards (1) 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 within the minimum. 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. The important thing is getting to that shared understanding of user stories.
The boards here in ScrumDo 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. See Figure C.
We are very interested in how you have been using minimum WIP limits. Please drop us a line and share your story by connecting with us. If you want to learn more about limiting your work in progress please write to us. We want to help.