During my last couple of planning meetings, I started asking the question “Can we break this story up?”. I have been getting pushback from developers with questions like:
- “Does the story really need to be broken down?
- “Why can’t we add a bunch of tasks to the story instead of breaking it up?”
- “Isn’t it the same amount of work, but we are just breaking it up?”
During this post, I will explain why it is important to keep story sizes small.
Why?
The main reason I like to split stories is increasing throughput and reducing the cycle time of a story. (time completed – time started). Time is always a constraint. Either we need to meet a customer promise or beat a competitor to market or the budget is going to run out on a certain date. Time is never unlimited.
Our Development Process
Before jumping into an example let me explain our Jira board
We have five columns for Stories. To Do -> Dev -> Review -> QA -> Done. When we start a story, we create a feature branch off of master. When the work is complete in Dev we move the ticket into Review and submit a pull request. The code is reviewed and approved by at least two people. Then the code is merged into master and a CI system runs tests and deploys to an integration server. Then the ticket is moved into QA. Manual testing is done then the story is moved to resolved.
Reducing Cycle Time and Increasing Throughput
OK, so how does splitting up the work into smaller stories reduce cycle time and increase throughput? Let’s assume that if we have a large story and broke it up into two small stories that it would be the same amount of work.
If the original larger story took 23 workdays total cycle time
The 2 smaller stories would be 13 workdays
I realize this may be an extreme case. But by breaking up the story we were able to get something valuable to QA to test earlier than we did in the first example. In other words, we reduced the time QA was waiting for work, which is one of the 8 wastes of Lean Software Development.
Additional Benefits
- Tightens feedback loops with product stakeholders – Reduces the risk that developers are building the wrong thing.
- Increases quality – smaller stories means it is less likely that we “forget” to do something, like test (j/k)
- Reduces waste – By getting stories through the board quicker, it reduces the time works waits to be worked on. In addition, it reduces the amount of wait time downstream processes like QA have to wait for work
- Predictability – I strive to make stories about-the-same-size. If stories are similar size then it is easy to calculate when you will be done with a feature by calculating the end date using throughput.
- Rhythm – Finishing small stories creates momentum.
Pitfalls
- Negative impact on quality – Without thinking about the overall design and architecture of the code, then you can get into trouble and design yourself into a corner. Thus having to refactor or rework parts of the code when implementing future stories.
- Smaller stories do not add value to the user – I typically use INVEST as a framework for sizing stories
