Your SlideShare is downloading. ×
Agile planning
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Agile planning

602
views

Published on

Published in: Technology, Real Estate

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
602
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Agile PlanningPresented by Juan Banda
  • 2. Time vs. SizeTime is not visual Size is 2
  • 3. Why do we estimatesize?•Time-basedestimates dependon who does thework•Size-based are notbiased by individualjudgment•Using size-basedestimates providealso estimates aboutrelative complexity 3
  • 4. Relative sizeestimation•Independent of whoimplements•Sizing is easy, relativeto baseline and otherstories•Planning Poker scale issuitable for humans•Fast 20 stories / hour•Accurate ‘PlanningPoker’ combines Delphiwideband with expertestimating 4
  • 5. Planning Poker•This very simple techniqueneeds that all teammembers vote –using cardsor paper slips– about thesize they think a user storyhas•No talking in the firstround, just voting•The ScrumMaster askquestions to the ones thatvote extreme values•A second round is called•Mean or mode values areassigned as user storysizes 5
  • 6. Velocity• What is velocity? •Rapidity of motion• Why use it? It help us to • estimate next sprints•3 Sprints rule•Initial estimates 6
  • 7. When should weestimate?PO should have team size all•known stories for entire releaseprior to first sprint •Do this as part of the story- writing workshop •Need sizes to create a release plan•PO should call an estimationmeeting during each sprint forthe team to size new or splitstories for up-coming sprints •Update release burn down chart with changes to the release backlog •Team must allow time during the sprint for this— typically 1 or 2 time-boxed meetings per sprint 7
  • 8. When should were-estimate?Actual velocity is lower than•estimated •Velocity will automatically correct underestimation, no re-estimation neededTeam changes• Velocity will reflect any • change in capacity, no re- estimation neededGoal-level or epic story is split• New ‘child’ stories must be • estimated (independent of original story size)•Relative size of story changes(new understanding) •Story should be re-estimated relative to other (known) stories 8
  • 9. Release planning•With all the user storiesestimated using planningpoker, the PO can work ona general estimate for whenthe project will be delivered•This is not fortune telling, itcan be err by some factorbut its not a wild guess•Research shows thatplanning a release usingthis technique is as muchas accurate as any otherestimation based onmathematical models, buttimes cheaper in time andresources 9
  • 10. Thanks for attending