Recently, a friend and I had a discussion about splitting larger user stories into smaller ones. We disagreed on whether or not a particular five-point story could be broken down into a handful of smaller ones. My friend argued that a five-point story was by definition divisible into smaller stories. The body of work in the larger story could be chunked out into smaller units each qualified as a standalone story. His comments highlighted for me a fundamental difference in how to approach software estimation.
Most of my experience is in an agile methodology called scrum. In a scrum approach, the set of known requirements and specifications for a software product are broken down into something called a “user story.” User stories are a short narrative designed to convey the interaction between some actor (e.g., a sales clerk) and some software system (e.g. point of sales application). User stories typically take on the form of “As a sales clerk, when I scan a UPC code, the item is added to the customer’s bill, so that we receive the correct payment.” In my opinion, the fundamental requirement of a good user story is user-deliverable value. If we subscribe to this argument, then a user story becomes the smallest unit of work worth doing.
We collect these user stories into something called a Backlog. We can think of the backlog as a to-do list. We know we’ve finished the project whenever the backlog is empty of user stories. The business’s priority dictates the order of items on this to-do list. When I say business, I mean the people who have a stake in the success of the project – the people who sign my paycheck.
As a software developer, it is my job to translate these user stories into working software. By working software, I mean software that is actively used by customers. The members of my team and I can only deliver a limited amount of working software at a time. To help organize our work, we choose to constrain our working hours in timeboxes termed iterations or sprints. Each sprint, we take user stories from the backlog and put them into a smaller, more focused to-do list called a sprint log. The number of stories we can fit into the sprint log (i.e. how much work we can do) is the quotient of how much effort it takes to complete the stories in the amount of time in our iteration. But not all stories are created equal. Some stories are ‘bigger’ or ‘harder’ than other stories. We need a way to measure the difference in the effort it takes to complete those stories. We call that measure a story point.
Story points are unitless; dimensionless values typically somewhere within the Fibonacci sequence, but that’s not a requirement. Many developers prefer the Fibonacci sequence for reasons I won’t go into here. Story points on their own are meaningless. To say a story is a 3 or 5 or even 15 story points doesn’t mean much. Story points become valuable as a tool to compare one story to another.
We can do this by assigning an arbitrary value to an initial story. As a team, while planning for a new iteration, we agree on a convention that Story A would take three story points of effort to deliver as working software. If we believe we can complete Story A five times by the end of the iteration, we can establish a baseline. We can call this baseline our team’s velocity.
By knowing how big a story is and how many of those stories we can complete, we can use this information to estimate additional work. We can ask questions like how much bigger or smaller is Story B than Story A? If, I can’t fit Story A, Story B, and Story C in my iteration and I take out Story C, can I complete Story D, Story E, and Story F?
So, how does this differ from my friend’s views on estimation? The difference is the purpose of the story point. I see the story points associated with the story as the relative measure of effort to deliver the smallest unit of value to a customer. Breaking a story point up purely by story point magnitude ignores the point of the story.
In my previous example of the sales clerk, my friend and I agreed on this story as five points of effort. My friend argued that scanning the UPC code, appending the item to the to the customer’s bill, and summing the total amount should be one three-point story and two, one point stories respectively. This method uses story points as a splitting heuristic and on the surface can seem like a sound approach. The question I put to my friend is: “If we delivered each of these chunks of software to the clerk separately, would that get him or her paid any more accurately or any more quickly?”
Not only does this not help our customer but is also creates unnecessary dependencies between the three resulting stories forcing us to complete them in a specific order. We would naturally want to put three developers on these stories in parallel, but in practice, this isn’t possible. The re-integration of source code from three stories would be a nightmare. The three developers would have necessarily changed the same files, and this is a recipe for merge conflict hell. Sound familiar to anyone?
My point here is if you find that a story is too big for your liking and you want to see if you can break it down, search for the sources of value. If you can find multiple value statements (e.g., “… so that I get paid correctly”) then use that as your splitting point and estimate from there. Coming at the problem from the other direction will undermine your ability to deliver useful software to your customers.