3.3.2B: User Stories

Loading...

From the course by University of Alberta

Client Needs and Software Requirements

1477 ratings

University of Alberta

Client Needs and Software Requirements

1477 ratings

Course 3 of 6 in the Specialization Software Product Management

This course covers practical techniques to elicit and express software requirements from client interactions.

From the lesson

Module 3: Writing Requirements

Explore the many ways in which software requirements can be represented. In this module, you will learn about the most popular means of expressing requirements in the industry today: the user story. You will learn how acceptance tests help to verify the stories which they accompany, and how to create a robust product backlog. At the end of the module, you will learn how story maps are used to organize user stories, so that you’re always putting your effort into the tasks which makes the most impact.

3.3.2: User Stories5:58

3.3.2A: User Stories6:59

3.3.2B: User Stories4:23

Meet the Instructors

Kenny Wong
Associate Professor
Computing Science, Faculty of Science

[MUSIC]

In our example of the restaurant application,

this could look like the user story.

As a customer, I want to pay for my bill so that I can settle what I owe quickly.

This seems simple enough, but what else is needed?

Does the user pay for their bill within the app?

What methods of payment are accepted?

These are all questions not addressed by the story.

And so the amount of effort which would be required to implement the story is

unclear.

This story would be considered an Epic.

I said a few seconds ago that Epics are usually defined

at the beginning of the Specification phase.

The problem is that estimates usually follow a pattern

called The Cone of Uncertainty.

We'll cover more about The Cone of Uncertainty in the agile planning course,

but basically this is the idea.

Time estimates to develop a user story get less and

less accurate the further into the future the feature is intended to be developed.

So if you're planning for a feature to be developed a few months down the road,

you can be certain that your estimate will be less accurate

than the estimate you make for a feature to be developed this week.

To avoid writing Epics,

the first step is to be aware of when you may be creating one.

A good practice is to give just enough information that the story can

be understood well enough for a developer to implement it, but not so

much that you begin to specify implementation details.

If you break Epics into multiple smaller stories,

you will find it easier to manage.

I mentioned an Epic earlier.

As a customer, I want to pay for my bill so that I can settle what I owe quickly.

A way to break this Epic down is to write a few smaller stories to describe it,

like this:

As a customer, I want to be able to see a bill,

with all of the items in order so that I can see how much my order will cost.

As a customer, I want to be able to select a "pay now" option when I view my bill so

that I can pay the bill immediately.

And, as a customer I want to be able to enter payment details for

Visa or MasterCard credit cards so that I can pay using a convenient method.

All of these are under the broad topic of paying for a bill, but

they're much more specific and helpful.

Imagine that you're building a software product in which users are able to choose

eyeglasses to purchase from the client's website.

Which of the following user stories would be considered epics for this product?

A. As an eyeglass wearer, I want to see, so that I can slay dragons.

B. As an eyeglass wearer, I want to purchase new eyeglasses, so

that I can get them in the mail quickly.

C. As an eyeglass wearer, I want to view a list of eyeglasses available for purchase.

Or D. As an eyeglass wearer,

I want to see the prices of eyeglasses available for purchase.

The correct answer is B.

A is not an epic because it's not really even a user

story that's related to this product.

C and D are both stories which outline specific functionality

without diving into the technical details.

And that's the user story.

In this lesson, I covered what a user story is.

It's another way of expressing your client's requirements.

Then, I covered what makes a good user story.

I introduced the INVEST mnemonic, which stands for independent,

negotiable, valuable, estimatable, small, and testable.

Finally, I covered what an epic is and how to avoid it.

In the next lesson, I am going to talk about how to make user stories testable

and introduce the concept of acceptance tests for user stories.

See you there.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play