In January, I wrote a little bit about how to do a better job slicing up stories. In my experience, there is always a healthy amount of debate around what size a story should be. Should we make this a 3 or a 5, a 5 or an 8? Inevitably we have to revisit the question of what a point even means. Are we talking about hours of work or difficult or ideal work days (whatever that means)? I don’t think these conversations are terrible useful unless we are intentionally driving to make a piece of work smaller.
So, that begs the question of why do I care whether or not a piece of work is smaller?
The normal reasoning on this comes from the business side of things. My managers at every previous company since the beginning of time wanted to know exactly when, to the hour if they could, a feature would be ready to ship to production. Contracts and more importantly, bonuses, are forged in the cauldron of on time delivery prediction. Those predictions are always wrong, I don’t really care about them.
I do care about the affect stories have on software development though.
Certainty and Isolation
The biggest benefit I can think of is knowing absolutely 100% for sure, or as close to that as we can get, what we are supposed to develop. Years ago, I was working on an change that was supposed to graph the age of people based on certain demographics. This one change request covered processing data, building custom queries on the fly based on a demographic (diabetes patients for example), displaying the data on a graph, and generating the data in CSV format.
That sounds reasonable as a feature, it covers the full workflow. As a feature request, it’s garbage. I started testing by creating a lot of data that covered several years of patients. Some very old, some very young, and some with bad data (I am a tester after all). The bad data made the browser hang. Data for the very old patients displayed off the graph and overlapped other controls on the web page. Data for the very young patients didn’t display at all.
When stories are too big, we forget important details (even when we talk about them or they are outlined in a spec), and we make assumptions to fill in the gaps where information is missing. That story could have easily been broken down into separate stories for the graph, for data processing, for creating test data or getting real customer data, for data export, and a new story for each little piece of functionality contained in the workflow.
It sounds like over kill, but there is a point. Smaller and smaller stories make it easier to ask questions and expose problems. Every thing we do in software is under time pressure, the software has to go to production at some point. We can talk about a large change like the one I mentioned in an hour and feel like we have a pretty good understanding. Once development starts, we have no clue what it means to be done, and then there is a ton of back and forth between testing and fixing activities.
Making small stories isn’t important because it builds a more predictable sprint. It is important because it helps us to ask and answer important questions up front that help us know what done really means. Getting predictable feature flow is a side affect of that.