splitting user stories - why and how?
TRANSCRIPT
Splitting User Stories
Why and How?Ashwin Chandrasekaran
We talk about three topics in this presentation
What are User Stories?
Why split them?
How to split them?
What are User Stories?
User Story
User Story is an unit requirement written in business language that can
be developed, tested and delivers tangible value to end user
User Story Example
As a Ground Handling Agent, I want the flights in watchlist to move to departed section, so that I know they
are departed In addition, an user story contains:
- Story Description- Acceptance Criteria- Estimation- Priority
Why split them?
What is the ideal size of an User Story?
2 hours
4 days
8 days
20 days
40 days
1/2 -10 daysOptimal time to finish an User Story (including testing and integration)
3 Reasons to Split User Stories
Reason #1 : Difficult to Prioritize
Story 1 : 30 Days
Story 2 : 20 Days
Story 1 : 5 Days
Story 2 : 8 Days
Story 3 : 9 Days
Story 4 : 4 Days
Story 5 : 3 Days
Which is easy to prioritize?
But prioritization cannot be avoided
Not enough room here...
Easier for PO to play around...
Reason #2 : Plan is Rigid
Typical Sprint Velocity is around 40-50 Ideal Days
Story 1
30 Effort Days
Story 2
20 Effort Days
Story 1
8 ED
Story 2
7 ED
Story 3
5 ED
Story 4
6 ED
Story 5
9 ED
Story 6
5 ED
Story 7
5 ED
Reason #3 : Estimation Inaccuracy increase with Size
I can have the foundation done in 2 months.
I can complete the living room in 2 months, bedrooms in 3 months, kitchen in 1 month and toilets in 1 month
Last month is for painting and furniture
I can build the house in 1 year
How to Split User Stories?
Strategy #1 : Along Data Boundaries
User must be able to view information coming into the
system from Interface A, B, C
User must be able to view information coming into the
system from Interfaces D, E, F
User must be able to view information coming into the system from all the Interfaces.
Strategy #2 : Separate Exception / Error Handling
User can enter flight details and save them
Validation must be performed on flight data entered by user and
errors displayed
User can enter flight details and save them. Validation on flight data must be performed and
errors displayed
Strategy #3 : Based on Operations Performed
User can view all details about the flight
In the flight view screen, user can edit/save CDM fields that
are enabled
User can view all details about the flight and edit/save CDM fields that are enabled
Strategy #4 : Separate CRUD Operations
User can view existing parking stand information and create
new ones
User can update and delete existing parking stand
information
User can create, view, update and delete information related to Parking Stands
Strategy #5 : Separate Functional and Non-functional
User must be able to update TOBT value and results
displayed
User must be able to view TOBT update results within 10
seconds
User must be able to update TOBT and the result must be displayed within 10 seconds
Strategy #6 : Smaller Stories of Different Priorities
User must be able to generate a report that shows Air Traffic
over past 6 months
User must be able to print the Air Traffic Report
User can generate a report that shows the Air Traffic over past 6 months and also be able to print
itPriority 1 Priority 2
To Summarize...
Splitting User Stories
User Story describes a unit requirement in business language
Typical size of a User Story is 0.5 - 10 Effort Days
Splitting User Stories help in : Easier Prioritization, Planning and Better Estimation
Some ways to Split Stories are : Along Data Boundaries, Separating Exception Handling, Operations performed, CRUD operations, Separating Functional/Non-Functional, Smaller Stories of different Priorities
Thank you!
Most ideas are taken from the book - User Stories Applied by Mike Cohn. I strongly suggest you to grab a copy and a coffee!