Agile Myths - Part 2

September 2nd, 2014 by Adam Sandman

agile requirements management

In this item we continue our examination of various Agile methodology ideas and ask whether they are valid or whether they are in fact, industry myths.

Myth 2: User Stores, Use Cases and Requirements are all Totally Different

With this question we ask not only whether there are differences between Use Cases, User Stories (or Scenarios) and requirements but also, if they are different can be used together as part of the same methodology, whether it be traditional or some form of Agile development. Let’s start with Use Cases and User Stories which seem to cause the greatest confusion, no doubt in part because of their similarity in names.

Problem Domains versus Solution Domains

The difference can be boiled down to the problem and solution domains. A well formed User Story deals with only the problem domain; it addresses the need of the user by describing in plain language what the user wants to do. It says nothing at all about the way he will do it. A good Use Case will also talk about what the user wants to do but it will go further by addressing how he will do it as well as all the parameters of the operation and any boundary conditions or interactions with other systems, i.e. the solution domain. Crucially, a Use Case includes the need but not in the same easy to read language of the User Story. The language of the Use Case is more formal with the objective of being comprehensive, which the User Story is not. Which brings us to the applicability of each narrative.

A User Story can be written by a stakeholder or business analyst with little instruction. To write a Use Case requires more appreciation of the Use Case concept, but perhaps more importantly, far more knowledge of the proposed solution. This is because, as we said, a Use Case must be all-inclusive and it must be implementable, which a User Story is not.

Because of the open-endedness of User Stories they work well within Agile methods where the development team will work together with the stakeholders to explore options and refine first the need, or problem described by the User Story and then the solution. A Use Case is self-sufficient and ideally requires no stakeholder discussion. Consequently, Use Cases work well in traditional software development projects in which developers are far more isolated.

A User Story Example

Let’s take a simple example to illustrate a User Story and how it differs from a Use Case. It is admittedly not a software example, but it nevertheless illustrates the differences.

The User Story might be: The user wants some chilled water and get is directly from the refrigerator.

The entire development team must work with the stakeholders (users, product owners, business directors, etc.) to ask a series of questions which are not answered by the User Story.

Some questions that might be asked:

  • Does the user have to open the refrigerator door to get the water?
  • Is the water provided already in a container such as a jug or bottle or must the user provide the container?
  • Does the user have to wait for the water or is it delivered instantly?
  • How much water can the user get in any one delivery?
  • Is there a minimum time between deliveries?
  • How much space can the delivery system take up in the refrigerator?
  • What is the nature of the interface to the system delivering the water to the refrigerator?

Once the answers to these and other questions are understood, tasks can be devised to provide an appropriate solution. A Use Case should already contain answers to all these questions!

User Stories and Use Cases Together

So, there are differences and similarities between User Stories and Use Cases, but can they be used together in Agile projects? The answer is yes, provided the User Stories come first and form the basis for the Use Cases which must be developed by the development team as a whole and not solely by the product owner.

What about requirements? Well, User Stories and Use Cases are just two of the many ways that requirements can be expressed, “shall” statements being another. So, all three do the job of specifying a need, just in different ways. Therefore, the myth that User Stories, Use Cases and requirements are totally different is indeed merely a myth. There are some (important) differences, but they all define a problem or a need, just to different degrees and in different ways.

You may also be interested in:

 

Spira Helps You Deliver Quality Software, Faster and with Lower Risk.

Get Started with Spira for Free

And if you have any questions, please email or call us at +1 (202) 558-6885

Free Trial