Epics and User Stories

Agenda

Need of Epics and User Stories

Understanding Epics

Understanding User Stories

Need

There should be a way to: define requirements / features at high level

break high level requirements into smaller understandable pieces

quickly estimating of schedule (both short term and long term)

prioritizing requirements of higher business value over lower ones

communicate requirements to development team more simply / effectively

Epic

Epic

Product Backlog item or User Story too big to complete in 1 Sprint

Simple Epic

may be small enough to be completed in as few as two Sprints

need to be broken down so that the team can deliver value in a given Sprint – Done at Backlog Refinement

Large Epic

might take the entire company several Quarters or Years

Requires the PO to work with Leadership and the Team to create Road Map, so most valuable features are created first

Epic as PBI (Product Backlog Item)

Most User Stories or PBIs as originally written are Epics

Usually written by a PO or a Customer with knowledge of the product but not of the development process

Backlog Refinement meeting is where the Team works with the PO to break the Epic down appropriately

Epics and Business Value

Epics are components of the Enterprise’s vision

Business Value can be best estimated at this level

Levels

Daily level

Sprint level

Release level

Product level

Version / Theme / Large Epic

EPIC 1 / Feature 1

Story 1

Task 1

Story 2

EPIC 2

Story 1

Task 1

Break Epics into Stories

As a frequent flyer I want to book flights customized to my preferences, so I save time

As a frequent flyer I want to book a trip using miles so that I can save money

As a frequent flyer I want to easily book a trip I take often so that I can save time

As a premium frequent flyer I want to request an upgrade so I can be more comfortable

User Stories

What is a User Story?

Simple, Clear, short description of customer valued functionality

User Stories are NOT part of the Scrum framework

User Stories are an eXtreme Programming technique

This may optionally be used to capture Product Backlog Items

The Product Backlog is the Scrum Artifact

User Stories capture Who, What and Why of any requirement

3Cs – Card, Conversation, Confirmation

Conversation rather than documentation

Leveraging User Roles and Personas

Write story from user’s perspective

Understand the user’s goal for the story

Understand the user’s value from the story

Use human users

Avoid generic “as a user” or “as a customer”

If you have identified Personas, the story could be written from the point of view of this character/user

User Story Template

Title: Priority:

As a [type of user], I want [goal] so that

[Value]

Notes:Assumptions:Constraints:

Estimate:

User Story Example

Checkout Using Credit Card

Priority: 25

As a book shopper, I can checkout using my credit cardSo that I can purchase a selected book.

Notes: Support mc, visa, amex

Constraints: Must use SBI payment gatewayEstimate: 13pts

Acceptance Criteria

Given [context]

When [some event]

Then [outcome]

Acceptance Criteria

Checkout using Credit Card

Test with valid mc, visa, amex - passes

Test with valid other cards – fails

Test with expired cards – fails

Test with invalid cvv – fails

Test with invalid zip – fails

Collaboration

Conversation

How do I describe what I want?

How do I validate that this work is done?

How do I code this feature?

What are the details of this feature?

Progressive Elaboration

Upcoming Sprint

Future Sprint

Next Release

Attributes of a Good User Story

Good User Story can be written by following I.N.V.E.S.T.

I = Independent

N = Negotiable

V = Valuable

E = Estimable

S = Sizeable small to be completed in a Sprint

T = Testable

Additional Documentation

The conversation might lead to additional documentation

HLD document

Detailed design document

Specifications document

RTM

Test Plan

Wireframes

Use cases

Just in time documentation

Just enough documentation

Which is Most Important?

Who – As a type of user ..

What – I want..

Why – So that..

How – Conversation..

Acceptance Criteria..

When to Split User Stories

Split stories that are dependent on each other

Split stories that are too big

Split stories into spikes if complex or risky

Split compound stories

A good rule of thumb is to watch out for conjunctions:

As a restaurant seeker I need to be able to find a restaurant that fit my taste and budget and is close to my location and that takes online reservations so that I can plan a dinner outing with friends

How to Split User Stories

Stories should represent some level of end to end functionality

Do not split into task like design, code frontend, code middle tier, code backend

Deliver cohesive subset of all layers

Do simplest thing that could possibly work

Vertical Slicing

Client application

Web Interface

Business Logic

Database

Story 1Story 2

Story 3

Pattern for Splitting Stories

Cross Cutting Concerns

Security

Logging

Error handling

Performance

Priority

Necessity

Flexibility

Safety

Comfort, luxury, performance

Business rules

Building the Initial Product Backlog

1. What are the high level stories (epics) ?

2. What are the stories ?

3. Which epics are most important ?

MOSCOW, Kano, ROI, NPV, NPV/point

4. Which stories are most important within a epic ?

5. What transaction by which user yields the most immediate revenue, Do this first.

6. This starts to generate a single ordered list – the Product Backlog

7. Get the top of the Product Backlog READY for the first Sprint

28

Q&A

29

Manish Agrawal, [CSP]

Thanks