Splitting User Stories

Measure. Optimize. Deliver.
Phone +1.610.644.2856
AgilePhilly
Splitting User Stories: Small, Smaller and
Smallest
Tom Cagley, CFPS, CSM
VP of Consulting
Mike Harris, SPC, CSM
President & CEO

User Stories Are Central To Scrumy- Agile
Architecture
Portfolio Layer
(ideas, needs)
Program
Manager
©2014 David Consulting Group
350
300
250
200
150
100
50
0
Burn-up Chart Example
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41
Days
Done
24 Hours
1-2 Weeks
Daily
Standup
Iteration
Backlog
Product
Backlog
Continuous
Reporting
Demo
Iteration
Planning
Potentially
Shippable
Retrospective
Business Functionality
Infrastructure
Business & IT
Steering Co
Program Layer
(IT Vertical)
Agile Team Layer
Epics
Product
Owner
Scrum
Master Cross Functional
Agile Teams
Iteration
Backlog
Iteration
Backlog
Business PO
Technical PO
Stories Release
Tasks

What Is A User Story?
A brief, simple requirement statement from the user perspective.
• Stories are visibly documented using the format:
As a <persona>, I want to <goal> so that <benefit>
• Ron Jeffries’ Three Cs:
• Stories are traditionally written on note
cards
• Cards may be annotated with estimates,
notes, etc.
Card
• Details behind the story come out during
conversations with product owner (stories
evolve)
Conversation
• Acceptance tests confirm the story was
coded correctly Confirmation
Source: XP Magazine 8/30/2001, Ron Jeffries

Why Use User Stories?
1. Many of the challenges associated with projects have been related to
requirements.
2. Words are imprecise:
– “Entrée comes with Soup or Salad and Bread.”
3. Stories shift the focus from writing to talking.

Difference Between User Stories and Use Cases
• IEEE Std 830-1998 defines software requirements:
– Correct;
– Unambiguous;
– Complete;
– Consistent;
– Ranked for importance and/or stability;
– Verifiable;
– Modifiable; and
– Traceable.
Standard requirement techniques, such as use cases and text-based requirements, are tools to
capture the complete set of requirements early in a project and at the maximum level of
detail. Agile assumes that the user story is a starting point and that conversation, acceptance
criteria and the demonstration of functional code will be needed to truly define what is needed
and what will ultimately be developed.

Story Card
• The “headline” for some new functionality.
• It is an “invitation to a conversation.”
• Written in business (domain) language.
• It is not a specification … specifications are documented using acceptance
criteria.
• Stories can be used to drive additional work, such as building test
scripts/frameworks.

Story Conversation
• Exchange of thoughts, opinions, and feelings.
• Takes place over time, particularly when the story is estimated.
• Conversations also occur at the iteration planning meeting when the story is
scheduled for implementation.
• Supplement with documents as needed.

Story Confirmation
• Acceptance criteria are written to test that the story meets the needs of the
product owner.
• The product owner specifies the acceptance criteria but will collaborate with
team to create them.
• The team can add additional tests.
• Most tests should be automated.

User Story Process
Step 1: Personas Step 2: Stories Step 3:
Brainstorm Initial
Personas
Organize
Consolidate
Refine
Choose a User
Persona
Generate stories
per persona
Discuss, argue
and refine
Augment
ID conversations
and supporting
documents
Acceptance
Criteria
Prioritize
Process flow to the backlog!
Refined Set of
Personas
User Stories

Components Of User Stories
Example from a job search site.
As a job hunter, I want to view information
about each job that is matched by my
search criteria to find a job.
Marco says show description, salary and location
What is needed
Notations, including
clarification and other
information
Estimate of size
Why the card metaphor?
• Enforced brevity
• Small size increases flow of work
• Enforces the need for conversations

Examples
• As a network administrator, I want the Verizon SIP circuits installed in the New
York data center, so that alternate paths can be established for the phone
system.
• As the organizational security officer, I want firewalls installed on all VOIP
circuits, so that security is improved.
• As the office manager, I want to ensure that the risk of equipment breakage
during shipping does not impact the phone system cutover, so that we don’t
miss call center SLAs. (A risk story)
• As an aircraft planner, I want to create individual sales orders for repairs of
aircraft, so that a work order can change against a job order number.
More
Examples

