Skip to main content

When to use User Stories, Use Cases and IEEE 830 Part 1

A hammer is good for nails, not so good for fixing televisions. A scooter is the best way to get around town, unless you’re in Montreal in January. Choosing one method to describe the customer’s need across projects, teams and environments actually hinders good analysts, architects and developers as much as it helps. What is much more valuable is having an analyst who understands and has the ability to use all of the tools, and relying on her to work with her team to decide whether to hammer the nail or take the subway.

Use Cases, IEEE 830 style “The system shall…” requirement statements, and User Stories each have advantages and disadvantages. A good analyst, or project manager, should know the advantages and have the ability to choose which is most appropriate for the project.

Over the next few posts I’m going to discuss the advantages and disadvantages of all three of these methods, while providing examples that are based on the same functionality for comparison. This post will start with User Stories.

User Stories

As a customer, I can reserve a hotel room with a credit card

User stories are vague. Any developer reading this would have 100 questions – Which credit cards? What does it mean to reserve a room? Can they choose a specific room in the hotel? and so on.

This is intentional. A user story is not a statement of need so much as a placeholder for a conversation. The user story has enough information in it, initially, to remind the person who submitted it what it was about and for developers to give a rough estimation of work. By rough estimation, I mean identifying how complex or difficult it is compared to other user stories, not how many hours it will take. Estimation of a user story provides a comparison so the customer can prioritize the user story against other user stories. Estimating a user story is not an estimate to be used in budgeting and resource allocation.

There are a couple of acronyms people refer to when providing guidance for the writing of User Stories. CCC (Card, Conversation, Confirmation) emphasizes that the user story should fit on a 4×6 inch card (written with a fat marker preferably). This limitation in size is enforced to discourage the reliance on the User Story card as a specification. Understanding the detail should be through conversations with the customer rather than the written information. During these conversations, acceptance criteria will be gathered that will guide the developer in confirming whether the code written has satisfied the user story. Example acceptance criteria for the above story would be:

  • The reservation cannot be made if the expiration date of the card occurs after the reservation date
  • The system must accept Visa, Mastercard, Amex, and Diner’s Club
  • The reservation cannot be made if there are no rooms available on one of the days requested

Another mnemonic for writing user stories is INVEST – Independent, Negotiable, Valuable, Estimable, Small, Testable. This mnemonic is also used to describe requirements and use cases.

The advantage of user stories is that they are very lightweight, meaning the time and effort invested in creating them is a lot lower than use cases and requirement statements. This makes them very useful in situations where requirements may change frequently, such as when breaking new ground for an organization or in highly competitive markets where you need the ability to react quickly to competing products or organizations. The other techniques require more up-front investment, which is then wasted if the need drops in priority. User stories are also very effective because they demand face-to-face communication. We as analysts are often too confident in our ability to write clearly, and assume that if we write something well there will be no room for confusion. In truth, every single person who reads our specification, no matter how well we write them, will interpret it differently.

There are disadvantages to User Stories. Face-to-face communication is the most effective means to reach a common understanding and to benefit from collaboration with all of the participants’ knowledge and experience. However, it can be extremely inefficient and costly when stakeholders have conflicting interests or when the need isn’t well thought out or understood. I’m not saying User Stories shouldn’t be used in this case however, just that some up front analysis work might need to be done in order for the user story to be “ready” for the team to estimate and prioritize.

Another problem with relying on face-to-face communication is sometimes it’s not possible. If your software is being outsourced, or if you’re developing a complex product where different pieces are being developed by contractors and subcontractors, it’s not very feasible to have developers communicating with the customers face-to-face every time a question arises.

Finally, if your organization already struggles to keep the clients engaged in the development process, User stories will make this problem more pronounced. You need to be certain that you will get the user engagement needed to flush out the details.

Users and stakeholders must understand that, unlike a use case or requirement statement, when submitting a user story they are committing to further conversation and involvement throughout the development process. This can be very hard for customers to grasp if they’re accustomed to traditional requirement specifications.

User Stories are a very effective requirements technique, and there’s more to say about them. For those new to User Stories, I’d highly recommend Mike Cohn’s book User Stories Applied if you want a detailed explanation on how to make user stories work, and Agile Software Requirements by Dean Leffingwell if you’re trying to adapt user stories to a business environment.

My next installment will discuss the benefits and drawbacks of Use Cases…

Don’t forget to leave your comments below.

Comments (2)