ELEN4010: Software Development

III

User stories and project planning

What is a requirement?

Wikipedia: A statement that identifies a necessary

attribute, capability, characteristic or quality of a system,

for it to have value and utility to a customer or

stakeholder

Succinct definition: Describes what the system must be or

provide in order to be useful

What are the characteristics of

good requirements?

Techniques for documenting requirements

Lightweight to heavyweight

Traditional to modern

Formal to casual

We will discuss three:

Use Cases

User Stories

Specification by Example (discussed later in the course, if

we have time)

Use Cases

First described by Ivar Jacobson in mid 80s

Important contributions from Alistair Cockburn

What is a Use Case?

A contract between the stakeholders of a system about its behaviour

Describes the systems behaviour as it responds to a request from one of the stakeholders, called the primary actor

Use cases are best presented as prose (simple writing)

Use Case Example I

Primary Actor:

Scope: Finance package (’package’)

Level: User goal

Stakeholders and Interests: Purchaser - wants to buy stocks, get them added to the package portfolio automatically.

Stock agency - wants full purchase information.

Precondition: User already has package open.

Minimal guarantee: sufficient logging information that package

can detect that something went wrong and can ask the user to

provide details.

Success guarantee: remote web site has acknowledged the

purchase, the logs and the user’s portfolio are updated.

Use Case Example II

Main success scenario:

1. User selects to buy stocks over the web.

2. Package gets name of web site to use (E*Trade, Schwabb,

etc.) from user.

3. Package opens web connection to the site, retaining

control.

etc...

Use Case Example III

Extensions:

2a. User wants a web site package does not support:

2a1. System gets new suggestion from user, with option to

cancel use case.

etc...

How would you classify Use Cases?

Lightweight or heavyweight?

Traditional or modern?

Formal or casual

Pros of Use Cases

Good for understanding intent and goals

Possible flows (extensions)

Finding stakeholders

Other actors and systems

Cons of Use Cases

Verifiability (tests) are not explicit

Planning – represent relatively large chunks of work, hard

to break down and estimate

Prose - ambiguity

Longer - harder to write and maintain, require more

investment (in some contexts, too much) in the

requirements phase

User Stories

First described by Kent Beck in late 90s as part of XP

Important contributions by others over time

Pros of User Stories

Short, lightweight - easy to maintain

Conveys user goals well - derive value

Includes verifiability criteria

Promotes conversation

Cons of User Stories

Easy to leave incomplete

Potential lack of context

May not scale well for large projects

User Stories Overview

What are User Stories?

Story slicing

Story size

Acceptance tests

User roles

Story mapping

Story estimation

User stories

User stories - requirements from a customers

perspective.

Aspects to a user story

Three aspects to a story:

1. A brief written description of the story

2. Conversations about the story to flesh out the

detail

3. Tests that convey and document details. Used to

determine when the story is complete

3Cs: Card, Conversation, Confirmation

Building a Car

Vertical Slices

Shrinking Stories; Maintaining Slices

Value Delivered Over Time

Story Size

A right-sized story from a user’s perspective is one

that fulfils a need.

A right-sized story from a development team’s

perspective is one that takes just a few days to build and

test.

A right-sized story from a business perspective is one

that helps a business achieve a business outcome.

An epic is a story that we expect is large, and know needs

to be broken down.

Written Description; Levels of Detail

As a <type of user>, I want <some goal> so that <some

reason>

An Epic Story:

As a user, I can backup my entire hard drive.

Too large for a single iteration, split into one or more

stories

Splitting the Epic

As a <type of user>, I want <some goal> so that <some reason>

As a power user, I can specify files or folders to

backup based on file size, date created and date

modified.

As a user, I can indicate folders not to backup so that

my backup drive isn't filled up with things I don't need

saved.

Acceptance Tests or “Conditions of

Satisfaction”

Write on the back of the story card

Example

Context: Managing the shopping cart on a book seller’s

site

The user story in question:

A user can put books into a “shopping cart” and buy

them when she is done shopping.

The Acceptance Tests

Put an out-of-stock book into the cart. Verify that the user is

told that the book will be shipped when it becomes available.

Put a book that hasn’t been published yet into the cart. Verify

that the user is told that the book will ship when available.

Put a book that is in stock into the cart. Verify that it appears

in the cart

Put a second copy of a book into the cart. Verify that the count

goes up.

User Roles or Personas

As a <type of user>, I want <some goal> so that <some reason>

Consider a job posting and recruitment site

Identify different types of job seekers

User Roles or Personas

As a <type of user>, I want <some goal> so that <some reason>

Consider a job posting and recruitment site

Different types of job seekers:

Tumi – university graduate looking for her first professional job

Allan – looking for any job in Cape Town so that he can windsurf after work

Ashish – has a job but is on the lookout for a better one

Brainstorm and Identify Roles/Personas

Job Seeker (eg. Tumi)

