It's told that if you don't like a cat you just don't know how to cook it. It's the same if we're talking about estimating and prioritizing user stories. This time we will back to unfinished the subject about bad examples of user stories and the stuff which one don't know how to treat as the user story. We will talk about which role, when and how work with user story and cover the main principles of user stories (no)estimations. Subjects: - What is and what is not a user story? - Who, when and why — roles and ceremonies. - To estimate or not to estimate? - Case studies/practice

1. Vladimir Tarasow
How to cook a cat?
User Stories

2. Vladimir Tarasow
About: http://about.me/netrat
E-mail: netrat@netrat.eu

3. User Story

4. User Story
Represent a description of a “solution” —
from a functional point of view.
Should cut through all the layers of
the architecture.
Must contain also Acceptance Criteria that
describes how the user of the story would
accept the implemented functionality.

5. INVEST Model
Independent. Easier to plan, if it has no
dependencies.
Negotiable. Details added via collaboration.
Valuable. Provides value to the customer.
Estimable. If it's too big or too small, you
can't estimate it.
Small. Can be done in less than a week by
the team.
Testable. Good acceptance criteria.

6. What is and
what is not
a User Story?

7. Bad User Story Example #1
User Story: Design brochure layout.
Drawbacks:
● Hard to say is it Independent or not.
● No business Value.
● This is a task representing a horizontal
architectural layer or phase.
● It can not be analyzed.

8. Task
The part of User Story which has no value
by itself.
You can't demonstrate the task by its own.
Understandable User Stories can be divided
into tasks at any moment.
Dividing into tasks helps to estimate User
Story and expose additional work amount.

9. Bad User Story Example #2
User Story: As a cinema fan I want to feel
spatial movement so that I will immerse
into action deeper.
Drawbacks:
● Not Small.
● Not Estimable.

10. Bad User Story Example #2
That's how this story looks like in real life.
Can you explain how to reach it?

11. Epic
An Epic is a big story.
It entails a sequence of actions that follow
a specific order.
Should be broken down and specified.

12. Theme
Is a collection of related user stories.
Describes a view of a tangible product or
an abstract goal.
Often used to organize stories into
releases.
Often used to organize user stories so that
various sub-teams can work on them in-
parallel.

13. Bad User Story Example #3
User Story: Verify that text entered in
"password" text box is masked.
Drawbacks:
● No business Value.
● Nothing to negotiate.
● Doesn't cut through all the layers of the
architecture.

14. Test Case
Is not an acceptance criteria.
But derived from acceptance criterias.
Are specific steps to check a feature
behaves as expected.
Not necessary to plan an iteration.
Can be written in the same iteration as the
code, before or in parallel with developing
the code.

15. Bad User Story Example #4
User Story: After the user has selected
items to purchase and then order the
items. The user will provide payment and
shipping information. The system will
respond with confirmation of the order and
a tracking number that the user can use to
check on order status in the future. The
system will also provide the user with an
estimated delivery date for the order.

16. Use Case
Is a list of steps defining interactions
between a role and a system, to achieve a
goal.
Сonsist of two components: use case
diagrams and the text.
Typically contains more details than
stories and traditional requirements.

17. Iterative & incremental development
Rational Unified Process (RUP).
It often uses Use Cases which are similar to
User Stories.
It's iterative development process.
It must meet all the objective in the end of
release.

18. Iterative & incremental development

19. Bad User Story Example #5
User Story: As Product Owner, I want a list
of highly-rated restaurants on the
brochure.
Drawbacks:
● It’s not only about you!
● Not Valuable enough. Focus on your end
users and stakeholders.

20. Technical Story
Needs to be done but can't be delivered.
Doesn't directly relate to any specific
stories.
Haven't direct value to the product owner.
Try to avoid tech stories.
Transform a tech story into a normal story
with measurable business value or into a
task within another story.

21. Bug
PO gets the most high priority item from
bug tracking system and put it into product
backlog.
PO creates stories that refer to items from
bug tracking system.
Bug-fixing is considered to be outside of
the sprint.

22. Who?
What?
When?

23. Stakeholders
Can't affect user stories directly.
However…
Create requirements.
Define the value.
Define priorities.

24. Scrum Master
Can't affect user stories directly.
However…
Helps PO to organize Sprint
Planning Meeting.
Helps the Team to develop
Stories by removing
impediments.
Helps the Team in preparing
the Review Meeting.

25. Product Owner
Adds or removes User Stories.
Prioritizes User Stories.
Selects User Stories to be
done during the next
iteration.
Breaks down User Stories and
Epics.
Accepts produced User
Stories.

26. Team
Estimates User Stories for
the iteration.
Breaks down User Stories to
tasks.
Develops User Stories.
Apply quality during User
Story development.
Demos User Stories to PO.

27. The Life of
User Story

28. The Life of User Story

29. DEEP
Detailed Appropriately
Estimated
Emergent
Prioritized

30. The Life of User Story

31. Splitting User Stories
By variations in data.
By workflow steps.
By data entry methods.
By business rules variations.
By operations (CRUD).
By major effort.
By simple/complex cases.
Defer performance.

32. The Life of User Story

33. The Life of User Story
Creating and adding details to
requirements might take 1-2 years.
MMFs and Epics are used for medium term
planning from 1/2 to 1 year.
User stories is for short term planning from
about 4 to 8 weeks.

34. Thank You!
Please, leave feedback!
http://spkr8.com/t/23171

35. Materials used in the presentation:
● 'User Stories, Epics and Themes' by Mike Cohn
● 'User Stories' by Mark Levison and Charles Bradley
● 'When To Write Story Tests' by Rachel Davies
● 'Basic use case template' by Alistair Cockburn
● 'IBM Rational Unified Process' from Wikipedia
● 'How To Split User Stories' by Dan Puckett
● 'Business Value Game' by Andrea Tomasini
● '#NoEstimates Part 1: Doing Scrum without estimates' by Neil Killick
● 'Purpose Of Estimation' by Martin Fawler
● Iterative development by Dutchguilder
● Photo by Geoff Gallice
● Photo by Chiara Vitellozzi
● Illustrations by Vladimir Tarasow
Credits

36. This work is licensed under the Creative Commons Attribution-
NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this
license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/.