Sprint Planning with Kanban

Let’s address the immediate question… It’s rather odd that I’m discussing a Scrum Event on a Kanban blog! However, I’m a firm believer that Scrum and Kanban complement each other exceptionally well. Kanban brings Flow Metrics, Work Item management, and powerful forecasting tools to Scrum, and in turn, the Scrum Framework helps ensure that we don’t plough very quickly and effectively in completely the wrong direction. There are some outstanding books and articles out there which expand on this, instead what I’m going to do is discuss the nitty gritty aspects of how to use Kanban’s Flow Metrics in one of the most important Scrum Events, Sprint Planning.

Next question, why should I care? Perhaps you use Scrum already and are doing quite well without Flow Metrics, or perhaps you’re using Kanban and don’t use any kind of planning/Sprint cycle to organise your work. I believe that for the majority of software teams unless you’re combining these two practices you’re missing a trick. Scrum without Kanban is heavily based on estimation or rescoping, this leads to work constantly being negotiated and little confidence in what the team can deliver. On the other hand Kanban without Scrum runs the risk of build/deploy/build/deploy without any schedule to check in with stakeholders to verify that we’re still moving in the right direction. Wouldn’t you rather set a short-term goal, with reasonable confidence that you’ll be able to deliver it and reassurance that it will move you towards your organisation’s ultimate goal? That’s the power of Scrum with Kanban.

For those who's Scrum knowledge is a little rusty the Sprint Planning Event is at the beginning of each Sprint and is where the team plan out their goal for the upcoming timebox and plan how they’re going to accomplish it.

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.

The Scrum Guide

Teams holding a Sprint Planning session attempt to answer three questions.

• Why is this Sprint valuable?
• What can be some in this Sprint?
• How will the work get done?

The team typically does this by crafting a Sprint Goal and a plan of how to accomplish it. This goal can be shared with stakeholders and is an excellent tool for helping the team maintain focus to improve towards their longer-term objectives.

However, rather frustratingly in my mind, the Kanban Guide for Scrum Teams is very vague on this event:

A flow-based Sprint Planning meeting uses flow metrics as an aid for developing the Sprint Backlog. Reviewing historical throughput can help a Scrum Team understand their capacity for the next Sprint.

Kanban Guide for Scrum Teams

So how can teams actually do it?

Here’s my advice, once the team has identified a Sprint Goal there are three questions they are left to extrapolate on their own.

• How do we represent the Sprint Goal so we can all,y Flow Metrics to it?
• How can we use Flow Metrics to what work can be done in the Sprint?
• What should we do with the work we’ve started but haven’t finished?

There are a few different ways that a Sprint Goal can be represented, it's worth mentioning that this isn't inherently different to when working in pure Scrum, however when applying flow metrics it becomes far more important to get right.

The Sprint Goal can be represented by a single piece of work amongst others. Other items on the board are being done by the team however this one represents the team's main focus. This is possible, however, there are a number of reasons I don't like this.

• It makes it less likely the team will stop negotiating the scope once the Sprint has started
• It encourages an implicit Class of Service which is extremely detrimental to overall flow
• It raises the question of why we are doing work that doesn’t contribute to the Sprint Goal

Instead, I recommend that we represent the Sprint Goal by a number of different pieces of work on the board, these should be prioritised by how important they are in helping the team achieve their goal. For example, if our Sprint Goal was to create a Data Export then our work items could be:

• Create a file with a list of IDs
• Add members’ names
• Add Registered Date

The list goes on. The Product Owner can work with the Developers to prioritise these and the team should have a good idea of which are required for the Sprint Goal to be considered achieved and which are there to deliver above and beyond. Each piece of work should pass the INVEST criteria so they can be delivered and provide value individually, but all should help the team achieve the Sprint Goal. Watch out for dependencies between work items, especially the initial ones. The key advantage is that this approach makes it extremely easy to negotiate scope should the team be falling behind their initial forecasts.

Now that we have decided that a Sprint Goal should be represented by a series of pieces of work we can look at the various tools available to us to build confidence that we'll deliver it.

There are three common ways of forecasting using Flow Metrics. These are Cycle Time, Throughput, and a Monte Carlo Simulation. Let’s look at these in a little more detail.

We will most likely have a good range of historical Cycle Time data which could be used to calculate how likely it is that the work will be completed in a given time. However, this information is better suited to estimating when a piece of work will be completed once started. It is can be used to great effect to suggest a sensible Sprint length but will be less helpful for estimating how many of the work items were likely to complete in a Sprint.

We also have Throughput, understanding your historical data here is very powerful in this situation. This echoes from the quote I included above. If we look at our recent Sprints and examine pieces of work that were completed then we can calculate the probability of how many we are likely to complete in this one. Using this we can predict how far through the list of items in our Sprint Goal we’re likely to deliver. Which are very likely, and which are less likely.

