User Stories

Short, simple descriptions of a feature told from the perspective of the customer
What is a User Story?
From Mike Cohn:

• “User Stories are a part of an Agile approach that helps shift the
focus from writing about requirements to talking about them…”

• “All Agile User Stories include a written sentence or two, and,

more importantly, a series of conversations about the desired
functionality.”

Source: https://www.mountaingoatsoftware.com/agile/user-stories

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 2
The 3 C’s of User Stories

•CARD
•CONVERSATION
•CONFIRMATION

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 3
The INVEST Model
INVEST is an acronym that captures the ideal qualities of User Stories:

• Independent: The User Story is not dependent on other Stories.

• Negotiable: The User Story can be changed, rewritten, or split (prior to being
committed to a sprint).

• Valuable: The User Story must deliver value to the end user.

• Estimable: The Development Team must be able to estimate the User Story’s size.

• Small: Every User Story has to be sized appropriately to fit into a Sprint.

• Testable: The User Story is capable of being tested.

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 4
What’s the difference between User Stories and Requirements?

USER STORIES REQUIREMENTS

Who creates? “3 Champions” to Full Teams Typically only the Business

High level of detail, specific; tends to

Level of detail Just enough; open for negotiation
cover all possible combinations

Quick, placeholder for further Can be laborious, taking significant time

Time to create
conversations and elaboration to complete
Created far in advance; reflect needs at a
Create when/as needed; reflect current
When to create? particular point in time, typically in the
needs
past
Collaboration emphasized, write down
Primary Info Transmission Written documentation
only what’s needed after discussion
Low amount of hand-off; expectation for Tendency for high amount of hand-offs –
Hand-offs
collaboration business to IT, IT to Quality, Quality to…
Experiment, learn, expectation for Lock down then implement significant
Change Control
change effort process for changes

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 5
User Story Format

•As a…
[Who? - Insert the User]
•I would like to…
[What? - Insert what they want to do]
•so that…
[Why? – Insert the Business Value]

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 6
Example Stories – Hypothetical Promotion Enrollment:

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 7
Implementation Details vs. Value of Implementation

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 8
Deliver User Stories as Vertical Slices of Functional Product:

Story 1 Story 2

GUI

Business Logic / Rules

Database

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 9
User Story descriptions are not enough…
You also need Acceptance Criteria to better describe expected outcomes.

• Acceptance Criteria characteristics:

– A list of outcomes that enable a Product Owner to accept a User Story
– Adds clarity to the story’s deliverables
– Provides a guide to developers for effective testing
– Helpful for further documentation
– A good tool for splitting up work and negotiating the schedule of deliverables

• Suggested format:
– “This story is done when…[insert outcomes, not implementation details]”

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 10
Example Acceptance Criteria – Hypothetical Promotion Enrollment:

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 11
User Stories are not “requirements” nor detailed specs…

• They are intended to be “placeholders for further conversations” – they are not intended to
be fully defined specifications down to detailed minutiae.
– Details of exactly what will be required will be built in collaboration between business and IT.
– Focus on the “why” (outcomes) and not the “how” (implementation details).

• They will be progressively elaborated over time:

– User Stories at the top of the product backlog (highest priority) will have the most detail.
– User Stories at the bottom of the product backlog (lowest priority) may have just a title.

• How much detail is needed for a User Story to be ready?:

– Enough for the team to Size and Task the story.
– This can be in conflict with traditional DCO practices.

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 12
Special Story Type – Spikes
• There are times when you may not know enough to deliver a User Story (incremental value) directly to a customer.

• You may want to gain clarity on…

– Do we have a problem?
– Does our proposed solution solve that problem?
– Is our proposed solution technically feasible?

• Use a Spike!
– Be sure that the “so that…” clause clearly identifies what you are going to do with the information once you have it.
– Acceptance Criteria is still necessary.
 What is it that you need to know?

• This is a special case – use Spikes sparingly

– The presence of multiple spikes indicates you may not have enough clarity on the problem and/or solution

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 13
User Stories must fit within the Sprint

The Goal is to deliver potentially shippable product at the end of each

iteration…

Complex Problems Compound Problems

“We just don’t know enough…” “Its just too big.”

Research Functional Multiple Functional

Spike Story(ies) Story(ies)
(do first) (do after spike) (prioritized)

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 14
00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 15
Do you have an Epic?

• What is an Epic?
– Typically represents a large chunk of work
– Consists of (2) or more User Stories

• What are the characteristics of an Epic?

– Still follows the same format as a User Story (title, description, Acceptance Criteria)
– Lives in the Product Backlog
– Unlike User Stories, the delivery of Epics can span multiple sprints
– Often start with Epics that eventually get decomposed into User Stories
 But, can also take a group of User Stories and create an Epic as well

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 16
Relationships between Epics and User Stories

1..n

2..n

Tasks
1..n

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 17
Definition of Done (DoD)
• Having User Stories and Acceptance Criteria are usually not enough to say a story is releasable.

• Definition of Done:
– Set of activities required for User Stories to be considered complete so that the increment of product functionality can be
“potentially shipped” if desired

• Some examples of a Definition of Done (DoD) could be:

– Code/Rules reviewed
– Unit testing added to automation testing suite and all Unit tests pass (not just for code added this sprint)
– Regression test suite updated
– User documentation (as required) is completed/updated

• The Development Team and Product Owner (PO) need to come to agreement on DoD before planning the first sprint
– DoD may vary from team to team – that’s OK as long as it’s transparent
– If multiple teams/POs are involved, there needs to be common agreement
– DoD often evolves over time as Dev Teams become more proficient

00 Month 0000 Footer (Edit footer for all slides with View > Header & Footer) 18