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.
No comments:
Post a Comment