For example:

• Sprint 504 - 10
• Sprint 505 - 12
• Sprint 506 - 14
• Sprint 507 - 8
• Sprint 508 - 11

In the previous five Sprints we have completed >= 10 pieces of work 80% of the time. This means we have an 80% confidence that we'll be able to deliver at least that many in the Sprint we are planning. I'd be reluctant to go above 80% confidence with such a small dataset (and more than 5 Sprints could potentially be a very long time with a lot of other factors muddling the data). But you could produce a forecast which looks something like this:

This is where the story of this post takes on an interesting twist (and a reason why I love the ProKanban Community). When I originally drafted this post I had a paragraph in about how it would also be possible to use a Monte Carlo Simulation but how frankly I considered it to be "massive overkill when we have a simpler option available". I finished my draft and asked Prateek to give it a proofread. What resulted was a really fascinating conversation about exactly the topic I'd previously dismissed. For those of you who don't know, Prateek is the Head of Learning and Development at ProKanban and has recently been working with Colleen Johnson and Daniel Vacanti on creating the Applying Flow Metrics for Scrum course to life.

He told me that a lot of work has been going on recently around this problem. When we use the method I described above we're caught between the choice of using a small sample size (of five Sprints for example) or taking a sample over a long period of time (a lot can change over months and months). To counter this the creators of the course are now recommending using your historical daily throughput data to run a Monte Carlo to forecast how many pieces of work the team expects to be able to deliver over the length of the Sprint. This means you can use representative sample data, but also create a decent probabilistic forecast like the one below:

As you can probably tell, I'm really excited by this idea and am itching to apply it to my own projects!

Whichever method you decide to use, at the start of each Sprint the team should identify the new Sprint Goal. Establish the work items which are part of the goal and ensure that they are ready to be worked on as soon as our Definition of Workflow permits. Do not automatically start all the new work on day one of the sprint, this is a pull system after all!

Ok, now that we’ve established how many pieces of work we’re confident that we’ll be able to complete in our Sprint we need to face up to a question all Scrum Teams are used to confronted with. As before, this isn’t a problem that is created because we’re using Scrum and Kanban together, however, the transparency that Flow Metrics give us makes it more apparent how important it is to get right.

Scrum says we do not put the Sprint Goal at risk

No changes are made that would endanger the Sprint Goal;

The Scrum Guide

However Kanban states that we should endeavour to avoid letting work items age. In fact, we know how damaging abandoning work can be to predictability.

More than limiting WIP, more than visualizing work, more than finding bottlenecks (which is not really a Kanban thing anyway), the only question to ask of your Kanban system is are you letting items age needlessly?

The Pocket Kanban Guide

And let’s not forget that removing work from the system destabilises Little’s Law by breaking the assumption that all which is started is completed. For more details see either the Pocket Kanban Guide or The Kanban Guide.

So do we throw our work away and focus on the new Sprint Goal or do we complete it?

Just to reiterate, this isn’t a problem that is introduced by Kanban, however it’s one which is exacerbated because we are now much more aware of our metrics and predictability.

You could argue that working on items that don’t support the current Sprint Goal will put that goal at risk. However, by cancelling them once they’ve been started you’re violating one of the assumptions of Little’s Law and therefore decreasing the likelihood we’ll be able to plan the next goal properly. Therefore, I believe it’s better to finish them and maintain predictability knowing that by doing that you’re helping your ability to plan.

This may mean that some work related to the Sprint Goal is completed after the end of the Sprint, but this is surely better than abandoning all the started work over and over again with the dawn of each new Sprint!

However, one last thing you should be aware of. As a piece of work ages our ability to predict when it will complete decreases. When the work item is started it is just as likely to complete within our SLE as any other piece of work. However the longer it is more active the fewer comparable work items we have to base a forecast on, this increases the probability that the piece of work will exceed our SLE and go on for longer and longer. What I’m saying is that you need to carefully consider any long-running items and prioritise closing them. Don’t just continue to drag work on indefinitely!

Hopefully, I’ve helped you think about how you can use Flow Metrics to aid your Sprint Planning sessions. To summarise:

• Decide how to represent your Sprint Goal
• Understand the likelihood of being able to achieve it using Flow Metrics
• Continue unfinished work into the next Sprint rather than abandoning it
• Avoid work aging indefinitely

I hope this has been of interest to you, a huge thank you to Prateek and the ProKanban community for challenging me and turning this post into such a valuable learning experience for me. If you’re interested in applying Flow Metrics to Scrum Teams make sure you check out the upcoming course on ProKanban.Org.

Author - Adam Griffiths

‍