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.

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.