Jira – User Story Guidelines

User Story Slicing

In a Scrum environment

page 1
Topics

• What is a User Story

• What does a good User Story look like?
• How to right-size a User Story?
• How to split User Stories into smaller stories?
• What is “Acceptance Criteria”?
• What is “Ready to Play”?
• Who writes User Stories?
• What is a Business Analyst responsible for?
What is a User Story - Where does it fit?

Vision / Investment
Aviva
Term
Outcome/
Outcome/ large-scale development
Benefit Benefit initiatives that realize the value
of an investments.
Feature/ Feature / Service provided by the system
Capability Capability that fulfils a need. Goes hand in
hand with a benefit.
Epic First level break down of features
EPIC into epics as needed which most
often represents user
activity/journeys.

User Sized to be delivered in sprints,

Story building up incremental value.
User Story
User Story – is one form of a Requirement

Stories are a:
 User’s need
 Product description
 Planning item
 Token for a conversation
 Mechanism for deferring conversation
 Represent requirements
(they are not THE requirements)

• User Stories are a promise to have

a conversation . The conversation
is much more important than the written story card!

Document only what is needed

to clarify the purpose of the conversation

Kent Beck coined the term user stories in 1999

“Extreme Programming Explained”
Guidelines for a Good User Story

• Start with the goal of the user. focus the story on user roles, use
business-language
• Initially, don’t be too concerned about story size
• Can slice the cake later
• Size should suit the stage you’re at: Big initially, smaller before sprint starts
• Write “closed” stories
• Put Constraints on the cards
• Don’t specify the solutions, let the team decide best solution
• Keep the UI out of the story as long as possible
• BAs help the Customer/PO to write them (ideally)
• Don’t number the cards
Recommended format for a User Story :
AS A <User Role>
I WANT <Some Function>
SO THAT <Business Reason>
 INVEST(D) Criteria for Story review

INDEPENDENT I VALUABLE V SMALL S

• Avoid introducing • Should be valuable • Story should not be too big or too
dependencies between to either user or small
stories customer • If the story is an epic, it needs to
be broken into smaller parts
NEGOTIABLE N ESTIMATABLE E • Very small stories should be
• A story is not a contract, it is • Story should be combined into one single story
negotiable estimable when possible
• Do not equate it with a • Common problems
signed off Requirement when estimation is
document not possible TESTABLE
• Provide enough information • Story is not clear in • Stories should be testable
T
for the developer and functional terms or • Provides validation that a story
customer to be able to talk technically complex has been successfully
about the story or too big developed.

Also Consider
DEPLOYABLE D
• Is this story deployable on it’s own?
• Does it represent enough value to stand alone and be pushed to production?
• Is it a culmination of other work that is enabling a larger feature to be deployable?
Gathering User Stories

Best User Stories come from getting close to the users

Techniques can include:
• User Interviews
• Questionnaires
• Observations (Systems thinking?)
• Story-writing workshops
• Should include users, developers and analysts if possible
• Focus on value to the user
• Don’t dive into details too soon (plenty of time for that later)
 What is in a User Story?

The Story

On the Suggestion
reverse, that is still
tests are needs to be
written broken down
in size

Constraints
(e.g. non-
Consider functional
writing requirement)
details
about the
story as A note to
tests provoke extra
questions

NB: The content is less important than the conversation.

Don’t write more – talk more!
User Story Slicing

Matt Roadnight - www.slideshare.net/mroadnight/ace-london-story-slicing-

session
Vertical Slicing

Matt Roadnight - www.slideshare.net/mroadnight/ace-london-story-slicing-

session
Why Vertical Slicing

• Deliver Working Software Early and Often

• Deliver Value to the intended User

• Easier to build and verify, reduces risk

• Holistic viewpoint, ensures a business perspective

• Early and Frequent Integration

• Frequently Tested – especially critical areas

• Always have something to demonstrate

• Can deploy incrementally

• Can a potentially deployable “minimal viable product”

User Story Map

Matt Roadnight - www.slideshare.net/mroadnight/ace-london-story-slicing-

session
One Approach: User Story Mapping

Jeff Patton http://www.agileproductdesign.com/presentations/user_story_mapping/index.html

Ideal Story Size

• Deliver Customer/Business Value

• Scrum team can build and test the Story in a few days

• Each Sprint has 5 or more Stories

Some ways to Slice User Stories

• Minimal “Happy Path”, followed by richer features &

exceptions

• Small end-to-end of user-benefit, additional benefit

later

• Simplest story, followed by more complex

• Most-frequent occurrence, followed by special cases

• Most-important users’ stories, followed by less

important user-type

• Basic input/output field, followed by add-ons

