Understand Epics and User stories in context of Agile / Scrum

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