A small story is easier to understand than a big story.
It’s easier to have a crisp definition of done for a small story than for a big one.
It’s easier to review a pull request for a small story than for a big story.
It’s less risky to deploy a small story than a big one.
Small stories couple with frequent deployments make it easier to maintain dev/prod parity.
Cycle time is smaller for small stories than big ones. This means less need to do sub-branches off of feature branches.
“But not everything can be small”
Maybe that’s true. Not every story can be small but it can at least be as small as possible.
And in my experience most development teams stop whittling down stories well before they reach “as small as possible”.
Here’s an example of a time I saw a big piece of work made into small parts. I once worked on a set of stories that involved renaming a concept from “sellable” and “unsellable” to “for sale” and “not for sale”. One of the first stories our team implemented and deployed was to simply rename the database table’s column and some of the referencing code.
The story didn’t involve changing the UI. We didn’t even change our API endpoints to reflect the new name. Most teams would probably consider this level of granularity to be silly, but we found it prudent to spread the work across as many small stories (and deployments) as possible to minimize the risk that any one deployment would cause a problem. Usually, a way can be found to make things small.
The story in this example feels more like a task to me, and it does matter what you call it, because you can otherwise lose focus on what the user wants and start just building stuff for the sake of building stuff.
I was first exposed to “agile” in 2006 when working as an intern on a team that did “Extreme Programming” (XP). At that time, I came away with this mental model of user stories and tasks:
1. A user story represents something the user wants the system to do, so that they can achieve a specific goal.
2. A task is a piece of work that (hopefully) implements some user story. Or it could just be required for technical reasons (e.g. fixing a bug, improving a slow database query or refactoring some code that nobody likes).
3. We didn’t talk about “epics”. That might be a more recent thing, or we just didn’t bother with that idea.
I noticed you keep writing “story” and not “user story”, and the way you’ve described making small stories seems to fit with that.
Although I like the idea of breaking work into smaller chunks, I don’t think it’s right to call this a “story” anymore because it’s starting to blur the line between tasks and user stories. At that point, what you really have is a bunch of tasks with little meaningful guidance in terms of user stories. When this happens, the team starts spending lots of time focusing on “technical excellence”, “best practices” etc, but really slows down in terms of delivering what the customer wants.
I think it can help to keep stories as *user* stories and only have a smallish number of them, even if they’re large stories. It’s fine to have a bunch of tasks for one user story, and even subtasks for those tasks if they’re sufficiently complicated.