User Stories

In agile software development, when people think of functional slices, they often think of User Stories. This is a term and technique originating with Extreme Programming. As usage of the term has spread, the understanding of it has become a bit fuzzy.

A User Story is a small slice of functionality that’s describable in terms of the user’s goals and capabilities. It’s so named because it involves an interaction with a system user, either accepting input or providing some observable result, and usually both. In general, a User Story is smaller than a Use Case, which is a more comprehensive set of related interactions. I often think of it as a single path through a Use Case. Each alternate flow would likely make a separate User Story.

Like a Use Case, a User Story describes the system requirements from the point of view of interactions and responses. When the system does all the things you want it to do—in other words, all of the User Stories have been implemented—then the system is ostensibly completely functional. It’s either that or the list of User Stories was incomplete.

By using User Stories to define the system by the things it needs to do, you can also estimate the work using them. How much time and effort would it take to add this User Story’s increment of functionality to the system?

Some people think that a User Story is described by the Connextra format: “As a <role> I can <capability>, so that <some benefit>.” This, however, is just the title of a story, and a wordy title at that. It’s worth noting that the originators of this format went back to using short titles very quickly, once they had reminded themselves to consider the benefits to the user. The heart of a User Story is a conversation telling the story about the user’s needs.

“Say that Joe has been handling the Parsnip Industries account, but Joe is going on a two-month cruise with his wife to celebrate their twenty-fifth wedding anniversary. While he’s gone, Joe wants to delegate the Parsnip Industries work to his colleague, Sue. With regard to that account, Sue should be able to do everything that Joe can do, enter new orders, expedite existing orders, update orders, and so on. Upon his return, Joe wants to take charge of the Parsnip Industries account again. Everything that Sue had done in his stead should be visible to Joe, and he should be able to perform operations on these items just as if he’d entered them himself.”

Notice that there is quite a bit of functionality here. It’s not a single interaction with the system. This is not a small story.

Big and Small Stories

Some people call this a feature, as “Delegate an account” might be the name of something you would put in the advertising brochure. Some people call such stories “epics” because of their size, but they’re not as grand and poetic as that might suggest. Instead, the term “epic” suggests that the story is intended to be further split before implementation. There’s no universal naming convention for big stories, so I often just call them that, Big Stories.

While this story is large for implementation, it might be just the right size for estimating in the moderately long term. For implementation, split your stories into slices that can be implemented in two days or less. This will let you see the progress. Larger stories seem to disappear into a black hole, and you can’t tell if they’re stalled or not.

This story might be split into a number of smaller stories like the following:

• An account can be delegated.
• A delegated account can be undelegated.
• A delegatee can enter orders on an account belonging to the delegator.
• A delegatee can update orders entered by the delegator.
• A returned delegator can update orders entered by the delegatee.
• …

For each of these story splits, explicit acceptance criteria should indicate when that User Story has been satisfactorily completed. This acceptance criteria should be illustrated with example scenarios that can be verified. Ultimately this can get quite detailed. That’s not surprising, given the detailed nature of telling a computer what we want it to do.

Each of the small story splits can be estimated. In fact, that’s the level that most people expect to estimate, using ​Story Points​ and ​Planning Poker​. It’s my experience that estimating such small stories generally takes more time and effort than it’s worth. For short-term estimates, such as how much work a team can accomplish in the next two weeks, just count the stories. If you’ve kept track of how many stories the team accomplished in the last two weeks, that’s probably a close enough estimate, and requires less work. (See ​Counting Stories​.)

For longer-term estimates, I don’t recommend going down to the small story level. That is also a lot of work, and things can change between now and when you go to implement those stories. Plus, it results in ​A Large Number of Small Parts​ which has its own challenges.

Completing User Stories

Implemented User Stories can provide value even when the full list of User Stories has not been completed. For the most part, User Stories can be added to the system in any order that makes sense at the time of implementation. Usually this order is determined by priority of value or minimizing risk. Necessary system support is built as needed by the story. This adds another ordering priority–simplest first. The ability to create usable functionality in an arbitrary order makes User Stories a great building block for incremental and iterative development.

One of the big advantages of tracking progress by User Stories is that, as functional slices, you can test to verify that they’re completed. User Stories are determined to be implemented when all of the example scenarios are verified. Given that they’re small and rather unambiguous, User Stories are excellent for estimating short-term milestones and tracking progress during development.