際際滷

際際滷Share a Scribd company logo
User Stories, Prioritization, Estimation &
Enhanced Process Flow
Rosario Poulraj
INVEST Model
NDEPENDENT EGOTIABLE ALUABLE
STIMABLE MALL
ESTABLE
SMART Tasks
MART EASURABLE CHIEVABLE
EALISTIC IMEBOUND
Functional vs Technical Stories
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
Definition of Done (Technical Stories)
 Code Review
 Documentation
 Unit Testing
 Demo
Definition of Done (Spike Story)
 Proof Of Concept (POC)
 Review (for the approach)
 Further Story Split up (if feasible)
 Estimation of related Stories
 Documentation
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
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
Titel der Pr辰sentation / Abteilung / Datum / Seite 11
Software Estimation - Techniques
 Work Breakdown Structure - WBS (Man Days)
 Function Points (Functional Size Measurement (FSM) of Software)
 Relative Sizing (Story Points / T-shirt)
Titel der Pr辰sentation / Abteilung / Datum / Seite 12
Merits of Relative Estimation (Story Points  High Level Planning)
 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.
Titel der Pr辰sentation / Abteilung / Datum / Seite 13
Merits of Task Estimates (in Hours)
 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 members 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
Titel der Pr辰sentation / Abteilung / Datum / Seite 15
Backlog Grooming - Process
Titel der Pr辰sentation / Abteilung / Datum / Seite 16
Sprint Planning (Project XXXXXX)
Project : XXXXXXX
Problem : Too big stories could
not be completed in single sprint
End-goal :Refined Stories
Solution : Altered workflow with
enhanced backlog grooming

More Related Content

Agile processpresentation-for-my-project-xxxxxxxx

  • 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
  • 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. Titel der Pr辰sentation / Abteilung / Datum / Seite 11 Software Estimation - Techniques Work Breakdown Structure - WBS (Man Days) Function Points (Functional Size Measurement (FSM) of Software) Relative Sizing (Story Points / T-shirt)
  • 11. Titel der Pr辰sentation / Abteilung / Datum / Seite 12 Merits of Relative Estimation (Story Points High Level Planning) 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. Titel der Pr辰sentation / Abteilung / Datum / Seite 13 Merits of Task Estimates (in Hours) 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 members 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. Titel der Pr辰sentation / Abteilung / Datum / Seite 15 Backlog Grooming - Process
  • 14. Titel der Pr辰sentation / Abteilung / Datum / Seite 16 Sprint Planning (Project XXXXXX)
  • 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