Thursday, 13 August 2015

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.

Monday, 3 August 2015

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.