Stories

for Design and Delivery

What is a story? Characteristics of useful stories Why stories?

A story describes product functionality from a • Supports satisfying the customer through early and
customer’s perspective. It is a collaboration tool - a Independent continuous delivery of valuable software
reminder to have a conversation about what the • Shifts the focus from writing to talking - words are
customer needs so the team can design it well & imprecise
NegoUable • Supports and encourages participatory domain-
deliver it quickly.
driven design (DDD) and user experience design
What is a helpful pattern to follow? (UXD): involve users, domain experts and
Valuable
“As a <user role>, I want to <goal> so that <benefit>” stakeholders (i.e. customers) in a creative, iterative,
INVEST collaborative design process
e.g. As a nurse practitioner, I want to add an appointment to my EsUmable • Describes concrete business reference scenarios,
schedule so that no patient has to wait more than 5 minutes for
equally understandable by developers and customers
treatment
in a common, shared language
Small
Start first with benefits and goals • Customer ranks stories in team’s work queue
according to relative business value, and team
Consider each user role and identify the goals that user
Testable designs iteratively & delivers incrementally
role has for interacting with the software. Identify stories
as core, supporting or generic subdomain. Focus on what • The right size for planning – level of detail is based on
is needed and why, not how.
implementation horizon

Model exploration Augment when appropriate Why user roles in stories?
• Avoid design fragmentation • User stories are not the end-all, be-all for • Broadens scope from looking at only one user
when splitting stories by doing representing “requirements” • Allows users to vary by:
model exploration when needed • Augment them as appropriate with: o How they use the software and for what
o Design documents/sketches o Background
• Exercise the ubiquitous language
o Proof of concepts, code probes o Familiarity with the software/computers
in stories. o Photos, screenshots, mockups • Used extensively in usage-centered design (c.f personas)
• Look for key business examples o Examples of inputs and expected result • Advantages
in user stories to source as (be specific!!!) o Users become tangible – software solves the needs of
reference scenarios for modeling o Business rules, data dictionaries, use real people
cases, glossaries, diagrams, o Incorporate roles into stories
spreadsheets

© 2016 Virtual Genius, LLC v.07.28.16 www.virtualgenius.com

Independent1 Estimable Common patterns for splitting stories2
• Identify dependencies – they • Don’t get hung up on estimation or traceability, Workflow Steps – potential need for modeling here if core domain
As a content manager, I can publish a news story to the corporate website
make prioritizing and planning focus on delivering …I can publish a news story directly to the corporate website
more difficult • A story might not be estimable if: …I can publish a news story with editor review
• “Slice the cake” – each story o Developers lack domain knowledge …I can publish a news story with legal review
must have a little from each o Developers lack technical knowledge
Business Rule Variations – potential need for modeling & UXD here
system layer o The story is too big (see below) As a user, I can search for flights with flexible dates
o Exercising each layer of the • Stories used in project planning …as “n days between x and y”
architecture reduces risk • Developers are responsible for estimating …as “a weekend in December”
of finding last-minute
• Technique such as planning poker or planning
Break Out a Code Probe or Spike/POC – in core domain (avoid otherwise)
problems in one of the game can be useful for making estimates As a user, I can pay by credit card
layers • Story points are a relative measure of …Investigate credit card processing
o Possible to release effort/uncertainty/risk in implementing a story …Implement credit card processing (as 1 or more stories)
application with only
Simple/Complex – is complex stuff within core domain? Potential need for modeling here. Otherwise,
partial functionality avoid complexity in supporting & generic
Negotiable Small As a user, I can search for flights between two destinations
• Stories are not: • Small stories for implementing in the near future, …specifying a max number of stops
…including nearby airports
o Written contracts and higher-level (larger) stories for further out.
o Requirements (they • Large stories (aka “epics”): Major Effort – supporting? maybe simple case is good enough
express customer needs o Do domain distillation: separate what is core As a user, I can pay for my flight with VISA, MasterCard, Diners Club, or American Express
that software can help from what is supporting and generic …I can pay with one credit card type (of VISA, MC, DC, AMEX)
…I can pay with all four credit card types (VISA, MC, DC, AMEX)
fulfill) o Often hide assumptions that should be made
• Don’t include all details, explicit Data Variation – supporting? maybe simple case is good enough
otherwise gives impression of: o Hard to estimate and to plan - won’t fit in a As a content manager, I can create news stories
o false precision or single iteration, so split into smaller stories …in English
…in Japanese
completeness • Bugs can be turned into user stories if this is
o no need to discuss further helpful Data Entry Methods – collaborate with UXD
As a user, I can search for flights between two destinations
Valuable Testable
…using simple date input
• Identify if story relates to core, • Drive important design decisions test-first with …with a fancy calendar UI
supporting or generic unit tests
subdomain • Specify acceptance criteria: these tests Defer Performance – leverage domain events & aggregate boundaries?
As a user, I can search for flights between two destinations
• Stories must be valuable either demonstrate that a story meets the customer’s …(slow – just get it done, show a “searching animation”)
to users/domain experts expectations, they define the conditions of …(in under 5 seconds)
• Completed stories have more satisfaction for the story
Operations (eg. CRUD: Create/Read/Update/Delete) – basic operations unlikely to be in core domain, is it
value. Finish stories early and • Use specific, concrete, actual business scenarios
supporting subdomain?
often. for modeling and testing As a user, I can manage my account
• Where possible, automate acceptance tests …I can sign up for my account
…I can edit my account settings


User stories content adapted from Mike Cohn, User Stories Applied (Addison Wesley: 2004).
1

2
Adapted from Story Splitting Cheat Sheet by Richard Lawrence of Humanizing Work (http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories)
3
DDD Whirlpool adapted from http://domainlanguage.com/ddd/whirlpool
© 2016 Virtual Genius, LLC v.07.28.16 www.virtualgenius.com