User Story Functional Vs Technical Stories Definition of Done (Spike) Factors in Prioritization Patterns for Splitting User Stories Relative Estimation Backlog Grooming Sprint Planning (Development & Analysis Stories)

1. User Stories, Prioritization, Estimation &
Enhanced Process Flow
Rosario Poulraj

2. INVEST Model
NDEPENDENT EGOTIABLE ALUABLE
STIMABLE MALL
ESTABLE

3. SMART Tasks
MART EASURABLE CHIEVABLE
EALISTIC IMEBOUND

4. Functional vs Technical Stories

5. Spike Story
• Used for activities such as research, design, investigation, exploration,
and prototyping
• Cannot be estimated until a development team runs a time boxed
investigation
• The output of a spike is an estimate for the original story

6. Definition of Done (Technical Stories)
 Code Review
 Documentation
 Unit Testing
 Demo

7. Definition of Done (Spike Story)
 Proof Of Concept (POC)
 Review (for the approach)
 Further Story Split up (if feasible)
 Estimation of related Stories
 Documentation

8. Prioritization - Factors & Models
Kano Model
1. Threshold (Must have)
2. Linear Features
3. Exciters & Delighters
MoSCoW Model
1. Must have
2. Should have
3. Could have
4. Won't have
Risk-Value Model
1. High Risk – High Value
2. Low Risk – High Value
3. Low Risk – Low Value
4. High Risk – Low Value
Core Factors
 Financial Value
 Cost of development
 Amount of Learning while development
 Amount of risk can be removed by developing

9. Patterns for Splitting User Stories
Strategy 1: Breaking down by workflow steps
Strategy 2: Breaking down by business rules (Special Cases)
Strategy 3: Breaking down by happy / unhappy flow (Validations)
Strategy 4: Breaking down by input options / platform (mobile, desktop, touchscreen)
Strategy 6: Breaking down by operations (CRUD operations - Create, Update or Delete)
Strategy 7: Breaking down by test scenarios / test case
Strategy 8: Break down items based on identified acceptance criteria
Strategy 9: Break Out a Spike

10. Daimler AG
Software Estimation - Techniques
Titel der Präsentation / Abteilung / Datum / Seite 11
 Work Breakdown Structure - WBS (Man Days)
 Function Points (Functional Size Measurement (FSM) of Software)
 Relative Sizing (Story Points / T-shirt)

11. Daimler AG
Merits of Relative Estimation (Story Points – High Level Planning)
Titel der Präsentation / Abteilung / Datum / Seite 12
 Commitment as a “Team” rather than “Individual” (High level plan)
 Story-points estimation is typically faster and Easy to perform
 Story Points reduces fear of commitment (individual)
 Less Pressure on the team, as there is no hourly estimate in the Story level
 Less stress brings better estimates as a Team
 Story Points invites collaboration as team behavior becomes prominent over individuals
 There is credible evidence that humans are good in relative estimation compared to absolute.

12. Daimler AG
Merits of Task Estimates (in Hours)
Titel der Präsentation / Abteilung / Datum / Seite 13
 Absolute Estimates at Lower (Resource) level
 Really feasible (in hours) at the task level rather than the story level (big piece)
 Hourly estimate is more specific to the team member’s ability, hence it differs from person to person
 Individuals can refer the previous tasks, learn from the mistakes to achieve the perfection in upcoming
Task estimates
 Based on the available capacity, the velocity can be re-defined

13. Daimler AG
Backlog Grooming - Process
Titel der Präsentation / Abteilung / Datum / Seite 15

14. Daimler AG
Sprint Planning (Project XXXXXX)
Titel der Präsentation / Abteilung / Datum / Seite 16

15. Project : XXXXXXX
Problem : Too big stories could
not be completed in single sprint
End-goal :Refined Stories
Solution : Altered workflow with
enhanced backlog grooming