The Road to Small User Stories
By: Dan Pincu
Tags: User Stories, Scrum, Breaking, Agile

Photo by Damir Spanic on Unsplash

Breaking stuff is fun

The team decided to tackle these big USs and find a way to handle them better. But how do you do that? The USs were already broken into smaller pieces (sub-tasks), but it didn’t change the fact that the US itself was still big. The idea was to consciously strive to reach USs that are as small as possible. It took some time and work, and this is the process the team put together:

Dedicate a day for the sprint planning

While a standard in Scrum, not everybody uses it. The team found that every minute invested in planning is well worth the development time that is “lost”.

Define a clear DoD (Definition of Done) for each US

Pretty straight forward, but also crucial. In order to write a good, detailed DoD the team must fully understand the requirements, which raises the accuracy of the estimation.

Switch to time-based estimations

The team found it much easier to work with time units for the small USs. When you reach the point of estimating the actual work, and not just a rough estimation of complexity and size, units of days or hours will be easier to work with. It also gives you more flexibility, because you can define a US that only requires a few hours of work.



Note that for rough estimation before breaking, the team is still using abstract units (specifically T-shirt size).

Aim for USs that are 1–2 days in size

How do you keep your US that small? Suppose you analyze a story and estimate it at 5 days work. You can’t just break it in half right? You’ll end up with two stories that don’t have value on their own. That’s probably true from the product perspective, but it doesn’t mean they have no value at all.



This is the crucial point to understand — many people will tell you that a US must have a value for the customer, but that’s not true. It’s perfectly fine to have a US that is valuable to your team, or maybe to another team you’re working with on the requirement. As long as you keep the product requirement in sight, go ahead and define as many no-immediate-value-to-the-end-customer USs as you need.

Define a maximum size for a US

This is just a guideline to help achieve the previous goal. The team defined a max size of 3 days. If a story is bigger after breaking and estimations, you look for a sub-task (or several) that have enough value on their own, and create a new story from them.

Photo by Ruthson Zimmerman on Unsplash

Enough theory, let’s talk business

Examples are always great, so let’s look at one.

Say your team is developing a web application, and you get a requirement to add filtering to an existing page. The team estimates it’ll take 7 days overall — that’s a big US, even if developing the two parts in parallel.

How would the sub-tasks look? Probably something like this:

Add filtering to REST interface (server) Validate input (server) Implement filtering logic (server) Add filtering controls (UI) Handle user selection (UI) Add selected filters to server request (UI)

No doubt you need all of these to get the product value — the feature won’t work without all parts. Now consider we break the big story to these smaller stories (each of these is 2 days work or less):

Build client-server integration

Add only the REST interface, filtering logic uses hardcoded values, UI sends hardcoded filters Handle a single filter

Server supports one filter type at a time, UI sends only one filter at once Handle combined filtering

Implement all filtering logic, UI sends all selected filters Add error handling

Add server validation, UI handles error response Add UI styling

Finalize UI according to visual design

See the gradual value? The first US reduces risk and opens the way for the parallel development of UI and server, with low risk of breaking the integration. From there, we just add a small part of the overall functionality with each additional US. You can also split them into explicit client/server USs.

Yeah, but does it work?

Back to our team — how did their sprints look with the new process? Let’s check one example:

A whole new story! We can clearly see that work items are closed daily, showing continuous progress throughout the sprint. The team is much happier now.

You might notice small increments in the graph here and there — these are estimation updates the team makes for USs that took longer then estimated. In the retro meeting, the team discussed these to find out what happened.

It’s nice to note that these changes don’t have any negative effect on the sprint. They’re often no bigger than half a day, and some updates reduce the estimation, so they tend to cancel each other out. This is another advantage of small USs.