Managing Requirements with User Stories

- Vishal Prasad

@AgileMaven

Author:

Vishal Prasad

Email:

vishal@AgileMaven.in

Website:

www.AgileMaven.in

Social Media:

@AgileMaven

About

What is a User Story?

A user story is a problem narrative encapsulated by a scope of acceptance criteria

It is NOT a solution!!!

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

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.

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

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

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

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)

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)

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” |

Example

Supplements

Screen DesignCoding GuidelinesEtc.

Acceptance Test Driven Development (ATDD)

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.

You are now ready for development

Please provide your feedback and ratings for this presentation