On a regular basis, product owners ask me if a given user story should be split in two. There’s no canned answer for this question, in fact, story writing is as much art as it is a science. That said, I generally respond by asking the business owner to think carefully about the story’s business objectives, then ask themselves “Can these objectives be delivered/deployed separately?”

If the answer is “yes”, then there are several advantages to creating separate stories. Remember, a team’s capacity is measured in story points, not number of stories. This means that breaking stories up doesn’t mean you’re increasing scope, you’re just allowing for more granular prioritization, which ultimately means delivering more value in the time/budget you have available.

If you think of a user story as an encapsulation of business objectives, which are described by acceptance criteria, then there are at least three characteristics you can examine to help decide whether or not those objectives can (or must) be delivered separately:

1. Dependencies. Do the objectives of a story share common dependencies? Will the dependencies be available at the same time? If different aspects of the story depend on different outside resources, and those resources may not become available at the same time then the story should be broken into pieces by common dependencies. This way, smaller portions of the original story can be worked on independently of the rest, which may not be unblocked until a future iteration.
2. Priority. Are there different priorities represented within the story? If one aspect of a story is a must have, and another part you could do without, break it up so that the two stories can be sized and committed to separately. This is extremely important because any time spent delivering functionality which is not of the highest priority at that time means that in a given time window you will not get the most possible value delivered.
3. Size. Is the story too large to be described in detail? Does it have a clear, cohesive set of objectives? Assuming all the elements of a story have common dependencies and priority, take a look at the size of the story. The larger a story is, the less accurate the estimate is likely to be. This is because large stories rarely have the same level of detail as smaller stories, which makes them harder for a development team to estimate, as there are more unknowns. Break the story up into smaller pieces and focus on providing as much detail as possible for the smaller pieces, highest priority pieces.

Ultimately, there’s very little to lose by breaking a story into smaller pieces, and potentially, a lot to gain. If you’re asking yourself if a story should be divided, it highly likely you already know the answer to be yes.