Good post over on the Agile Business Change Blog by Stan Wade about a very common problem: Teams continue to fail to get stories done in a single sprint and by default believe that their sprint is too short. Stan points out three potential problems other than sprint length and gives a good overview.
- Stories are too big.
- It takes too long to get something completely through the process.
- Stories aren’t really ready to begin with.
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.
In my experience, if you can’t complete a 2 week sprint, you probably won’t be able to complete a 4 week sprint either. Very often (but not always), teams struggling with a 2 week sprint are struggling because they are trying to do waterfall inside the sprint. This is difficult, but still possible somewhat, in a 2 week sprint. So my general advice is always switch to a 1 week sprint. This will put more strain on the process and cause you to look more carefully at how work moves through the process and improve that.
Read more here…
