No matter what team I’m a part of or what meeting I’m in, the topic of smaller user stories is regularly broached. The reason? Because it is really important. At the same time, smallerizing stories can be quite challenging. However, as challenging as it can be, it is well worth the effort. Here are some reasons why I think it is beneficial to create small user stories.
Small user stories are more clear
When stories are large, there is more information contained in the description and more acceptance criteria to be considered. Sometimes this can be too much to wrap your head around. For example, when there are about three stories worth of information contained in one story, it’s harder to understand the scope and chances are that there will be multiple dependencies introduced. When stories are small, they are easier to understand which allows you to focus on what is right in front of you.
Small user stories are easier to estimate
Going hand in hand with smaller stories being easier to understand is that smaller stories are easier to estimate accurately. Would it be easier to guess the weight of an elephant or a cat? I recently conducted a small survey asking people to estimate those weights and each time the estimate for the cat is much, much closer. Try it yourself. You can also see this in the Fibonacci sequence that is commonly used in Agile estimating. As the numbers get larger, there is more room between them which indicates more ambiguity and less precision. 1, 2, 3, 5, 8, 13… these numbers are all pretty close to one another… 21, 34, 55, 89, 144… not so much.
Small user stories introduce less risk into the sprint
Have you been part of a team that had a 21 point story carry over to the next sprint? It was almost done, but not quite. At the sprint review, the stakeholders are now a bit disappointed because they were hoping to see that new checkout flow they’ve been dreaming about for the past two weeks. Imagine if the team had broken the story out into 4 or 5 smaller stories, for example. The stakeholders would have loved to see how the user can add an item to their cart and then add their credit card, even if they didn’t get to see the confirmation screen and email. But now they are sad and wonder why they attended the review in the first place.
Small user stories increase the workflow
Maintaining a steady workflow is important to help the team get in a rythym and avoid bottlenecks. Perhaps you’ve witnessed a large user story stuck in progress for over a week while Johnny QA is twiddling his thumbs and tapping his foot just waiting for the chance to find those bugs. Smaller stories lead to a better workflow and less bottlenecks, which lead to better team productivity.
Small user stories help shorten the feedback loop
When user stories are smaller, they are completed faster, therefore providing the Product Owner and other stakeholders the opportunity to provide feedback more often. When the team receives feedback more often, they can be ensured that they are working on the right stories, which in turn, ensures that the correct product is being built.
Can user stories be too small?
Yes, definitely. I remember one team in particular that I was on where the size of stories was discussed in the sprint retrospective. The team all agreed that the stories needed to be smaller. The next retrospective, we were discussing that the stories were too small. So, even though it is beneficial to have small stories, beware of making them too small. For example, if you are changing the size and color of 5 headers on a page, it’s probably overkill to have 5 separate stories for that. The overhead of creating and moving the stickies or updating the tool is probably more work than actually updating the headers.
To sum it up, small user stories provide clear benefits and add more value than larger user stories. However, breaking stories down is not as easy as it sounds and the team needs to work together to find the right size. It takes team collaboration and it takes practice. But it’s worth it, so give it a shot with your next batch of user stories.