Geographic Searcher (eg. Allan)

Monitor (eg. Ashish)

User Story Mapping – FilmFinder

Start my search for a movie

Indicate interest in a specific movie

Story Size

A right-sized story from a user’s perspective is one

that fulfils a need.

A right-sized story from a development team’s

perspective is one that takes just a few days to build and

test.

A right-sized story from a business perspective is one

that helps a business achieve a business outcome.

An epic is a story that we expect is large, and know needs

to be broken down.

Allocating stories to sprints

INVEST in Good Stories

Independent

Negotiable

Valuable

Estimable

Small

Testable

Independent

Dependencies complicate planning and prioritization, and estimation

Worse:

A company can pay for a job posting with a Visa card.

A company can pay for a job posting with a MasterCard.

A company can pay for a job posting with an American Express card.

Better:

A customer can pay with one type of credit card.

A customer can pay with two additional types of credit cards.

Solutions: combine dependent stories or find a different split

Negotiable

Stories are short descriptions of functionality - not

contracts

Details to be negotiated in a discussion

Stories should not include detailed requirements even if

known. Can be annotated with key details

A company can pay for a job posting with a credit card.

Note: Accept Visa, MasterCard, and American Express.

Consider Discovery.

Negotiable

Too much detail could give the impression that the story

contains all of the requirements; no further need to have a

conversation

A company can pay for a job posting with a credit card.

Note: Accept Visa, MasterCard, and American Express. Consider

Discovery. On purchases over R100, ask for card ID number

from back of card. The system can tell what type of card it is

from the first two digits of the card number. The system can

store a card number for future use. Collect the expiration month

and date of the card.

Story cards are reminders to have a conversation, can contain

notes about issues to resolve during the conversation

Negotiable

Details become acceptance tests

A company can pay for a job posting with a credit card.

Note: Will we accept Discovery cards?

Note for UI: Don’t have a field for card type (it can be derived from first two digits on the card)

Tests on the back of the card

Test with Visa, MasterCard and American Express (pass).

Test with Diner’s Club (fail).

Test with good, bad and missing card ID numbers.

Test with expired cards.

Test with over R100 and under R100.

Valuable

To users

Also include stories valuable to purchasers (stakeholders)

All configuration information is read from a central location.

(Product is installed on multiple machines in an enterprise)

Throughout the development process, the development

team will produce documentation suitable for an ISO 9001

audit.

Valuable

Avoid stories which are only valued by developers (don’t

mention technology assumptions)

All connections to the database are through a connection

pool.

All error handling and logging is done through a set of

common classes.

Better variations

Up to fifty users should be able to use the application with

a five-user database license.

All errors are presented to the user and logged in a

consistent manner.

Estimable

May not be possible:

Lack of domain knowledge – discuss with customer

Lack of technical knowledge (first time use) - use a spike story

to gather information to estimate along with a story to do the

real work

Estimation in the large is inaccurate split large stories

into smaller stories.

Small

Stories which are too large or too small cannot be used

in planning

Epics or Activities in the user story map are useful to

have but are difficult to work with

Split stories to make them smaller but they still need to

be vertically slices!

Too small stories typically take longer to write down and

estimate then to just do them eg. Bug reports and UI

glitches. Combine into larger stories and schedule just

like any other stories

Split this story into smaller stories

“As a content manager, I can publish a news story to the

corporate website.”

From the conversation with the customer it turns out that:

The news article requires both editorial and legal

approval before publication

The news article requires a final review on the staging

website

Testable

Describe functionality which is testable

Automate tests as much as possible

Not testable (non-functional requirement)

A user must never have to wait long for any screen to

appear.

Testable version

New screens appear within two seconds in 95% of all cases.

Closed Stories

Finishes with a meaningful goal and sense of achievement

Context: A Recruitment Site

User Story: “A recruiter can manage the ads she has placed.”

Lacks closure as this is an ongoing activity

Prefer:

A recruiter can review resumes from applicants to one of her ads.

A recruiter can change the expiration date of an ad.

A recruiter can delete an application that is not a good match for a job.

Estimating user stories

Playing planning poker

A technique to compare estimates between team

members.

Root out any assumptions or lack of information.

For each user story, each team member plays a card.

Other variations use T-shirt sizes (small, medium and large)

What about the very large values ?

Each person places cards face down, and then turn them

over at the same time (why ?)

Resolve the spread by group discussion.

Large spreads can be caused by a misunderstanding.

Acknowledgements

Selected images used from “Head First Software Development” by Pilone/ Miles, the prescribed book for course.

“User Stories Applied for Agile Software Development” by Mike Cohn

“User Story Mapping” by Jeff Patton

Mike Cohn’s website:

http://www.mountaingoatsoftware.com/agile/user-stories

Images from the Elephant Carpaccio facilitation guide

http://bit.ly/1ktFnaY

Some slides by Joshua Lewis