Writing Good User Stories Bob Schommer, CSP, PMP Senior Project Manager Skyline Technologies, Inc

Writing Good User Stories

Bob Schommer, CSP, PMPSenior Project Manager

Skyline Technologies, Inc.

Welcome – Our Objectives for Today• Define the components of a good user story• Discuss the importance of writing stories for

unique user roles• Share techniques that will help you to “trawl” for

user stories• Provide you with methods for writing good user

stories• Have some fun!

Agenda• What is a User Story?• Keeping the User in the Story• Going Fishing for Requirements• Acceptance Tests• How to Tell a Good Story

The Three C’s

• Card– A written description used for

• Planning• As a reminder

• Conversation– Discussions about the story that flesh out details

• Confirmation– Tests that convey and document details– Used to determine when a story is complete

A reminder to have a conversation

Card

• Common format is:– “As a <user role> I would like to <feature> so that

<justification>.”• Guideline – not a strict rule• At a minimum include the role and what they want

the software to be able to do– “As a pilot I can view my schedule from last month

and one month into the future”

Conversation

• Additional comments about the story• Discussions that have been held

– “Andrea said that each trip should include airport, schedule date and actual date”

• Unanswered questions– “What should be displayed for short trips?”

• Reminders– “Note for UI: Include pop up to show additional

details”

Remember this is a reminder to have a conversation when the time is right

Confirmation• Details already determined in conversations• Acceptance tests can document details uncovered

during conversations– “Test with a Captain, First Officer and Flight Attendant”– “Test with a Reserve Pilot”– “Test with a crew member who has been on vacation”

• First of two steps for testing– Turned into actual test cases that prove the story has

been completed correctly• Write on back of card

Why User Stories?

• Emphasize verbal communications• Comprehensible by everyone• Right size for planning• Work for iterative development• Encourage deferring detail• Support opportunistic design• Encourage participatory design• Build up tacit knowledge

Software requirements is a communication problem


Role Modeling

• Stories should be written from perspective of different users of the software

• Identify user roles before writing stories• Think beyond the obvious

Role Modeling Steps

• Brainstorm initial set of user roles• Organize the initial set• Consolidate roles• Refine the roles

Role Modeling Guidelines

• Focus on identifying roles that can make or break your project

• A user role should be one user• Avoid non-human users

Other Techniques• Only use these if the additional effort benefits the project• Personas

– Imaginary representation of a role– Only write for important roles– Allows team to feel that they know the person– Caution: Requires market and demographic research be done

• Extreme Characters– May help uncover new stories– If anything, it may provide some brief entertainment– Examples:

• Pope• Drug dealer• Married man who is cheating


Trawl – Don’t “Elicit” or “Capture”

• New metaphor for gathering stories– Different sized nets for different sized stories– Not all requirements are worth catching– Some die– You won’t catch everything– You will likely catch some debris– Skill is required

Techniques• Story-Writing Workshops

– Rapid way to write many stories– Involve all team members– Combine with a low-fidelity prototype– Focus is on screen flow – not actual screens or fields– Ask questions that will help identify new stories:

• What will user likely do next?• What mistakes could they make?• What could confuse them?• What additional information might they need?

– Throw the prototype away when done writing stories


Acceptance Tests with User Stories• Used to convey details from conversations that

have taken place• Criteria that tell when the story is “done”• Should be written by the customer

– With support from Testers or Developers

• Write before coding begins– Whenever Customer and Developers talk about a story

and want to capture details– During iteration planning– When new tests are discovered during or after coding

Expanding Tests Before an Iteration

• Prior to starting an iteration, the customer should try to write additional tests by asking:– What else do the Developers need to know about

this story?– What am I assuming about how this story will be

implemented?– Are there circumstances when this story may behave

differently?– What can go wrong during the story?


Guidelines for Good User Stories• Start with goal stories for each user role

– Identify goals that each user role will have– Decompose from here

• “Slice the cake”– Do not split large stories along technical lines– Write stories that will deliver end-to-end functionality

• Write closed stories that can be accomplished– Can be finished by achieving a meaningful goal– Balance the six attributes of a good user story (INVEST)

• Create constraint story cards– For documenting non-functional requirements– Write “constraint” on card– Do not estimate– Do write acceptance tests when appropriate

Guidelines for Good User Stories• Size the story to the horizon

– Write small stories for functionality that will be developed within the next few iterations

– Goal stories are acceptable for features that are farther in the future

• Keep the UI out as long as possible– Causes the solution to interfere with understanding requirements– UI stories will be defined eventually – but not in early iterations– Exception – the UI is important to the success of the product

• Not all requirements need to be user stories– Screen shots are appropriate to define the UI– User stories may not be appropriate for some interface specifications

• Include the user role in the story– Be as specific as possible. Avoid: “As a user …”– Good template is: “As a <role>, I want <function> so that <business value>”

Guidelines for Good User Stories• Write for one user

– Avoid plural users– “A Pilot can …” rather than “Pilots can …”

• Write in an active voice– A user role should be performing an action

• The customer should write– Developers should feel free to suggest stories to the customer– Aids in understanding– Improves prioritization

• Do not number them– Adds unneeded overhead– Try writing a short title instead

In Closing

• References– “User Stories Applied: For Agile Software

Development” by Mike Cohn• I highly recommend this book

• Evaluation forms• Class certificates

Documents

Writing Good User Stories Bob Schommer, CSP, PMP Senior Project Manager Skyline Technologies, Inc