Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Iasi CodeCamp 20 april 2013 Agile Estimations and Planning - Cornel Fatulescu


Published on

Published in: Sports, Technology
  • Login to see the comments

  • Be the first to like this

Iasi CodeCamp 20 april 2013 Agile Estimations and Planning - Cornel Fatulescu

  1. 1. Agile estimations andPlanningCornel FATULESCUagile coach
  2. 2. Did It Ever Happen to You?• Who the ... made this estimation?• Sorry it will take me than … hours!• I hope we’ll deliver tomorrow.• I can’t tell you how much time it will take!• We don’t have time for testing• …2
  3. 3. Usual solution3
  4. 4. Classical IT services supplier scenario4Sales Start-upOngoingprojectSomeexpertsSome membersof newly createdteamThe teamBasicknowledgeSomeknowledgemight be lostGroomingsessionsReleasePlanningCapitalizeRFPKnowledgeDoR DoDEstimationsInitial ReleasePlanningProduct VisionInitial BacklogGoalsProblem 1How toestimatefeatures?Problem 2How toplan?
  5. 5. How to estimate features ?• What does the team need for each feature inorder to increment it?• How features become part of the increment?• Estimate the features!5Definitionof ReadyDefinitionof DoneRelativeEstimations
  6. 6. Feature metamorphosis flow!6Suggestion Assumed Estimated Ready In ProgressPre-ProductionProductionDone
  7. 7. Feature metamorphosis flow!7Suggestion Assumed Estimated Ready In ProgressPre-ProductionProductionDone? ? ? ?ReleasePlanningEnd of Release…………………………………………………… ……
  8. 8. Sample of Definition of Ready for a feature8Story clarifiedTasks identifiedStory estimatedAcceptance criteriaClear dependenciesScrum Team accepts the storyResponsible for acceptanceUser story complies INVEST rules…
  9. 9. Sample of Definition of Done for a feature9Design completeDevelopment completeCode commentedStatic code quality analysisUnit testing is doneCode RefactoringCode checkinContinuous buildTestsDocumentation ReadyPeer reviewsJira is updatedStory is accepted
  10. 10. Why relative estimations?• Product Owner: How long it will take todeliver feature A?• 1st team member : 3 Days• 2nd team member: 6 Days10Bothestimationsmight beright!
  11. 11. Why relative estimations?• Product Owner: How long it will takeCompared to feature B we’ve done the lasttime?• 1st team member : 3 times more• 2nd team member: I agree, 3 timesmore11
  12. 12. Measure the size, calculate the time12Velocity =𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒𝛥𝑡𝑖𝑚𝑒𝛥𝑡𝑖𝑚𝑒 =𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦
  13. 13. Measure the size, calculate the time13Velocity =𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒𝛥𝑡𝑖𝑚𝑒𝛥𝑡𝑖𝑚𝑒 =𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦
  14. 14. It’s effort, not complexity14“In a class a few years back, I was given a wonderfulexample of this. Suppose a team consists of a littlekid and a brain surgeon. Their product backlogincludes two items: lick 1,000 stamps and perform asimple brain surgery–snip and done. These itemsare chosen to presumably take the same amount oftime. If you disagree, simply adjust the number ofstamps in the example. Despite their vastly differentcomplexities, the two items should be given thesame number of story points–each is expected totake the same amount of time.”-Mike Cohn
  15. 15. Visualize the estimations15ToestimateFeature 2Feature 5Feature 6Feature 7Feature 8Feature 9Feature 111 SPFeature 1Feature 43Feature 32Feature 21Feature 232 SPsFeature 3Feature 4Feature 183 SPsFeature 10Feature 885 SPsFeature 13Feature 158 SPsFeature 225 SPs 6 SPs 6 SPs 10 SPs 8 SPs35 SPs
  16. 16. How to plan?16Ourconcern?ReleasePlanningProcessSprintDoR, DoDReleaseDoR, DoD
  17. 17. What is release planning?17• It is a process not an event!Release Planningat projectstart-upSprint 1 Sprint 2 Sprint 3ThroughGroomingSessionsIn Scrum nomore than10% of theSprintUsually moreeffort neededthan in a sprint
  18. 18. Sample of Definition of Ready for a sprint18Sprint goalThe Sprint Backlog is prioritizedNo hidden workCalculated capacityTeam accepted the Sprint BacklogAll stories meet definition of readyList of stories for regression testing
  19. 19. Sample of Definition of Done for a sprint19Release BuildFunctional testing doneRegression testing doneAcceptance testing done by the Product OwnerClosure
  20. 20. Sprint Context20Team sizeFocus factorSprint sizeCalendar daysVelocity6 People70%2 weeks10 Days16 SPs
  21. 21. Estimate 1 SP21• Estimate in hours several features– Ex: Feature 1• Estimated initially at 3 SPs• Estimated in man days at 6 days• =>1 SP = 2 days• Ask the team directly how they evaluate 1SP?• Experience and measure
  22. 22. Calculate Sprints Velocity22Sprint 1 Sprint 2 Sprint 3Person days in sprint = calendar days *team size60 60 60Ideal person days in sprint = person daysin sprint * focus factor42 42 42Sprint ideal man days1st sprint = (1-40%) * ideal person days2nd sprint = (1-20%) * ideal person days3rd sprint = ideal person days25 33 42Velocity = Sprint ideal man days/1 SP 16 22 28Team size Focus Factor Sprint Size CalendarDays1 SP?6 70% 2 weeks 10 Days 1.5 Man Days
  23. 23. Simulate sprints23Backlog5 SPs3 SPs8 SPs13 SPs1 SP2 SP1 SPSprint 13 SPs1 SP1 SP5 SPs2 SPs2 SPs1 SPsSprint 25 SPs3 SPs5 SPs2 SPs5 SPs2 SPsSprint 33 SPs5 SPs3 SPs5 SPs1 SP5 SPs2 SPs5 SPs…1st SprintVelocity 16SPs2nd SprintVelocity 22SPs2nd SprintVelocity 28SPs
  24. 24. Measure and re-estimate 1 SP?24• Ex: 1st sprint estimated at 16 SPs velocity– After execution we deliver 12 SPs– Do reverse calculations from the previous slidesSprint 1 Sprint 2 Sprint 3 1 SP?Before starting 1st Sprint 16 22 28 1.5After 1st Sprint 12 16 21 2After 2nd Sprint 12 16 21 2
  25. 25. Criteria for ordering the backlog25• 1st The risk which the story should diminish• 2nd The uncertainty on client needs which thestory should reduce• 3rd The contribution to the product quality• 4th The dependencies between stories• 5th The utility of a story
  26. 26. Dealing with uncertainty26Demo inspired from
  27. 27. Estimate how long will the walking take?
  28. 28. Walking from Iasi to Bucharest28• Distance Iasi – Bucharest = 417 km• Average walking velocity = 5.0 (km/h)–• We estimate walking 8 hours per day• ~ 10.5 days of walking from Iasi to Bucharest
  29. 29. Walking from Iasi to Bucharest29• Initial uncertainty is probably in hours or days
  30. 30. We walk from Iasi to Roman
  31. 31. Walking from Iasi to Bucharest31• Distance Iasi – Roman = ~86 km• Real walking velocity = 4.0 (km/h)• We’ve walked 6 hours per day• ~ 3.6 days of walking from Iasi to Roman
  32. 32. Estimate from Roman to Bucharest?
  33. 33. Walking from Roman to Bucharest33• Distance Roman – Bucharest = ~331 km• Estimated walking velocity = 4.0 (km/h)• Estimated walking hours per day = 6• ~ 14.8 days of walking from Roman toBucharest• Initial cycle time = 10.5 days of walking• Total cycle time = 18.4 days of walking
  34. 34. Burn-down chart Iasi-Bucharest34
  35. 35. What about agile planning poker?35• The most common estimation method knownin the agile community• The interest is in the discussions
  36. 36. What about agile planning poker?36• The most common estimation method knownin the agile community• The interest is in the discussions
  37. 37. Estimation issues hide higher problems!37-100102030405060D1 D2 D3 D4 D5 D6 D7 D8 D9 D10RAFIdeal RAF
  38. 38. Sprint Backlog381st Story 132nd Story 133rd Story 84th Story 85th Story 13
  39. 39. Observed issues39• Just technical stories/no user stories• Stories didn’t correspond to INVEST criteria• Waterfall approach in iterations• Lack of Definition of Ready• Definition of Done was not respected• …
  40. 40. Start from the need of information40• Clients want to know when it will be ready,the budget…– Ex: Continuous pulling systems like Kanban=>use average Cycle Time instead• TODO in another knowledge sharing session!
  41. 41. Cornel FATULESCUagile coachPlanning is Everything. Plans are Nothing.- Helmuth von Moltke