The Scrum process—the current market share leader among development teams using an agile cadence to deliver software—is built around the process of implementing user stories. Each user story represents something that a user needs to be able to accomplish with the software.
The user story is a great tool to use when the goals are to capture requirements, communicate concisely, and help developers so effectively keep a customer-centric perspective that they eventually forget how not to be user-focused.
The challenge comes directly from the conciseness of the user story—a single sentence describing the user’s objective and intent, combined with a set of acceptance criteria that allow a measure of the acceptability of any given solution. It is elegant and concise, but brevity is not always a boon.
If you were to summarize the entire novel of Moby Dick into a single sentence, you would end up with something like “Ship’s captain, mad with vengeance, destroys himself and others in his hunt for the whale that took his leg.” Sure, you get the big-picture view, but so much is lost in the compression from a novel to a sentence that you suck the life out of the story.
With user stories, you have to strike a balance between being exhaustively descriptive but overly narrow in scope and being overly vague and excessively broad in scope. The two measures you use to guide “right sizing” a user story are value—a user story cannot be so small that it doesn’t deliver tangible value alone—and deliverability—a user story should not be so large as to be undeliverable in a single iteration.
An objective of the Scrum process is to deliver working (and valuable) software with each iteration of development. Too small, and there’s no value. Too large, and you can’t deliver.
A waterfall process with a large requirements document actually suffers from both of these problems simultaneously—too many small requirements (without atomic value) bundled into an artifact that as a whole is too large to deliver predictably. Projects invariably have user stories that are too large. Many teams struggle with the challenge of knowing how to split them, so that the individual stories have atomic value and are properly sized.
Richard Lawrence provides us with a diagram that maps out many different patterns for splitting stories. Mark Levison shares an exploration of splitting stories, showing intent, rationale, and results.
Split your user stories to the appropriate size, using the techniques these experts have provided for our collective toolkits.
