User story as a tool in agile. Writing good user stories. Slicing/splitting of user story. Prioritization and Estimation of user story.

1. Story of User Story
Balaji Sathram, CSP, PMI-ACP.
Scrum master, Sabre.

2. Agenda
• User Story-History
• User Story - Brief
• User Story-Templates
• Writing good user stories
• Slicing user stories
• To maintain good user stories
• Additional Terms
• User Story - Prioritization
• User Story - Estimation

3. User Story-History
• Comes from XP (eXtreme Programming)
• 1999: Kent Beck coined the term user stories in Extreme
Programming Explained 1st Edition
• Documenting requirements to Explaining (Tell story about what you
want): Building a common and shared understanding.
• People started following it. But The sad part of the whole episode
is: instead of telling stories, people started writing stories.
• Organizations started documenting user stories:
"shared documents are not shared understanding"

4. User Story - Brief
What is User Story:
• A concise written description of a piece of functionality that will be
valuable to a user (or product owner) of the software.
• All about the user’s goals
• Carries the value stream to the user
• It contains:
• Value: Requirement of a customer
• Cost: an understanding of what it takes to build
• Validation: that you understand what is happening

5. User Story-Templates
As a <WHO|ROLE>
I want <WHAT|FEATURE>
So that <WHY|PURPOSE>
OR
Given [context]
When [event]
Then [outcome]

6. Story Inputs

7. XP Stories – Ron Jeffries – 3Cs
• In 2001
• Card: Write stories on a card. Just enough
to identify the requirement.
• Conversation: Most of the requirement is
communicated through a conversation.
Information can be stored elsewhere. The
story is a holder for these.
• Confirmation: “How will we know we’ve
done that.” We also need an acceptance
test.

8. User Story Description
• It is written down on a note card
(e.g. 3x5 inches or 8x13 cm)
• Start with a title.
• Add a concise description using the
templates.
• Add other relevant notes,
specifications, or sketches
• Before building software write
acceptance criteria (how do we know
when we’re done?)

9. Writing good user stories
• Independent – User Stories should be as independent as possible.
• Negotiable – A User Story is not a contract. It is not a detailed specification.
Story cards are short descriptions of functionality, the details of which are to
be negotiated in a conversation between the customer and the development
team
• Valuable – User Stories should be valuable to the user (or owner) of the
solution. They should be written in user language. They should be features,
not tasks.
• Estimable – User Stories need to be possible to estimate. They need to
provide enough information to estimate, without being too detailed.
• Small – User Stories should be small. Not too small and not too big. DONE in
one iteration
• Testable – User Stories need to be worded in a way that is testable, i.e. not
too subjective and to provide clear details of how the User Story will be
tested. if you can’t test it, you don’t know when you are done

10. Slicing user stories
• Breaking them down

11. Slicing User Stories
• Split by workflow steps
• Split by business rules
• Split by happy/unhappy flow
• Split by input options / platform
• Split by test data or data types or parameters
• Split by operations(CRUD)
• Split by test scenarios/test case
• Split by Roles
• Split by external dependencies
• Split based on Mock/Real services
• Split based on acceptance criteria
• Split based on Usability

12. Some Additional Useful Terms
• Definition of Ready
• Definition of Done
• Acceptance Criteria
• Theme and Epic

13. Definition of Ready
From Team to Product Owner
• No Open questions
• Test data collected
• No technical dependencies
• Workflow figured out
• Acceptance criteria understood
• Estimated
• Has some business value
• Sized appropriately

14. Definition of Done
From Team to the Team
• Architectural Review Complete
• Code Review Complete
• Unit Tested
• Test Scenarios Review with BA/PO/Team members
• QA tested
• PO/BA Acceptance
• No Priority 1 or Priority 2 bugs
• Integration
• Known deployment & Rollback plan

15. Acceptance Criteria
From Product Owner to the Team
• Agreement between the team and the PO on when the story is
accepted

16. Theme and Epic

17. PRIORITIZATION

18. Prioritization
• High-Medium-Low
• MoSCoW
• Kano Analysis
• 1-2-3-4-5
• Stacked Ranking
• Impact Analysis

19. MoSCoW
• A method to prioritize requirements popularized in the DSDM
(Dynamic systems development method) community is MoSCoW
• Must Have, Should Have, Could Have and Won’t Have

20. Kano Analysis
• Kano Analysis is a quality measurement tool used to prioritize customer
requirements based on their impact to customer satisfaction.
According to the Kano Model (developed by Dr Noriaki Kano in
the 1980s), a product or service can have three types of
attribute (or property):
• Musts: Which customers expect to be present in a product.
• Satisfiers: Which are not absolutely necessary, but which are
known about and increase the customer's enjoyment of the
product.
• Delighters: Which customers don't even know they want,
but are delighted when they find them.

21. Impact Analysis
• For every user story, give impact points based on below questions
• What is the impact it is creating if it is implemented
• What is the impact it is creating if it is not implemented
• Multiply both the values which will result in impact score for the user
story
• Higher the score higher the impact

22. ESTIMATION

23. Estimation

24. User Story - What do we Estimate?
Complexity
Uncertainty
Effort

25. Story Points
• Story Points are the unit of measurement for expressing the overall size of a user story,
feature, or other piece of work.
• The number of story points associated with a story represents the overall size of the story.
• Either Doubles OR Fibonacci Series
Non Linear Scale - Fibonacci Series [1,2,3,5, and 8]
Non Linear Scale - Doubles [1,2,4, and 8]

26. Estimation Techniques
• Agile Relative Sizing
• Ideal Days
• Planning Poker
• Wideband Delphi
• Affinity Estimating

27. Relative Estimation

28. Ideal Days
How long something would take if
• It’s all you worked on
• you had no interruptions
• and everything you need is available
Factors Affecting Ideal Time:
Training, Email, Reviews, Interviewing, Demonstrations, Meetings, Sick Time,
Phone, Bug Fixing, Management review

29. Planning Poker
An iterative approach to estimating
Steps:
• Each estimator is given a deck of cards, each card has a valid estimate
written on it
• Customer/product owner reads a story and it’s discussed briefly
• Each estimator selects a card that’s his or her estimate
• Cards are turned over so all can see them
• Discuss differences (especially outliers)
• Re-estimate until estimates converge

30. Wideband Delphi
Is a process that the team can use to generate an estimate
Process:
• Choose the team
• Kick off meeting
• Individual preparation
• Estimation session
• Assemble tasks
• Review results

31. Affinity Estimation (Lowell Lindstrom)
Affinity estimating is a technique many teams use to quickly and easily
estimate (in story points) a large number of user stories.
• Product backlog is provided by the product owner
• Team members are expected to size each item relative to other items
on the wall considering the effort involved in implementation
• Stories are arranged horizontally

33. Thank you