1-1

User StoriesUser Stories

Much taken from

User Stories Applied: For Agile Software DevelopmentMike CohnMountain Goat Software

1-2

Where are we?Where are we?

Found some objects and major responsibilities Understand a desired system better Did some role play on one scenario

— User plays one song, start to finish

Understand the system from a high level Used a few design heuristics to more properly

place responsibilities Next up ... User Stories to capture requirements

1-3

User StoriesUser Stories

Extreme programming (XP) introduced the practice of expressing requirements in the form of user stories

User stories are short descriptions of functionality–told from the perspective of a user–that are valuable to either a user of the software or the customer of the software

1-4

A few Example User StoriesA few Example User Stories

The following are typical user stories for a job posting and search site:

— A user can post her resume to the web site— A user can search for jobs— A company can post new job openings— A user can limit who can see her résumé

1-5

User StoriesUser Stories

A user story describes functionality that will be valuable to either a user or purchaser of the system

User stories are traditionally written on an index card when the team and customers are communicating

— They will be written now as a line of text • in the slides that follow, and• in the project specification.

1-6

Aspects of a User StoryAspects of a User Story

A user story is composed of three aspects: — Written description of the story, used for planning

and as a reminder— Placeholder for future conversations among the

user, customer, and developer• User: You, me, section leaders, maybe you can sell it?• Customer: Rick• Developer: You

— Tests that convey and document details that can be used to determine when a story is complete

1-7

The student affairs office want to put some newfound activity fee funds toward a Jukebox in the student center. The Jukebox must allow students to play a song. No money will be required. Instead, a student will swipe a magnetic ID card through a card reader, view the song collection and choose a song. Students will each be allowed to play up to 1500 minutes worth of "free" Jukebox music in their academic careers, but never more than two songs on any given date. No song can be played more than five times a day*.

*What a drag it would be to hear "Dancing Queen" 14 times while eating lunch (apologies to ABBA)

In team of 2 or 3, write In team of 2 or 3, write fivefive user user stories for the Cashless Jukeboxstories for the Cashless Jukeboxwe'll collate them in 10 minuteswe'll collate them in 10 minutes

1-8

User stories for the Cashless User stories for the Cashless JukeboxJukebox

Example

1.Songs can be played up to 5 times per day

1-9

Some User Stories for the Some User Stories for the Cashless JukeboxCashless Jukebox

1. A user can select a Song from the collection of songs

2. Songs can be played up to 5 times per day

3. User can hear audio files play

4. Any user can play up to 2 songs per day

5. Jukebox can find a user given an ID

1-10

Other Stories?Other Stories?

When originally planned as an in-class demo, there were other user stories that seemed valuable to the students and the customer

— We can pick some, eliminate others

1-11

Do These Seem reasonable?Do These Seem reasonable?

5. Notify Student the song is not selectable

6. The system should be able to queue songs on a FIFO basis

7. Show the play list (queue) to help users decide what to do

8. Have a nice GUI interface

9. User can swipe card

1-12

Seem reasonable?Seem reasonable?

10.Students see their account status

11.Students can see how long all songs in the queue would play

12.Administrator can add and remove Students

13. Administrator can add and remove songs

14. Use this for "WebRadio"

15. The system should be able to play mp3s