by Suzanne Erin on May 30, 2019

In software development, before any code can be written, you begin by gathering requirements. The clearer the requirements, the better the code reflecting those requirements will be. Writing quality user stories is an important first step towards setting development up for success. What is one way to make sure that the user stories are good? Make them small.

Small stories are easier to talk about and get your head around. A large story has room for vagueness. You either risk making wrong assumptions or you spend time coming back for clarification again and again. A small story lets you have focused discussion around the specifics of a single behavior.

It is easier to write a test for a small story than a big story. Testing a single behavior of the system will be more straightforward than testing a complex set of interactions. Small stories facilitate high test coverage with meaningful tests. Similarly, the requirements for acceptance will be clearer in a small story.

Big stories lead to big commits. Big commits are harder to review. If a bug pops up after a small commit, you’ll know where to look. If a bug arises after a big commit, have fun figuring out where the issue was.

Imagine you’re a developer working on a big complicated feature. Every day at stand-up, you report “I’m still working on the big feature”. The stakeholders begin to get antsy. They’re not sure if you’re making progress. You’re not sure if you’re making progress. Every time you think you’ll be ready to deliver soon, you discover an aspect of the feature no one thought about yet. You’ve “gone dark.” Breaking big features down into small stories will allow you to chart a path forward and mark your progress, so no one is lost in the dark.

If you have a big feature, how do you know how big it really is? Break it down into small stories to capture all of its dimensions. Having more pieces allows prioritization and enables discussion about if and how to simplify. It makes it easier to identify pieces that could be saved for later.

Big stories are lumbering; small stories are spry. Small stories are at the heart of what it means to be agile. Agility is about responding nimbly, being ready to switch gears when the situation changes or when things simply don’t come out right. Small stories put you in a position to pivot. They allow you to deliver and deploy more frequently, which means that you can start generating value and feedback sooner. Small stories make agility possible.

Imagine that you are building an app, and the stakeholder wants to add some "social" features. The stakeholder might say:

"I want the user to be able to like posts"

So, they might add to the backlog:

User likes a post

This isn't a small story. It's bigger than it looks. What does it mean to like a post? A developer or product manager just working from those few words would either have to make a few assumptions to answer that question, or spend time gathering more details about the requirements.

A user story is small if it is focused on a specific interaction between the user and the system. This reduces ambiguity. You can make sure user stories are small by walking through each part of the user experience, step by step. What does the user do next? How does the system respond? Each user story consists of a user action, and a system reaction. A story can be as small as a single such interaction.

The above feature could be rewritten as:

Given I’m a user
And I’m viewing a post
When I select the heart icon
Then I see the number by the heart increment by 1
And I see the heart turn red

The story is written so that it can serve as testing instructions and acceptance criteria. It is written from the user’s perspective, describing the user’s actions and how the app behaves in response. It uses the stakeholder's domain language to make sure everyone understands all the details. By continuing to walk though the subsequent steps of the user experience with the stakeholder, you can uncover different paths and edge cases. In the “liking posts” example, you might follow-up by asking:

Can the user like the post more than one time?
What if they leave and come back later?
Do other users see the number of likes incrementing?
Can users see who liked what when?
Does a user need to be logged-in to like a post?

These questions might generate more small stories. Then, everyone will have a better understanding of the scope of the ask, and the stakeholder can make decisions about which aspects are important.

A small story doesn’t necessarily mean that it is a simple story or a short story. It just means that it is focused on a single interaction, in a particular set of circumstances. A single-interaction user story might still be pretty lengthy. You may need to list a long set of preconditions that describe the scenario. The reaction it elicits from the system might be quite complex. In order to fully capture a feature, you may need to use multiple stories. By focusing on one interaction step at a time, you are in a better position to suss out the details.

At Hashrocket we write an initial set of user stories in a storycarding session. We start the discussion by talking at a high level about the functionality of an app. Then we walk through the user experience step-by-step, being sure to explore happy paths, sad paths, and edge cases. This ensures that the intended behavior is accurately captured at a granular level, and helps uncover otherwise unanticipated scope.

Successfully creating and enjoying the benefits of small stories demands frequent and quality communication. Both developers and product owners or stakeholders should be involved in the discussion at creation. The stories represent an agreement about the intended functionality of the app. The benefits of transparency, scope illumination, and agility will only come about if stories are part of a communicative and iterative process that connects developers to stakeholders regularly. At Hashrocket, we take advantage of the benefits of small stories by having daily stand-ups, frequent delivery, and a healthy feedback loop.

Image by: Iker Urteaga