• Important Acceptance Criteria, additional criteria in

next story

• Get it working first, add Non-Functional Requirements

Story Slicing Example - from AvivaWorld: Find a Person’s
Phone #

Epic:
As an Aviva employee, I want to find phone # of another Aviva
employee
so that I can discuss my project with that person

Story Slices:
- Search by First and Last Name, with exact spelling
- Search by First and Last Name using wildcards *
- Search by Synonyms: Peter/Pete, Elizabeth/Liz, McKintosh/Macintosh

- Display email only

- Display email and phone number
- Display department info
- Display Org Chart and where the person fits in the organization
- Display a map of where the person is located, which building and floor

- As Aviva Security personnel, I wand to contact a person’s manager

- Performance: Ensure the results are displayed within 1 second via dial-
up connection in India
Exercise: Write and Decompose Stories

You are writing stories for BooksOnline.com

User Types:
 Ferocious Reader
 Occasional Reader
 Student
 System Administrator
 Book Author

Exercise:
1. Write User Stories for the above User Types
2. Slice the stories as small as possible, while
still valuable to that User Type
Acceptance Criteria
 Acceptance Criteria

 define the boundaries of a user story, and are used to confirm when a
story is completed and working as intended
 written in simple language, just like the user story.
 Should not be too detailed, the details should be worked out through
discussion between developers and SMEs
 when the development team has finished working on the user story
they demonstrate the functionality to the business, showing how each
criterion is satisfied.

Benefits
 they get the team to think through how a feature or piece of
functionality will work from the user’s perspective
 they remove ambiguity from requirements
 they form the tests that will confirm that a feature or piece of
functionality is working and complete.

he recommended format for writing the acceptance criteria is

GIVEN <precondition> WHEN <Input> THEN <output>
 Example Story with Acceptance Criteria from Guidewire

As an e-Docs system I need to receive the relevant information / indexing of

documents so that e-Docs users can see the appropriate documents they have
permission to.

Extra data items required to be stored in Content Mgr records over and above what
we currently store are, Agency Number, Effective Date, Product Type.

Story Acceptance Criteria:

GIVEN a user has selected for a Policy document pack distribution method to
include e-docs
WHEN Guidewire sends the print request message
THEN the Agency Reference Number which content manager should store the
composed document(s) against must be included.

GIVEN that Content Manager receives the Agency Reference Number in the request
message
WHEN the documents are indexed and stored in Content Manager
THEN each document should be stored with the Agency Reference Number received
in the AGENCY_NBR field

GIVEN a user has selected for a Policy document pack distribution method to
include e-docs
WHEN Guidewire sends the print request message
he THEN
recommended format
the Effective for
Date of writing
the the acceptance
transaction must be sentcriteria is
in the message which
GIVEN <precondition> WHEN <Input> THEN <output>
content manager should store the composed document(s) against must be
included.
What constitutes a User Story ready for Play?

A story is ‘Ready to play’ when the Scrum team agree that they have
sufficient information to include it in a sprint (via a sprint planning
session).

As a minimum, all ‘Ready to play’ stories will have:

• Title
• Priority/order (agreed with the Product Owner or their representative)
• Estimate (in story points)
• Size sufficiently small to be completed in sprint
• Acceptance criteria – sufficient to define the scope of the story
• Agreed basic design (completion of sufficient analysis and design activity so
that remaining uncertainty removal can be resolved in sprint)

• Dependencies documented/understood
• Agreed ‘definition of done’
The BA role, a crucial role between Solution designer,
Product Owner and the rest of the team

Works with the Team and PO to ensure User

Stories are Ready to Play at appropriate time
Business  Supports PO in backlog refinement and
(re)order
Analyst  Facilitates info sharping (READY for PLAY)
 Synchronizes User Story with Solution
designers
 Provide information to the team (on
Product
demand) Owner
Solution
designer
Business
Analyst
Screen
Lead designe
Develope r Scrum
r Team Master
Primary Scrum-roles

 Defines features and manages the product

backlog for optimum ROI
Product  Prioritizes features by business value
Owner  Works directly with the team and accepts or
rejects their work

 Ensures team is functioning and productive

 Removes barriers (impediments)
Scrum  Shields team from external interference
Master  Ensures the process is followed
 Facilitates planning, not a traditional PM

 Cross functional, 7 +/- 2 members

Team  Self directed

 Organizes itself and tasks
Member  Commits to Sprint and Demos to Product
Owner
Supportive Scrum-roles

 Provide management and resource

support
 Promote and support cultural change
Executive  Protect the teams from internal detractors
 Work with teams to provide accountability
 Reward transparency and reality
 Help provide clear prioritization of needs