Epics, Themes and User Stories
• Epic
– A large user story
– Often requires weeks or months to deliver
– “As a VP Marketing, I want to review the performance of
historical promotion campaigns, so that I can identify and repeat
profitable ones.”
• Theme
– A collection of related user stories
– User stories that you can “wrap a rubber band” around
– “As a frequent flyer, I want to book a trip.” (travel website)
• User Story
– A description of desired functionality told from the perspective of the user or customer (by persona)
– “As a frequent flyer, I want to book a trip using miles.” (travel website)
– “As a frequent flyer, I want to rebook a trip that I take often.” (travel website)
What can be described as a user
story?
• Functionality
• Non-functional requirements
• Risks
• Issues
. . . Anything!

Backlog Grooming
• Why:
– Ensures that each story is understood and qualified.
– Reviews how a story is constructed and if it is properly formed.
– Enforces keeping the backlog prioritized and granular enough.
• When:
– Sprint pre-planning (event driven).
– Any discussion about what is needed (continuous grooming).
• How much?
– Kent Beck suggests 5-10% of sprint effort.
– Variable depending on project lifecycle.
– Grooming does require effort.

Sample Story Map - 1

Sample Story Map - 2

User Story Problems?
• Technical stories.
– Purely technical stories may or may not deliver a benefit that a product owner can
prioritize.
• Stories are still just words.
– Words mean different things to different people.
• A generic persona is hard to engage.
– Using overly generic user personas in user stories makes it hard to talk to a broad enough
set of people in the group to ensure you are going to deliver what is really needed.
• Not identifying the benefit of a story.
– Simply put, if you can’t identify the benefit of a user story, how can the story be prioritized?
• Stories without acceptance criteria.
– How do you know when you are complete?
• Stories that are too big need to be split.

Acceptance Criteria and Gherkin/Cucumber
• Acceptance criteria guides the team to deliver the functionality that the user
actually needs and wants.
• Acceptance should be written by the PO or BA in the language of the business.
• Each user story should have one or more acceptance criteria.
• Acceptance criteria should be added when stories are written and enhanced or
modified during grooming and iteration planning.
• Recommended format for stating acceptance criteria:
– Given ____________ [starting condition]
– When ____________ [specific action taken by user]
– Then _____________ [observed outcome]

Add Acceptance Criteria To Stories
Example from a job search site.
As a job hunter, I want to view information
about each job that is matched by my
search criteria to find a job.
Marco says show description, salary and location
What is needed
Notations, including
clarification and other
information
Estimate of size
More notes, testing notes or
acceptance criteria,
or other information that
helps with confirmation
Given: The job hunter wants job specific
information from a list of jobs.
When: The job hunter selects a specific job
Then: Display the detailed job listing.

Why Split User Stories?
Challenges with large stories and Epics:
• They’re harder to understand. Large stories
generally represent multiple, related business
concepts.
• They take longer to elicit feedback. Agile
techniques elicit feedback as work is being done.
• They can clog the flow of work. The one thing that
is always true in software development is that we
never foresee all eventualities (popularly known
as “stuff happens”).
Smaller stories are easier to understand, estimate
and implement. Breaking down larger stories
increases the throughput and therefore increases
the amount of value delivered.

INVEST
INVEST
Independent Stories can standalone
Negotiable Stories are not contracts
Valuable Each story provides a tangible benefit
Estimable Define the effort needed to deliver
Sized Appropriately The story can be delivered in the proper timebox
Testable The result of the story can be proved
Developed by Bill
Wake

Applying Invest As A Filter
A user story for Tom’s Beer Logo Glass Collection Application:
As a beer logo glass collector, I want to log my glass collection, so that I can keep track
of my glass inventory.
Invest Application
I – Independent Yes – this story could be developed independently of other stories.
N – Negotiable Yes – this story would facilitate communication, collaboration and negotiation with the project
stakeholder.
V – Valuable Yes – this story provides a tangible benefit (a system for tracking glasses in a collection).
E – Estimable Yes – based on the teams productivity, this story would require approximately 120 hours to
complete (4 FP per person week).
S – Small or Sized
Appropriately
No – the story is too large for the team to develop in one sprint. This story is 15 IFPUG
function points and includes four business functions.
T - Testable Yes – this story can be easily unit and acceptance tested.

