Factors affecting WIP (2)

Velocity is a key metric for an agile team but when considering WIP it may give us a “limit” for the team but we still need to take into account whether several team members can work on a story and the story size. We may have a true agile “feature team” where any team member can work on any story but there may often be a division between discipline, knowledge or just “that’s how we do things”.

Let’s say that we have an Agile feature team of eight people and a velocity of 40. What does that tell us about our WIP? Let’s assume that any number of our team can work on any of the stories – we know that based on our velocity we could expect the team to complete eight 5sp stories and that would maintain our velocity of 40. What about two 21sp stories? It’s a reasonable stretch in terms of velocity (42) so that shouldn’t be an issue. But can we expect a team to work on two 21sp stories as effectively as eight 5sp stories knowing that the 21sp stories contain more complexity and risk?

Let’s say that we complete seven of the 5sp stories so our velocity for this iteration is 35. If we fail to complete one 21sp story then our velocity is 21, just over half what it previously was. So, we can expect our velocity to be more variable if we attempt larger stories as the impact on our velocity is greater. In terms of flow – for the first example we’ve completed seven items and in the second example just one.

In terms of value it’s more difficult to say, if we required all eight 5sp stories to complete the feature then we may not be able to satisfactorily demonstrate the feature. Then again, assuming that each story provides an end-to-end capability then we could expect some value from completing seven 5sp stories. We may get some value from one 21sp story but we’re more likely to be missing something that was to be provided by the other 21sp story.

When looking at our WIP we can’t really consider each story to be a “unit” unless they are all of a similar size. If we have all stories of a similar size then perhaps we can move towards a “flow unit” style calculation but in order to achieve this are we sizing stories arbitrarily rather than considering them to be an end-to-end piece of functionality? If we accept that stories will be of different sizes then we can expect smaller stories to be completed quicker and more predictably than larger stories – although provided that they are completed within an iteration then it shouldn’t matter.