based on commonly accepted criteria
Stake-  Willingness to support the Product Owner
in their role as product decision maker
holder  Assist management in understanding
changing needs
 Define minimal marketable feature set
 Provide specific feedback at each iteration

Customer  Willingness to spend time with the teams

 Willingness to receive value iteratively
 Focus on Simplicity
Who Writes User Stories?

• Anyone can!

• Primary responsibility rests with Product Owner

• Anyone can contribute/write a User Story: member of Dev

Team, SMEs, Customer Support, other stakeholders
• Ultimate prioritization rests with Product Owner, others can
negotiate

• In Aviva, a Business Analyst

works with the Team and Product Owner
to ensure User Stories are Ready to Play at appropriate time
Examples of activities BA’s might carry out

 Help the Product Owner understand how Scrum works

 Help the Product Owner prioritize their backlog
 Helps the Product Owner to create a Straw man of the Product
 Represent the Product Owners interests to the Team and vice versa
 Explain to the Product Owner what User Stories are and how the Team
use them
 Act as SME for the Team
 Provide clarification or details about requirements for the Team
 Ensure that all User Stories comply to INVEST and are agreed by the
Product Owner and update them.
 Ensure (especially) that the User Stories have good acceptance
criteria and update them.
 Specifies technical requirements
 Specifies logical data structures if appropriate
 Checks compliancy with the overall architecture
Example artefacts that a BA might produce
Or just
take a
Withdraw Cash picture!
Bank
Customer System

Transfer Funds

Refill and Service ATM

Machine Operator

ATM Update System

Configuration
Administrator
An approach that the BA might follow

• Synchronize with Product Owner

• Studies business environment
• Studies architectural environment
• Evaluate / Understand the technical environment with it’s limitations
and possibilities
• Create straw man model of the product together with the Product
Owner
• Review/Define Definition of READY with the team
• Review Epics and User Stories
• Facilitates Info sharping of the User Stories (INVEST and prioritize)
• Make User Stories READY for PLAY (in collaboration with team)
• Communicate, explains and discuss on User Stories with the team in
planning sessions, story kick offs and during development.
• Present results to stakeholders and processes their feedback
Common mistakes

• Stories are too large

 Stories should be able to complete within a half iteration
• Interdependent stories
• Are difficult to plan
• Can’t start one until another is finished
 So, try to avoid dependencies
• Gold-plating
 Stick to the story!
 Don’t add features that have not been agreed (propose new story?)
• Too much detail
 Stories are promises to have conversation
 Try using smaller cards!
Common mistakes (cont.)

• Including UI details too soon

• Restricts choice
• Masks value to the user
 Add UI details just before sprint
• Splitting too many stories
 Spend more time planning before iterations
• Customer has trouble prioritizing
 Check: Is the size too big?
 Check: Does it really express business value sufficiently?
• Customer not sufficiently involved in writing stories
 We’re all in this together!
 It’s OUR project
 Use retrospectives to assess impact
REFERENCES
References
Jeff Patton : User Story Mapping - Discover the Whole Story, Build the Right Product (2014)
Jeff Patton’s Blog: http://www.agileproductdesign.com

Roman Pichler: Agile Product Management with Scrum

Gojko Adzic: Fifty Quick Ideas to Improve your User Stories

Gojko Adzic: Impact Mapping

Bob Hartman and Richard Lawrence: http://www.agileforall.com/splitting-user-stories/

Bill Wake: 20 ways to split stories

Gottesdeiner & Gorman: Slicing Requirements for Agile Success

Matt Roadnight: http://www.slideshare.net/mroadnight/abc-how-to-slice-stories-oct-2014

OCTO: http://blog.octo.com/en/impact-mapping-business-success-in-software-development/

'How to split user story' on AgileForAll

BACKGROUND MATERIALS
Story Splitting – by Bob Hartman and Richard Lawrence
Impact Mapping – by Gojko Adzic
Jeff Patton’s Model for User Story Mapping

Use the user story backlog as a way to

describe user’s experience with your product

1: Mapping user stories

 User story essentials
 Telling stories about the user experience
 Mapping user stories based on experience

2: Planning valuable incremental releases

 Identifying product goals that delivery value
 Slicing the story map into valuable releases
Scrum: Sprint and Ceremonies

Customer Value Play

Ready
Daily s
Business Strategy Storie
Play Scrum
Ready Sprint LookAhead
s
Enhancements Storie

Defects Sprint Sprint Kickoff

Backlog Done
Product Backlog Sprint
(2 Wks) tially
1. User Story Poten le
Goal b
2. User Story Shippa e
Demo ar
Softw
3. User Story
4. User Story Release Retrospective
5. User Story Planning
6. …

LEARNING

Feedback