In Agile, Definition of Ready is as important as Definition of Done Requirements shall be simple enough to understand Requirements shall be clear enough to be worked upon
For Road Map or Most Valuable Features (MVP) --remember 80:20 rule for refinement for prioritization Story Points, EPIC & User Stories --are Scrum but --these terms have come from XP
Use Case Vs User Story --Use case is different from User Stories --In Use Case, focus is on how user will act with the system --User Story is from users perspective – as a user - I want feature - so that
Vertical Slicing has to be done to get complete feature to be usable
E.g. Payment Story can be divided into 3 stories Visa - (used by 80%) – so shall be taken first - Priority 1 Master – (used by 15%) – Priority 2 AMEX – (used by 5%) – Priority 3
Stories when divided into sub stories goes thru Progressive Elaboration Refinement – Make each user story a better user story
Personas – can be used for outliners Don’t use the term user or customer, those are very generic, e.g. use frequent flyer.
Write them down, be it Notes, Constraints, Risks, Assumptions No harm and it helps in prioritization, estimation
UX has to be mentioned in the requirements
Behavior Driven Development As a good P.O. you need to have Acceptance Criteria for every user story
Should not say -implementation details -it is from user’s perspective
Thought Process in writing a User Story This can be done, by PO in Collaboration with Customer or PDM Collaboration is aggregation/collection of requirement / information at one place, and also mentioning about, once done how it can be validated to be done
Scrum doesn’t say no documentation You have to do required documentation Just keep it lean
Spikes Place holder for research Hard to estimate Time box the spike After that take a decision Otherwise it will keep going What POC is required
For Splitting – Value to be there
Make a separate story for Security, Logging, Error Handling – spreading across components
MoSCoW M – MUST have this in order for the product to function S – SHOULD have this if at all possible C – COULD have this if it does not affect anything else W – WON’T have this time but WOULD like in the future
Kano model is a theory of product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories. 1. Must-be Quality, 2. One-dimensional Quality, 3. Attractive Quality, 4. Indifferent Quality, 5. Reverse Quality
NPV – Net Present Value IRR – Internal Rate of Return ROI - Return on Investment
Epics and User Stories
Epics and User Stories
Need of Epics and User Stories
Understanding User Stories
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
Product Backlog item or User Story too big to complete in 1 Sprint
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
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
Product level Version / Theme / Large Epic
EPIC 1 / Feature 1
Break Epics into Stories
As a frequent flyer I want to book flights customized to my preferences, so I
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
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
As a [type of user], I want [goal] so that
User Story Example
Checkout Using Credit
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
When [some event]
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
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?
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
The conversation might lead to additional documentation
Detailed design document
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..
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
Deliver cohesive subset of all layers
Do simplest thing that could possibly work
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
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