This document discusses epics and user stories in agile software development. It defines epics as large features or requirements too big to complete in a single sprint that need to be broken down into smaller user stories. User stories are simple descriptions of features written from the perspective of the end user that follow a who, what, why template. The document provides examples of epics and user stories and guidelines for when and how to split large stories or epics into smaller independent stories that can be estimated and implemented within a sprint.

1. Epics and User Stories

2. Agenda
 Need of Epics and User Stories
 Understanding Epics
 Understanding User Stories

3. 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

4. Epic

5. 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

6. 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

7. Epics and Business Value
 Epics are components of the Enterprise’s vision
 Business Value can be best estimated at this level

8. 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

9. 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

10. User Stories

11. 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

12. 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

13. User Story Template
Title: Priority:
As a [type of user], I want [goal] so that
[Value]
Notes:
Assumptions:
Constraints:
Estimate:

14. User Story Example
Checkout Using Credit
Card
Priority: 25
As a book shopper, I can checkout using my credit card
So that I can purchase a selected book.
Notes: Support mc, visa, amex
Constraints: Must use SBI payment gateway
Estimate: 13pts

15. Acceptance Criteria
 Given [context]
 When [some event]
 Then [outcome]

16. 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

17. 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?

18. Progressive Elaboration
Upcoming Sprint
Future Sprint
Next Release

19. 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

20. 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

21. Which is Most Important?
 Who – As a type of user ..
 What – I want..
 Why – So that..
 How – Conversation..
 Acceptance Criteria..

22. 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

23. 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

24. Vertical Slicing
Story 1
Story 2
Story 3

25. Pattern for Splitting Stories
 Cross Cutting Concerns
 Security
 Logging
 Error handling
 Performance
 Priority
 Necessity
 Flexibility
 Safety
 Comfort, luxury, performance
 Business rules

26. 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

27. 28
Q&A

28. Manish Agrawal, [CSP]
29
Thanks