CH. 5: USER STORIES

Copyright 2013-2015 Robert W. Hasker

Story Review

Elements of a Scrum story:

The three C’s:

Sprintable stories:

Mechanisms for obtaining stories:

Story Review

Elements of a Scrum story: As a <user>, I want to <action> because

<reason>. Acceptance criterion – when stakeholder

satisfied The three C’s:

Sprintable stories:

Mechanisms for obtaining stories:

Story Review

Elements of a Scrum story: As a <user>, I want to <action> because

<reason>. Acceptance criterion – when stakeholder

satisfied The three C’s:

Card, Conversation, Confirmation Sprintable stories:

Mechanisms for obtaining stories:

Story Review

Elements of a Scrum story: As a <user>, I want to <action> because

<reason>. Acceptance criterion – when stakeholder

satisfied The three C’s:

Card, Conversation, Confirmation Sprintable stories:

INVEST Mechanisms for obtaining stories:

Story Review

Elements of a Scrum story: As a <user>, I want to <action> because

<reason>. Acceptance criterion – when stakeholder

satisfied The three C’s:

Card, Conversation, Confirmation Sprintable stories:

INVEST Mechanisms for obtaining stories:

User-story-writing workshop, story mapping

Stories vs. Requirements

Requirements

Story

Form

Detail

Size

Readiness check

Estimation

How to handle errors?

Stories vs. Requirements

Requirements

Story

Form “as an X, I want to Y so that Z”

Detail Story can be a promise to discuss a topic w/ customer.

Size Can vary from epic to requirement.

Readiness check INVEST

Estimation

How to handle errors?

Stories vs. Requirements

Requirements

Story

Form “shall” “as an X, I want to Y so that Z”

Detail Anything not said is not done – forms a contract

Story can be a promise to discuss a topic w/ customer.

Size Each requirement has small scope

Can vary from epic to requirement.

Readiness check Review by customer, written tests

INVEST

Estimation Days of person-effort

Story points

How to handle errors?

Rework or renegotiate

Add to backlog

Good stories

I

N

V

E

S

T

Good stories

I Independent

N Negotiable

V Valuable

E Estimatable

SSmall (appropriate size)

T Testable

Good stories

I Independent

N Negotiable

V Valuable

E Estimatable

SSmall (appropriate size)

T Testable

Why?

Contradiction

Early on: a story should be a placeholder and real requirements are captured during the sprint.

Later: a story must meet the INVEST criteria

Our model: stories must meet INVEST to be in the sprint Must know how to take story out before

put it in. Write use case for each story – can be

short, but capture exceptions.

Examples

As an MSOE faculty member, I would like the kiosk to be branded so that it looks like a part of MSOE.

Examples

As an MSOE faculty member, I would like the kiosk to be branded so that it looks like a part of MSOE.

The site looks a little bit "off". We need to update the CSS so that it looks like the hub at least for the navigation portion. Spacing, fonts, and link colors are all incorrect.

As an admissions counselor, I would like to have most of the info available at a glance because I don't have time to click around during a tour.

Conditions of Satisfaction: Do not need to scroll to view most information

As an admissions counselor, I would like to have most of the info available at a glance because I don't have time to click around during a tour.

Change the default settings in the graph to start at daily, then go to weekly, and then go to monthly and so on.

Provide clear definitions of the data and how it is calculated in text.

The temperature widget has not been displaying the correct temperature. Find the issue and correct it.

Make sure the graph is displaying the correct information and in the correct scope.

As a user, I want to view a GUI while

using the system so that the system is easier to navigate. (Decide how to organize the UI and

create the UI elements.)

As a user, I want to view a GUI while

using the system so that the system is easier to navigate.

• Create a page to display the status of a room for the application.

• Create the login screen for the UI

• Build the control fragment used to move between pieces of application functionality. Buttons needed for room status, room calendar, partner calendar, create appointment, and room list.

• Create a fragment that displays a form for entering appointment data which includes: date, start/end date, attendees, etc.

• Create the main activity and integrate the different pieces of the application through method calls.

• Create the room list fragment that will display the room status of the other rooms.

• Design, create, and test the UI for the calendar fragment.

• Implement the login button in the status bar of the application and link it to the login page.

• Create a button for the room status. The user needs to be able to navigate back to the main screen of the application.

A more positive example

As a website user, I want double-clicking on the hourly performance data chart to leave the user in the hourly view so an accidental double-click doesn't jump me to a view that's unrelated to my intent. Acceptance criteria:Change to performance view, navigate until hourly data is showing, double-click on the hour bar, and confirm no change to the performance view.

As a user, I want there to be a "room

status" screen so that I can see whether the room is available or not at a glance.

(Create a room status screen.)

As a user, I want there to be a "room

status" screen so that I can see whether the room is available or not at a glance.

(Create a room status screen.)

Find the next available half hour block and display through the UI

Implement and test the next meeting functionality on the room status screen.

Implement the getting of the room's schedule and determining whether the room is currently available or not.

Review

Story review Stories vs. requirements INVEST Examples