Agile Business Change Blog Thoughts on Agile Strategic Business Change and Agile Delivery

Tweet

Mail

So here I am again faced with the observation, from a retrospective, that two weeks is too short for a sprint. The stories that are being developed are taking too long and the team don’t think enough is being completed in a sprint.

Well, my first reaction was well done to the team for being concerned. They wanted a representative velocity and were concerned with stories rolling over to the next sprint not representing the contribution to an unfinished story being made in the sprint where it was made. But we don’t give credit for half completed stories. Well we could in a way using what we have called Optimistic Velocity, but that’s for another post. So the real problem was getting stories completed in the sprint.

So is the answer to increase the sprint duration to we can get the stories completed? Probably not. The way I see it, it’s probably not the sprint that is too short, it’s down to ‘batch size’ being too big.  This is usually down to one of a few things or possibly a combination of them all.

Firstly and most likely, the stories are too big. I can’t say that writing short stories is easy, especially for new teams, but failing to get them down to a small enough size will result in inconsistent velocity across sprints. This is certainly a matter of experience and looking for ways to ‘shave’ or ‘split’ stories to create something suitably small. There is always a claim that making them too small is ‘inefficient’, but I would claim that’s measuring progress against a different ruler than we want. Having large volumes of untested code developed and delivered for test is not the approach we want to take. Getting people to understand the value of small batches is key, even if the unit cost per feature takes a development performance hit. The incremental feedback and story validation will more than compensate for this cost.

The second potential problem is the development process itself.  How long does it take to get a story physically though the development and testing environments? When using older languages and infrastructures more suited to large batch delivery just getting the story though the environments can take a long time. Recompiling big COBOL systems and packaging for deployment for example doesn’t happen quickly. This is especially true when the existing procedures are designed for doing one release every 6 months and not several a day. When the first sprints are run, this is usually an area that becomes a resource sink until something is at least partly automated.

The third issue is that the stories were not really ready to play when accepted into the sprint. This can result in extended periods of analysis and design as part of the story development which results in too many blockages and not enough flow of completed stories. This again is damn hard to get right initially. We accept that ‘sufficient’ upfront analysis and design is acceptable, but getting ‘sufficient’ prepared at a story level is always hard. In my experience this is usually initially too much because that what people are used to or not enough because there is pressure to get coding. A good way to ‘test’ this is to have a review of a completed story after the sprint and walk it though to see how it played out. When there wasn’t enough prep done it’s usually obvious, but too much prep is harder to find. I usually ask devs and testers to review the prep material and cross out what wasn’t really needed or contribute to the story completion. This can result is some surprised faces.

So, the stories in this case were taking longer than hoped for because of all three issues to some extent.

So I think if you are hearing the ‘sprint is too short’ you are most likely hearing a symptom of a behaviour or working practice that needs to be addressed.

I am not saying that you can always get teams down to two weeks, but I would feel ‘beaten’ if I couldn’t achieve it and would strive to attain what in the vast majority of cases is totally achievable.