Visualising Sprint Planning

I heard a fantastic thing today:

"Well, we have a velocity of about 40.... so we should be able to handle three 13 point stories"

Let's explore how this might work using some pictures.

We can start with a box representing our sprint. We start on the left and finish on the right, exactly like a timeline. We have 8 developers on the team, who pair the majority of the time so we can see the sprint divided into 4 parallel streams:

As I blogged about previously, I know my team deliver 13 point stories 10-13 days based in previous history. Visualised, this would look like:

Not a great start.

For the purposes of this blog, I'm going to imagine we have sorted this issue and the team have a track record of delivering 13 point stories within our sprint window of 10 days. So going back to the previous statement, we can view the sprint like this:

First obvious issue, what would the last stream be doing? OK, so we had some spare capacity - according to our velocity we had 4 left over so we could bring in a 5 point story and still be OK. Five point stories are taking about 7 days:

We have a little slack, which is never a bad thing. However something more sinister is going on - these developers will not have many options to deliver this work.

The pairs on 13s will be stuck with that story from beginning to end. Everyone else has a similar problem.

We have 4 stories in play. 3 will probably finish around the same time, which is right at the end of the sprint. We only have 2 developers at the end to help get these stories across the line as far as testing goes. One developer on each story could mean one story is sacrificed.

The numbers and stories 'fit' but this is less than optimal and still pretty scary.

If we can, we aim to finish stories mid sprint. This allows us to mix up the teams skills or to add resource to another story if required. In the previous example, although we could try to do this we risk not delivering the stories at all.

So if we could break down the stories a little, we could also assess risk and decide when to start a story. In the following example, we have a big 13, two 5's and a 3 all in progress:

If everything pan's out the guys working on the 3 will finish in time to help out with both of the 5's or start another story. Alternatively, they could help out with the 13 if we feel there is more risk in that not being completed.

With the 2 fives being complete, we could swarm on another story that we tasked out specifically to allow more people to work on parallel or we could mix up the pairs and pull in 3 smaller stories - probably a 2 and a pair of 3's might fit if we look over our lead times. Merging 2 of the streams and working on 1 story would lower WIP, which reduces lead times which is another option.

Alternatively, we could benefit from a bit of slack and allow the team to evolve their development practices. Seeing that they are no longer working from beginning to end, we have that option also.

All these options start for us in prep and planning. Our choices on how we break up and task out stories allows us to plan how we are going to deliver that work. Just relying on numbers is way to simplistic. Knowing a bit about your leadtimes gives you pretty powerful ways of visualising how the sprint should pan out.

Like photos, sprint composition is an art

A while back I started looking at metrics used in Kanban to better understand some of the patterns I was seeing in my sprints. The change from looking at a sprint velocity to looking at leadtimes for individual stories has been an eye opener.

In particular, I started to look at the composition of sprints rather than just trusting a velocity. The problem I have with velocity is the perceived safety it provides. Estimate stories, add the totals and when you reach something near your velocity you should be good to go.

Imagine this: we have a velocity of about 40 so we should be good to take in four 8 point stories and still have a little room right? This is where leadtimes start to give us a little more information.

My team is quite large, having 8 developers and 2 testers. We generally work in pairs so I see this as 4 parallel development tasks with an additional 2 testing streams. The team work on development and testing in parallel as much as possible - joining up is still a little fun but we get by.

I know from looking at my leadtime data that the average leadtime for an 8 point story is about 6 days. The worst we have turned a 8 point story around in is 9 days, with 4 days being the best. We work in a 2 week sprint cycle, which is realistically 9 days once we take out planning and other ceremonies.

Working with the averages alone, to have a 50% chance of completing all the 8 point stories in the sprint, we would need to start them all by the 4th day of the sprint. If we wanted this to increase to a 85% chance, the leadtime increases to 8 days meaning we would need to start them all on the second day of the sprint.

Here are some of the problems this could introduce:

Higher WIP: With 4 stories that all need to be started within a few days of each other, we force a higher WIP. Higher WIP means longer lead times.

Loss of fluidity/options: With 4 parallel work streams each using a pair of developers, we might find it hard to move people between tasks. We basically end up with a static pairing from the beginning of the sprint to the end. This limits our options or introduces waste where we have to move people around e.g. illness or a specialism that we have not shared yet.

QA 'tsunami': There is a risk that all 4 stories will need QA at around the same time. This might create a bottleneck in testing and slow throughput. If you had some flex in the team, you could get the developers to help with the testing - in this scenario that is probably not an option.

The composition of how that 40 points is reached is as important as the number itself.

Having a mix of smaller and larger stories creates more opportunities for the team to collaborate on delivery. Having stories finish regularly throughout the sprint allows the team to find points at which they can mix up their pairing or help out with other stories in progress. Having this flex allows you to shift responsibilities around the team to help keep stories moving across your board.

