User stories are one of the most basic, but essential, components of the Agile framework. They’re how a product owner or stakeholder expresses the functionality needs of a project, and they help the development team understand why they’re building what they’re building. One of the most important parts of the user story is its size, or work effort, which is determined by the team. Story sizing helps you decide what to plan in a sprint or better manage work-in-progress, depending on the Agile framework your team is using.
Story sizing is surprisingly hard, so it’s important to do what you can to make it easier on yourself and the team. Writing one story documenting all your requirements may be easy for you, but it makes it more difficult for the development team to know how much work it will take to meet all those requirements. Put simply, the larger a user story is the harder it is to estimate confidently, and accurate estimations are the key to planning and keeping your project on track.
Think of smaller stories as a risk mitigation strategy: you’ll be able to estimate and plan the work better, and you’re much less likely to have an entire sprint hinging on one big story. Smaller stories are focused, making it easy for the development team to understand what they’re supposed to deliver.
Smaller stories also mean you regularly have things flowing from to do through to done. You may have 10 stories in a sprint, 9 get done and 1 is held up. Your stories should be sized so that they could deliver value individually. You probably wouldn’t release each one on its own, but in theory, you could release the 9 ready stories and see a benefit.
In general, a user story should take about a day of development. There’s wiggle room there, but if you’re looking at more than 2 days of development you’re getting into too-big territory; it’s likely the scope is too wide or there are too many requirements.
If you reevaluate and decide you have too much stuff you’re trying to get out of a single user story, try thinking about it in slices of functionality. For example, maybe the original was for a form that includes calculations and auto-populates information from a database. Consider breaking these things out: a story for the existence of the form and form fields, stories for the individual calculations, a story to connect to the database to retrieve the data, a story for date picker functionality, et cetera. These things individually should be much easier to gauge a level of effort on, whereas the original story would likely have been a shot in the dark.
Now you’re thinking, is there a such thing as too small?
Technically speaking, user stories that are too small wouldn’t deliver any business value. For example, you have a story to change the font size on the homepage from 10 to 12. This might take next to no time to do, and there’s not really any tangible value to it, but there is a reason it’s being requested. Even if the only payoff is making a stakeholder happy it should be worth it. The caveat here is that you shouldn’t push aside more important work for something like this!
The major drawback to have a bunch of tiny stories is the management of said stories is going to waste a lot of time. If you’re doing backlog refinement and sprint planning you’re going to have to walk through every one of those user stories individually to make sure there aren’t any questions. Plus, your sprint and backlog are going to wind up with way too many items to keep track of!
If you do end up with stories that you think are too small, think about if the stories seem more like individual acceptance criteria for a main story. If so, it’s easy to combine a couple to make one meaningful story.
Getting to the point of right-sized user stories requires practice and trust. It may take a while for a product owner to get used to breaking stories down into smaller chunks if they’re used to big stories. If a team is new it might be some time before they’re able to confidently size most user stories. But it’s important that the team is able to pump the brakes if they’re unsure or think a story is too big, and the product owner has to trust their judgement, be able to answer any questions they have, and commit to reworking the story if it really is too big.