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.

"3 Strikes" Quality Monitoring

This concept came about through discussion about how Defect waste should be measured. There are a load of posts on the 7 wastes, which I will not go into now but this started a discussion that led to something interesting.

We found 3 different gates which we think could be used to actively monitor the quality of our organisations products and development processes:

1) Defect Waste - This is a measure that is purely within our sprint. If we are working on something new and we find a defect with it in our sprint during QA, we label the time to resolve the issue as defect waste. This may seem harsh but it has interrupted our flow through the development process. We had complete acceptance criteria and access to the domain knowledge that created it - so in an ideal world this should never happen.

This a symptom of other problems e.g. are developers buying into the acceptance criteria, are the criteria strong enough, are the developers even reading the criteria? This also encompasses questions around the effectiveness of regression and automation suites, which is another area the team can improve on.

2) Release Testing - A series of teams all feed into a release, which is where we realise an integrated version of our application. We typically run automated suites and exploratory testing here, ideally this is built from tests created by the teams in addition to system level tests. Anything we discover here is irritating since we now need to fix it before we can release.

I find this hard to monitor since the issues raised look like any other issue and it is difficult to pick them out - ideally we are only interested in stuff raised during testing and dates are the only data I can currently rely on. It symbolises complexities around integrating work from multiple teams and possibly improvements for teams in terms of DoD depending on the problems found.

3) Bug Reports from Customers - The last place a bug will be found is by the customer, which means the organisation has failed! It should not make it this far but that does not mean we cannot learn from it. The number of the issues being raised by the customer can be used as the final gated measure.

It has evaded both of the other gates so may well be down to customer specific data or configuration. It might inform how we guard against regression for specific customers who are using features that might be specific to them or rarely used.

These 3 measures can be used to monitor trends. Ideally, we would see all of these trending towards zero in every sprint, every release and for every customer. The combination of the 3 gates tells us more about about how we treat quality throughout the development process.

By making these measures visible we can also start to re-focus the development teams on a wider view of what we term as quality for the products we build.

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.