This document explains user stories as a method for managing requirements, highlighting their key components: narratives, acceptance criteria, and supporting supplements. It outlines the levels of user stories, from themes to specific stories, and illustrates the requirements gathering process with detailed examples. Additionally, it emphasizes the importance of reusability in user stories, ensuring that they can adapt to changing solutions without altering the underlying problem statement.

1. Managing Requirements with
User Stories
- Vishal Prasad
@AgileMaven

2. Author:
Vishal Prasad
Email:
vishal@AgileMaven.in
Website:
www.AgileMaven.in
Social Media:
@AgileMaven
About

3. What is a User Story?
A user story is a problem narrative
encapsulated by a scope of acceptance
criteria
It is NOT a solution!!!

4. 3 C’s of a User Story
Card
Small enough to fit on a card
and concise enough to be read
& understood or explained
Conversation
It’s a conversation starter,
that’ll lead to a solution derived
by the whole team
Confirmation
It provides a shared
understanding of the problem &
confirms the desired solution

5. Components of a good User Story
Narrative
The most common format is:
As a <user> I want to <the
expected outcome> so that
<business value of the outcome>
Expectations
This formulates 3 to 5
acceptance criteria that define
the scope of the solution and
extract the expected results
from conversations
Tests
These are specifications by
examples. A list of user tests that
are derived by the team and
utilized to confirm the
correctness of the solution
Supplements
Anything that enhances clarity
of the requirement. Typical
examples would include screen
designs, metaphors, architecture
& designs, work agreements, etc.

6. Levels for User Stories
Themes
High level features required by
users. These usually just
contain the narratives since the
scope and boundaries are very
broad.
E.g.: Blog
Epics
Grouping of smaller
independent components
under a theme. These contain
the narratives & acceptance
criteria that are too big to be
implemented in an iteration or a
release.
E.g.: Blog Layout Designer
Stories
Requirements which are ready
for implementation with well
defined and understood
acceptance criteria, tests
specified as examples, and
supplements as part of work
agreements; can be completed
in an iteration or a release.
E.g.: Add component to footer

7. Typical Requirements
Gathering Process
● Identify the Product Vision
● Derive mini Goals / Themes from the vision
● Identify Users who help fulfill goals
● List the Benefits for the users for each goal
● Discuss Alternatives / UX to achieve benefits
● Derive the User Journey for selected alternative
● Write the Epics for components of a journey
● Create a Story Map and carve out your MVP
● Refine epics into Stories during development

8. Example
● Product Vision: An advanced calculator
● Themes: Simple, Scientific, Reverse Polish
Notation
● Users for RPN Calculator: Stack Oriented
Programmer (SOP)
● Benefits: Faster calculation than algebraic
notation calculator due to lesser key strokes
● Alternatives: Binary operations, Unary
operations, Integer operations, Float operations
● User journey for Binary Integer operations:
Accept User Expression > Evaluate Expression >
Perform Calculation > Display Results

9. Example
Epic
Narrative: RPN calculator for binary integer
operations
As a SOP, I want to perform binary operations with
integers on a RPN calculator so that my results are
calculated faster than a algebraic calculator
Acceptance Criteria:
1. I can perform binary operations for integers
2. Supported operators: + - * / %
3. Expressions can be of any length
4. Results must be displayed within 0.1 ms (NFR)

11. Example
User Story
Narrative: Binary integer addition using RPN
As a SOP, I want to perform binary add operations
with integers on a RPN calculator so that my results
are calculated faster than binary add operations on an
algebraic calculator
Acceptance Criteria:
1. I can perform binary add operations for integers
2. Expressions can be of any length
3. Results must be displayed within 0.1 ms (NFR)

12. Example
Specification by example using
Behavior Driven Development
(BDD Gherkin scripts)
Can be used as regression and UI
tests as well
Scenario: Results displayed within 0.1ms
GIVEN input string is “2,3,+”
WHEN the action is to calculate
THEN the output is “5”
AND the output is displayed within 0.1 ms
Scenario Outline: Adding valid binary RPN notations
GIVEN input string is <expression>
WHEN the action is to calculate
THEN the output is <result>
EXAMPLES:
| expression | result |
| “2,3,+” | “5” |
| “4,5,+,6,+” | “15” |
| “6,7,a,4,+” | ‘Invalid” |

13. Example
Supplements
Screen Design
Coding Guidelines
Etc.

14. Acceptance Test Driven Development (ATDD)

15. A user story must be reusable. Since your
problem statement doesn’t change, the story
shouldn’t change either. The solution may
change.
E.g.: a story to check your bank balance must
not change for a desktop or a mobile
application since the user problem stays the
same. Your supplements may change.

16. You are now ready for development
Please provide your feedback and ratings for this presentation