A discussion arose the other day about why we like to break down stories into smaller ones. It arose during a backlog grooming session, in which the team was looking at the forthcoming work and assessing its suitability for next iteration. It was proposed that one particular medium-sized story be broken into a couple of smaller ones, and the question was asked if that was worthwhile.
Here are a couple of reasons which I think aren’t correct:
- Because it helps us deliver more points;
- Because it gives us a smoother burn-down chart.
These aren’t bad things to have, and they are consequences of breaking down stories, but they are not the primary reasons. Ultimately our purpose is not delivering points and generating burn-down charts—our purpose is delivering software, and doing that in a sustainable manner.
The real reason we prefer smaller stories is that it helps us deliver working software sooner, which provides a tighter feedback loop, and we can use that to steer us better.
It’s better to deliver 100% of two small stories out of three than not delivering one larger single story even though it’s 66% done. With those two stories—seen working, and ideally in live use—we can recalibrate any future requirements, and we can do that sooner rather than later. That may mean changing what we were going to deliver, or changing the sequence what’s already planned. Either way, it’s all about delivering a satisfactory system sooner.
Points and charts are artifacts that allow us to achieve our end goal, but we should not confuse those artifacts with our primary goal of delivering working software sustainably.