If you do have larger stories then look to create tasks during planning that allow a larger number of people to work on the story at the same time. This helps lower your WIP and decrease the leadtime for the story, which will give you more choices as to when you can start the story during the sprint.

Be careful not to overload a story - just putting more people on a story will not make it progress faster, it needs to be a part of the plan.

This might go back as a far as preparation where you could choose to break up stories a little further to allow them to be worked on in parallel during the sprint. You might need to negotiate on the independence of the stories you have broken down but it might save you from negotiating on what you can deliver.

Size (sort of) matters

Recently, I have been keeping a small set of metrics on the stories from my team. I started with simple dates so I could look at leadtimes - the time taken from when we start a story to when we deliver it.

With just these 2 dates you can do a lot! A lot of this came from looking over what was presented by Mattia Battiston at a meetup not so long ago. In particular, I was interested in his observation that there is very little correlation between story sizes and leadtime. This is something I have battled before so I was interested when my own data showed a very similar pattern:

Looking at this you could infer that a 2 point story might take as long as n 8 point story, which is hardly useful. What I missed for a while is the upper bounds across all the story sizes. We have a couple of anomalies at the top but the vast majority are within 10 days - which you should know is the length of our sprints.

That caught my interest. Although we cannot say with any sort of accuracy how long a 5 point story will take - in this example the longest was 26 days and the lowest was 4 days - we can say that 95% of 5 point stories can be delivered within 10 days or less. You can repeat a similar statement for story sizes 8 and below.

So maybe we should revise what we are expecting from our estimation by the team. What we are very good at doing is working out what can deliver within our sprint window. What we actually want to know is how many stories we can expect to be delivered if we want to use this to forecast, which is our throughput.

For me, looking at leadtimes influenced how we were working on and preparing stories. Littles Law describes how we should see a lower leadtime if we lower our WIP. We think more about how more of us can work on a single story, this often starts in prep. We open less and this lowers WIP, decreasing leadtimes.

Having a leadtime which only just fits in a sprint window means we have limited options on how to plan the work in the sprint - we have to start everything on day 1. This would mean loosing fluidity - everyone would be one a single story from beginning to end. Not many options for us at all.

Lowering leadtimes by a few days gives us some flexibility in when we can start stories. We use our story points to influence when we start on things. Larger stories might need to go first but smaller stories run in parallel so that we can deliver throughout the sprint rather than everything at the last minute, which would probably create a bottleneck with testing.

For me the sizes of stories begin to matter less and less. They serve their purpose during prep and planning and help us get to the answer: "Will this fit in our sprint?". When we see a 13 we look to break it down further since we can see it is rarely delivered in less than 10 days, which does not give us enough options. 

If we bring something in mid-sprint, we can look at the previous leadtimes and give a percentage "75% of previous 5 point stories have been completed in the time we have left" allowing us to make a commitment with some accuracy on success.

There are many more interesting things you can gleen from leadtimes and some basic spreadsheet fun, Mattia's presentation is a great place to start.

Symbols not words

It is rare that something I try just works but this is something that was simple and helped one of my teams.

We were finding it awkward to track the overall state of a story on our manual board. Without this it was easy to miss something interesting during the stand up and even more difficult for the business to look at the board and understand what we were working on.

The team always talked about 'bringing an item into play' so I started to use a CD/DVD play symbol to indicate the items we were currently working on. This quickly evolved to use the stop symbol to show a story had not been started yet, a pause symbol to show the story had something blocking it and eventually a fast forward symbol to indicate that the team were swarming on that single story. Once we used the eject symbol when a story was pulled from the sprint due to a really late change in customer requirements.

It seems almost trivial, but the mere fact we could see the state of all the stories on the board helped with:

1) WIP - before it was too easy to start working on something without finishing something else. There were several instances where we had a high WIP and some items could not be done by the end of the sprint. Being able to see status of the board pretty much stopped this overnight. Never quite understood why but the added visibility meant it was much more difficult to hide opening another story, allowing the team to form and keep an agreement on WIP.

2) Stand ups - we focus the stand up on the 'in play' stories, drilling into each one and organising the day around closing them. We often update the symbols to reflect what we agree to do for the day e.g. pausing a story so we can swarm on another one if we feel it is stuck and we won't incur waste in doing so.

3) Waste - the states of the story give clues to any waste that might be happening during development. If a story is paused - do we have a delay or hand-off? If a story is in play but seems to be stuck in a particular phase of development - maybe we have re-learning happening? If we have to play a paused story - maybe we should be looking for task switching? I can ask questions that help the team see waste and record it more accurately but the clue's start with status of the story.

We have also used padlocks to indicate if something should not be touched - happens occasionally if we are working on anything that needs approval by the organisation but we are slightly ahead of the curve and have already planned the item.

The key observation is that everyone 'gets' these symbols. They convey specific information quickly and easily with no training required. They drive team conversations and most importantly, the team has adopted them which is probably the best endorsement you can get.