Reapplying INVEST After Splitting User Stories
1. As a beer logo glass collector, I want to log (add) a glass, so that I can develop an
inventory of my collection.
2. As a beer logo glass collector, I want to be able to change logged logo glasses, so
that I can correct my data entry mistakes.
3. As a beer logo glass collector, I want to be able to display all of the logged
information, so that I don’t recollect the same glass.
4. As a beer logo glass collector, I want to be able to delete a glass that I have logged
in case my dog breaks the glass.
Add Story Change
Story
Display
Story
Delete Story
I – Independent Yes Yes Yes Yes
N – Negotiable Yes Yes Yes Yes
V – Valuable Yes Yes Yes Yes
E – Estimable Yes Yes Yes Yes
S – Small or Sized
Appropriately
Yes (4
function
points)
Yes (4
function
points)
Yes (3
function
points)
Yes (4
function
points)
T – Testable Yes Yes Yes Yes

Patterns In Splitting Users Stories
• One rule when splitting user stories: Each story must deliver functionality that is potentially
implementable. Where needed, the story should describe functionality that cuts across a full
architectural slice of the application.
• Slicing workflows: Workflows can generally be
broken into a number of separate valuable stories.
• Business rule variants: Transactions can require
different rules, different processing logic, depending
on business needs.
• Data variations: Data variations occur when there are
nuances in the groups of data needed to describe an
object.
• Data entry pattern: How the data enters the application
represents another potential for splitting stories.

A Working Example
We will compare the application of a number of patterns of splitting user stories using a time
accounting as a case study. Here are a few basic, high-level user stories:
1. As a company owner, I want my consultants to accurately record time and expenses by
project and by day, so that I can bill accurately and on a timely basis.
2. As a time accounting user, I want to log into the time accounting system securely, so that
I can log my time.
3. As a time accounting user, I want to log into the time accounting system securely, so that
I can log my expenses.
4. As a project manager, I want to be able to review and approve time and expenses logged
to my projects to ensure accurate reporting and billing.

A Workflow Example
Workflow
1. Log into the time accounting system.
2. Select the option to create a new
timesheet.
3. Enter data timesheet header; click save.
4. Enter line item data that includes project,
task, time type, hours per day and
comment per day. (Rule: one project,
task and time type per line.)
5. If done for the week, save and submit; if
not, just save (note: we will return to this
flow when looking at alternative paths)..

Applying The Workflow Pattern
In our example, the epic (large user story):
• As a time accounting user, I want to log my time securely, so that I can get paid.
The flow of work suggests the epic could be broken down into at least five user stories based on
the work flow noted above. For example:
• As a time accounting user, I want to log into the time accounting system, so that no one
else can mess up my time and expense accounting.
• As a time accounting user, I want to be able to create a new timesheet, etc.
And the list of user stories would go on matching until the sheet was saved and/or saved and
submitted, as previously noted.

Business Rule Pattern
• Business rules are a set of statements that indicate whether or
not something can be done or they provide criteria and conditions
for making decisions.
Example: Time Accounting Epic Story
– As a business owner, I want employees to work a full week
and contractors to work only the time authorized, so that I
can bill correctly.
Business rules governing the number of hours that can be booked
in a week:
– Employees must log at least 40 hours of work per week.
– Contractors may log less than 40 hours of work per week.

Splitting User Stories Base on Business Rules
In our example, the epic (large user story):
• As a business owner, I want employees to work a full week and contractors to work
only the time authorized, so that I can bill correctly.
Applying splits based on the business rule examples for the number of hours booked would yield
two potential stories:
• As a business owner, I want employees to account for a full week’s work of at least 40
hours, so that I can ensure all employees are busy delivering value.
• As a business owner, I want contractors only to enter the time they work, so that I do
not overcharge clients.

