The Road to Small User Stories
One of the most important aspects of agile methodology is breaking requirements into smaller pieces. For development teams, this usually means breaking the user story (US) defined by the product owner (PO). If you were ever a member of a dev team practicing agile, you know that this is easier said than done.
Let me tell you a story about a team that, like many others, had its challenges with this issue and managed to learn a lot in the process.
Where we started
Our agile team started as a medium size team of 5 members, practicing Scrum with 2-week-long sprints. Mostly the team was working on one major feature in each sprint, and a few other small tasks.
The sprint planning process went like this:
- Receive a requirement from the PO (not part of the team) in the form of a user story
- Analyze the requirement, break it down into smaller work items (sub-tasks) and estimate each one, using story points (SP)
- Plan the sprint, based on these estimations
The result of this process was that most USs were at least 3–4 days long, sometimes more. But they still fit into a single sprint, so no problem, right?
Wrong. Let’s look deeper to understand why.
Tell me where it hurts
We begin our analysis by looking at the burndown chart of a sprint that was planned as described above:
Not a pretty sight. Except for one or two work items that were completed in the first day, it took the team more than a week until the next US was delivered. Toward the end of the sprint there’s a sudden drop — either many work items were completed together, or more likely, one or two very large ones were.
So, what happened here?
The sprint started with 8 stories estimated at 16SP, which isn’t bad. But 3 of them summed up to 9SP, so things weren’t well balanced. No wonder it took so long until real progress was made.
While most of the work was completed in this sprint, the team was not happy. It’s hard to plan the next sprint, when you need to figure out how much work remains from the previous one. It’s hard to do a retro, and discuss what happened with a big US, while it’s still in progress. Doing it in the next sprint is even harder, because who remembers what happened four weeks ago?!
When this happens in a sprint here and there it’s not too bad. But when this is the default scenario, you get long term consequences, such as delays in delivery, and you can’t really trust your planning.
The team members asked themselves — can we do it better? What can we change in the process to increase our effectiveness?
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.
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.
So, what have we learned?
We learned that there’s always more then one way to do something. We learned that if something doesn’t work well for you, you should look for alternative solutions, and we learned that you must do it continuously.
The change described here wasn’t done in a day; it took several months. Each time the team changed and improved a different aspect of the process, and they continue to do so.
One of the things I love most about agile is that there’s no “right way” to do it — you make your own rules. The concept described here is just one approach. It works well for my team but won’t necessarily be the same for yours. If you’re struggling with sprint planning and US breakdown, try different solutions, experiment, and keep looking for ways to improve your work procedures.
