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.