Splitting User Stories Based On Data Variations
• Data variations occur when there are nuances in the groups of
data needed to describe an object or an entity.
Example: Time Accounting
Business Rule: Contract employees can’t approve a timesheet.
Epic:
– “As a business owner, I want time entered to be approved
by an employee to avoid the perception of conflict of
interest.”
Could be split-based data structure variations as follows:
– As a business owner, I do not want contract employees to
be able to approve timesheets to avoid conflict of interest.
– As a business owner, I want timesheets to be approved to
ensure proper billing.

A Less Nuanced Set Of Data Variations
• If we were writing stories based on different groups
of data or variations, stories would encompass:
1. Individuals
2. Roles
3. Relationships
4. Family

Splitting user Stories Based On Elementary Processes
(Data Entry Pattern)
• Another pattern useful for splitting user stories is the concept of
the elementary process defined by the International Function
Point User Group (IFPUG) as the “smallest unit of activity that is
meaningful to the user.”
• The process of splitting user stories into elementary processes
can be paraphrased by three criteria that can be easily applied.
The criteria are:
1. Is the story meaningful to the user?
2. Does the story represent a single, functionally useful
element?
3. Is the story self-contained (independent)?

Time Accounting: Apply Elementary Process Pattern
A large user story (also known as an epic) for logging and maintaining time accounting data could
be written as:
As a time accounting user, I want to maintain my time, so that I can account for the work I
do.

Split Based On Elementary Processes
• Splitting . . .
– As a time accounting user, I want to add my time to my time card, so that I can account for
the work I do.
– As a time accounting user, I want to display the time I entered, so that I can ensure I
entered my time correctly.
– As a time accounting user, I want to change the time I previously entered, so that I can fix
my mistakes.
– As a time accounting user, I want to delete the time I entered in case I entered the wrong
week or day.
• Applying the simplified elementary process criteria:

Mixing Approaches
• All patterns are useful but . . .
• There is NO one way to look at user stories that
generates perfect splits!
Beginning with the elementary process pattern, using the
example of adding time:
Epic: As a time accounting user, I want to add my time
to my timecard, so that I can account for the work I do.

Adding A View Into The Workflow Yields More
• The workflow confirms that two flows exist and can be split.

Bad Splits!
• Waterfall Splits: Using waterfall concepts of developing knowledge in layers (analysis, design,
construction, testing and user acceptance) an iteration at a time rather than in thin slices.
– These stories do not deliver valuable functionality, one of the principles of Agile.
• Architectural Splits: Splitting stories up by architectural layer.
– These stories fail independence.
• Splitting Without Knowledge: Usually based on the belief that doing something will create
enough information to understand the remainder.
– Random splitting leads to wasted time, lower quality and reduced customer satisfaction.
• Keeping No Value Remainders: Not splitting because the remainder will not have value.
Stories that do not have a demonstrable business value should be jettisoned,
– Keeping stories that do not have value violates the Agile principle of delivering valuable
software.

A Few Rules of Thumb
1. Stories must be small enough to be completed during a single iteration.
(Suggestion: Split until the story can be completed in 2 – 3 days.)
2. Stories should be sized so that a single story does not require the whole
team at once to complete. (Suggestion: Split until only 1/3 or less of the
team must be involved at any one time).
3. Stories need to be testable within the sprint time box. (Suggestion: Split until
the story only requires five to seven acceptance criteria).
INVEST
Independent Stories can standalone
Negotiable Stories are not contracts
Valuable Each story provides a tangible benefit
Estimable Define the effort needed to deliver
Sized Appropriately The story can be delivered in the proper timebox
Testable The result of the story can be proved
Rules of
Thumb and
Invest define
done for
splitting!

Questions . . .
Tom Cagley, CFPS, CSM
VP of Consulting
The David Consulting Group
t.cagley@davidconsultinggroup.com
(440) 668-5717
Software Process and Measurement Podcast
http://www.spamcast.net (or Itunes)
Software Process and Measurement Blog
http://tcagley.wordpress.com
Mike Harris, SPC, CSM
President & CEO
David Consulting Group
m.harris@davidconsultinggroup.com
(610) 644-2856
www.davidconsultinggrpoup.com

Splitting User Stories

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to Splitting User Stories

Similar to Splitting User Stories (20)

Recently uploaded

Recently uploaded (20)

Splitting User Stories