Scrum Sprint Planning with Kanban

Scrum Sprint Planning with Kanban

During Sprint Planning, Scrum teams play fortune-tellers and try their best to predict how much work they can commit to. Most of the time, this is a difficult feat to pull. The usual approach of teams would be to take their average velocity and use that for Sprint Planning. But we know that a team’s velocity would vary through time and there are a lot of factors that contribute to its variation.

While it can be precise, using average velocity for Sprint Planning will not guarantee accuracy. Teams should not discount the variation that can be experienced sprint-by-sprint. There will be unexpected production issues that pop up or urgent product backlog items that need to be prioritized. Stories can be more complex than before. Team members may go on personal time-off which can decrease capacity. With uncertainty being certain, teams have developed ways to manage work towards the sprint boundary.

Managing work at the Sprint Boundary

One of the common approaches teams use to manage sprint expectations is to use a buffer. For example, they can allot a day in the sprint to take on any urgent or production issues. So, if there are 10 days in a sprint, they’d only take on stories that can be finished in 9 days. Some eyebrows may be raised with this approach and two of the common reasons include:

• Stakeholders may think we’re letting the team slack off.
• The possibility of sacrificing items that contribute to the Sprint Goal if the buffer (e.g. 1 day) is not enough to resolve an urgent issue.

Realistically, we cannot predict with 100% certainty when an item would be finished. Sprint commitments will always be an educated guess.

Another approach that teams explore is to manage scope instead of time. This can mean that they will allocate a certain percentage of the Sprint Goal scope to “must-have” items and the remaining to nice-to-have items. For example, if a team allocates 60% of its sprint capacity to must-have items, it means they have 40% capacity remaining to allocate to urgent issues or nice-to-have items. By doing so, this allows teams to have a higher chance of meeting their Sprint Goal earlier.

Once the Sprint Goal is met, any additional work will not be critical. But this can also raise issues about teams working on items that are not of the highest value in the Product Backlog. A solution to this can be to discuss with the Product Owner about trading some nice-to-have items with items on the top of the Product Backlog. The caveat here is the team wouldn’t be obliged to complete work on the newer items pulled at the end of the current sprint.

Does it mean that items would roll over to the next sprint?

Technically, yes. If the product backlog priorities don’t change then the unfinished item would be rolled over to the next sprint. The team would have to re-estimate them as work has already started before it’s officially committed to a sprint.

If teams have this arrangement in place, it means they would inevitably have unfinished work every sprint. Is that a bad thing? Not exactly. If we think about it, not only are they maximizing their capacity, but they’re also working towards your release objectives.

But this also means that the Sprint Backlog gets replenished outside of Sprint Planning. This arrangement puts more importance on flow rather than on feature-focused Sprint Goals. This may warrant a different approach to Sprint Planning altogether. This is where Sprint Planning with Kanban kicks in.

How to conduct Sprint Planning with Kanban

Sprint Planning with Kanban is called Flow-Based Sprint Planning. The Kanban Guide for Scrum Teams defines Flow-Based Sprint Planning as a meeting that “uses flow metrics as an aid for developing the Sprint Backlog.” Metrics can include throughput, cycle time, and work item age, to name a few. During Flow-Based Sprint Planning, teams use Kanban metrics to frame their commitments for the upcoming sprint. For example, teams commit to improving their cycle time or maximizing throughput in a given sprint.

While focused on flow-based metrics, stories worked on by the team will still be based on the value set by the business. The Product Backlog prioritization is not affected by this change in planning. However, how the Product Backlog is consumed is where the change is experienced.

With Flow-Based Sprint Planning, the Sprint Boundary becomes almost seamless. The team pulls work into the Sprint Backlog when there’s capacity. If the work is unfinished, they would continue working on it on the upcoming sprint. Sprint Planning becomes a venue for the team to validate their flow-based Sprint Planning goals and course-correct when needed to establish a stable flow of work sprint-by-sprint.

Kanban as a strategy for flow optimization in Scrum

Sprint planning with Kanban can be a big shift for Scrum teams. Industry experts observe that this technique is more often used by teams working on mature products. This is because the complexity of these products has minimized and teams working on them have a better grasp of the type of items they would work on. With this, the focus on building features is decreased while the need for stability and improved flow of work is increased.

This pushes teams to explore Kanban to match their needs. Kanban becomes a strategy for flow improvement and optimization. Scrum teams can do Sprint Planning with Kanban as they see the need and then switch back to feature-driven Sprint Planning once they’ve optimized their flow.