how do you get more out of your user stories?
DESCRIPTION
Ways to improve writing and sharing of user storiesTRANSCRIPT
How do you get more out of
your user stories?
© 2013 © 2013
Let’s first
refresh our basics
© 2013 © 2013
! Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
! We welcome changing requirements, even late in development.
! Business and IT teams must work together.
Key Agile
principles
http://www.agilemanifesto.org/principles.html
© 2013 © 2013
What is a
user story? Card Conversation + Confirmation = +
© 2013 © 2013
! Physical token
! Used in planning
! Reminder for a conversation
! Often annotated
#32 As a user I want to do something so that some benefit is received
What is a
user story?
Card
© 2013 © 2013
What is a
user story?
! Requirement itself
! Verbal conversation / workshops
! Supplemented with documents / wireframes / mocks
Conversation
© 2013 © 2013
What is a
user story?
! Acceptance criteria
! Used to determine when the story is done
#32 Given <preconditions> When <trigger> Then <expected outcomes>
Confirmation
© 2013 © 2013
Now, let’s see what makes a
good user story?
© 2013 © 2013
Independent Negotiable Valuable Estimable Small Testable
What makes a good user story?
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
The INVEST guideline for writing a good story
© 2013 © 2013
What makes a good user story?
Independent
Negotiable
Valuable
Estimable
Small
Testable
þ Do not overlap your stories in concept.
þ When sequencing the stories, try to find their natural order.
Pay by MasterCard
Pay by Visa
Pay by AmEx
Pay by Credit Card
The order of stories should not restrict your customer’s ability to re-prioritize or move stories out of scope.
© 2013 © 2013
þ Stories are negotiable...and negotiated.
þ Remember, your story is the essence of the requirement and not an explicit contract.
þ Sign off stories with working software.
As a purchaser, I want the receipt to indicate when I
completed the purchase, so that I can maintain my
records.
As a purchaser, I want the receipt to display the date of my purchase in ISO 8601 format Comic Sans 12pt font with 9pt leading, so that I can maintain my records.
What makes a good user story?
Avoid signing off written stories before they are played, as it creates contractual documents that shift the focus to documentation.
Independent
Negotiable
Valuable
Estimable
Small
Testable
© 2013 © 2013
As a developer/DBA, I want a new table in the Orders DB to capture shipping information, so that ???
As a customer, I want to be able to specify my preferred
shipping details, so that I can ship to an address other
than my billing address
þ Your stories need to be valuable to and understandable by your customer.
þ They need to be framed from your customer’s perspective.
What makes a good user story?
If it is difficult to write the "so that....” part easilyyou might want to consider the story’s value and purpose. Avoid layer-based development. Instead choose vertical slices of functionality. Technical debt are not user stories.
Independent
Negotiable
Valuable
Estimable
Small
Testable
© 2013 © 2013
As a good world citizen, I want world peace, so that we can all live in harmony.
As a movie goer, I want to be able to pay by Paypal, so
that I don’t have to use my credit card.
þ Your stories should have boundaries so you know when you are “done” and what is required to be “done”.
þ Your stories should be digestible by the team so they can estimate them.
þ Keep your stories understandable and of consistent granularity.
þ “Spike” stories that your team has difficulty understanding.
What makes a good user story?
Avoid “catch-all” stories with uncertain estimates.
Don’t get bogged with precision and detail.
Independent
Negotiable
Valuable
Estimable
Small
Testable
© 2013 © 2013
As a movie goer, I want to be able to find and purchase movie tickets online, so that I have something to do tonight.
As a movie goer, I want to be able to find a movie by title,
so that I can quickly locate the details of a movie I am
interested in.
þ Keep your stories small enough to be measured and tracked.
þ Keep your story descriptions short and concise.
What makes a good user story?
Stories should be measured in days not weeks.
Independent
Negotiable
Valuable
Estimable
Small
Testable
© 2013 © 2013
þ To know when your story is done, it needs to be testable.
þ Define acceptance criteria that are clear and precise so you know when you are done and have delivered value.
What makes a good user story?
All acronyms replaced with complete terminology
Improve readability
New screens appear within 2 seconds 95% of time
A user must never have to wait long for a screen to appear
First define your tests and then develop.
Independent
Negotiable
Valuable
Estimable
Small
Testable
© 2013 © 2013
How do you
size your stories?
© 2013 © 2013
Larger
Vs.
Smaller
Easier to prioritize
Clearer business value
No ‘challenge’ of splitting
Perceived ‘efficiencies’
Accurate estimates
Planning flexibility
Measure of progress
Advantages of larger stories Advantages of smaller stories
Understanding of scope
Finding the right story size can be hard
How do you size your stories?
© 2013 © 2013
Breaking down
stories
How do you size your stories?
§ Agree on target story size with the development team.
§ The exercise is a joint effort with the customer and the development team.
§ Don’t break down stories too soon - progressively elaborate.
§ Use story complexity, operational (eg. CRUD) and data boundaries as guides.
© 2013 © 2013
How do you know when
your story is done?
© 2013 © 2013
How do you know when your story is done?
þ Define “complete” with the customer
þ Write acceptance criteria collaboratively with the customer
þ All the criteria must be met before the story is “complete”
þ Consider using a template
þ Include all Risks, Assumptions, Issues and Dependencies (RAID)
Given <some initial context> when <an event occurs> then <ensure some outcomes>
Tips for writing
acceptance criteria
© 2013 © 2013
How do you know when your story is done?
Be smart with
acceptance criteria
Smart
Measurable
Achievable
Relevant
Timely
Explicitly defined and definite
Possible to observe and quantify
Capable of existing or taking place
Having a connection
When will the outcome be observed?
© 2013 © 2013
Lifecycle of a story
© 2013 © 2013
The fundamental idea is that you do just barely enough
modelling at the beginning of the project to understand the
requirements for your system at a high level, then you gather
the details as you need to…just-in-time.
-- Scott W. Ambler
Lifecycle of a story
”
“
* *
Why “just-‐in-‐time”? § Reduces potential waste.
§ Provides flexibility to change, prioritize.
§ Enables learning from delivery.
§ Tighter feedback loop between business and the delivery team.
*
© 2013 © 2013
Lifecycle of a story
#1. Start at the Product Level
! Develop an understanding of the breadth
§ Objectives/vision statements
§ Elevator pitch
§ Product box
§ User roles & goals
§ Context diagrams
§ High-level domain model
§ Feature lists
§ Paper prototypes
§ …
Product Families
Themes
Feature Sets
Features / Epics
Stories
© 2013 © 2013
Lifecycle of a story
#1. Start at the Product Level
#2. Examine the Release Level
! Take a closer look at a subset of features:
§ Data models
§ Business needs
§ Architectural dependencies
§ Quality attributes (Non-Functional
Requirements)
§ Personas/actors
§ Define epics
§ More paper prototyping
§ …
Product Families
Themes
Feature Sets
Features / Epics
Stories
© 2013 © 2013
Lifecycle of a story
#1. Start at the Product Level
#2. Examine the Release Level
#3. Deep-dive into the Iteration Level
! Go deep, but focusing just on one thin slice
§ User stories
§ Narratives
§ Acceptance criteria and tests
§ Working software
§ Involve Subject Matter Experts
and Stakeholders
§ User and exploratory testing
§ …
Product Families
Themes
Feature Sets
Features / Epics
Stories
© 2013 © 2013
Non-functional
requirements
© 2013 © 2013
Non-functional
requirements as…
Acceptance Criteria
As a customer, I want to be able to pay by
PayPal, so that I can complete my
purchase.
[Acceptance Criteria] - payment confirmed within 5 seconds
- handle 100 concurrent payments
- encrypted redirect to PayPal
…
http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories
© 2013 © 2013
Non-functional
requirements as…
Acceptance Criteria
Separate User Stories As a CTO, I want up to 50 users to be
able to use the application with a five-
user database license, so that I can
minimize ongoing license costs.
As a developer, I want all connections to
the database to be made through a
connection pool, so that ???
http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories
© 2013 © 2013
Non-functional
requirements as…
Acceptance Criteria
Separate User Stories
Constraint Cards
[CONSTRAINT]
As the CTO, I want the system to use our existing
orders database rather than create a new one,
so that we don’t have one more database to
maintain.
http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories
© 2013 © 2013
Story Anti-patterns
© 2013
Story Anti-patterns
Look out for these
smells...
§ Is there any reference to business value?
§ Is your story too detailed. Is it “replacing” the conversation?
§ Do you have trouble prioritizing it?
§ Is it too small or too big to estimate?
§ Does it have implementation details and technical language?
§ Are you thinking *too* far ahead?
§ Is the product owner unable to explain the card to you?
§ Are you splitting it by process lines (analysis/code/test)?
§ Gold-plating?
© 2013 © 2013
Back to our basics
© 2013 © 2013
! Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
! We welcome changing requirements, even late in development.
! Business and IT teams must work together.
Key Agile
principles
© 2013 © 2013
References
§ Cohn, Mike
§ (2004) "User Stories Applied”, Addison Wesley, ISBN 0-321-20568-
§ Non-functional requirements
http://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories
§ Sutherland, J (2007) User Stories Done Right http://www.gbcacm.org/sites/www.gbcacm.org/files/slides/4A%20-%20User%20Stories%20Done%20Right.pdf
§ Wake, B (2003) INVEST acronym http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
§ Meyer, Paul J (2003) SMART acronym "What would you do if you knew you couldn’t fail? Creating S.M.A.R.T. Goals". Attitude Is Everything: If You Want to Succeed Above and Beyond. Meyer Resource Group, Incorporated, The. ISBN 978-0-89811-304-4.
§ Jeffries, Ron (2001) Card, Conversation, Confirmationhttp://xprogramming.com/articles/expcardconversationconfirmation/
§ Lawrence, R (2009) Patterns for Splitting User Stories http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
© 2013 © 2013
How do you get the most out of
your user stories?
Make decisions, not documentation The best Agile requirements are the ones the team builds as they work. Mingle generates actionable project records from natural team collaboration.
Learn More
Agile Project Management
See how Mingle can help you make the most out of your user stories