Agile Estimating and Planning [material inspired by Agile Estimating and Planning by Mike Cohn] Laurie Williams North Carolina State University williams@csc.ncsu.edu This lecture material is copyrighted by Laurie Williams (2007). However, you are encouraged to download, forward, copy, print, or distribute it, provided you do so in its entirety (including this notice) and do not sell or otherwise exploit it for commercial purposes. Estimating and planning Estimating estimating the [resources, time, size] required to develop a [user story, feature, or requirement] Planning putting the estimates together to formulate a project plan and schedule 2
Estimating size: concepts Story point: unit of measure for expressing the overall size of a user story, feature, or other piece of work. The raw value of a story point is unimportant. What matters are the relative values. Related to how hard it is and how much of it there is NOT related to amount of time or # of people Unitless, but numerically-meaningful Ideal time: the amount of time something takes when stripped of all peripheral activities Example: American football game = 60 minutes Elapsed time: the amount of time that passes on the clock to do something Example: American football game = 3 hours Velocity: measure of a team s rate of progress 3 Coming up with the plan 5 story points/twoweek 30 October 30 story points 6 s 4
Estimating dog points Estimate each of the dogs below in dog points, assigning each dog a minimum of 1 dog point and a maximum of 10 dog points A dog point represents the height of a dog at the shoulder Labrador retriever Terrier Great Dane Poodle Dachshund German shepherd St. Bernard Bulldog 5 What if? Estimate each of the dogs below in dog points, assigning each dog a minimum of 1 dog point and a maximum of 100 dog points A dog point represents the height of a dog at the shoulder Labrador retriever Terrier Harder or easier? Great Dane Poodle More or less accurate? Dachshund German shepherd More or less time consuming? St. Bernard Bulldog 6
Estimating story points Choose a medium-size story and assign it a 5 Estimate other stories relative to that Twice as big Half as big Almost but not quite as big A little bit bigger Only values: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 Near term stories A few s away epic 7 Estimating ideal days Ideal days vs. elapsed time in software development Supporting current release Sick time Meetings Demonstrations Personal issues Phone calls.... When estimating ideal days, assume: The story being estimated is the only thing you ll work on Everything you need will be on hand when you start There will be no interruptions 8
Deriving an estimate for a user story Expert opinion Rely on gut feel based on (extensive) experience Disadvantage for agile: need to consider all aspects of developing the user story, so one expert will likely not be enough Analogy Relative to (several) other user stories Triangulation: little bigger than that 3 and a little smaller than that 8 Disaggregation Break up into smaller, easier-to-estimate estimate pieces/tasks. Need to make sure you don t miss any tasks. Sanity check: does the sum of all the parts make sense? Planning poker Combines expert opinion, analogy, disaggregation 9 Playing Planning Poker Include all players on the development team (but less than 10 people overall): Programmers Testers Wideband Delphi Database engineers Requirements analysts User interaction designers... Moderator (usually the product owner or analyst) reads the description and answers any questions Each estimator privately selects a card with their estimate All cards simultaneously turned over Discussion ensures Re-estimate Repeat until converge 10
Coming up with the plan 11 Velocity Velocity is a measure of a team s rate of progress. Velocity is calculated by summing the number of story points assigned to each user story that the team completed during the operation. We assume that the team will produce in future s at the rate of their past average velocity. Yesterday s weather 12
Coming up with the plan 5 story points/twoweek October 30 30 story points 6 s 13 Not working as fast as planned? 3 story ypoints/two- 5 story week points/twoweek 25 December October 30 30 story points 6 s 10 s 14
Not working as fast as planned? 3 story ypoints/two- 5 story week points/twoweek October 30 30 story points 6 s 18 story points 15 Velocity corrects estimation errors Since all user stories are estimated relative to each other... It s the velocity that should change, not each story point estimate for future releases 16
Coming up with the plan 17 Prioritization Driven by customer, in conjunction with developer Choose features to fill up velocity of, based on: Desirability of the feature to a broad base of customers or users Desirability of a feature to a small number of important customers or users The cohesiveness of the story in relation to other stories. Example:» Zoom in a high priority feature» Zoom out not a high priority feature But it becomes one relative to Zoom in High Priority Give us these stories to provide a minimal working system. Medium Priority We need these stories to complete this system. Low Priority Bells and whistles? Which stories can come later? 18
Coming up with the plan 19 Burn down charts Vertical axis shows number of story points or hours remaining in the 400 project 350 300 Iterations [or days] are 250 shown across the 200 horizontal line 150 100 Shows the amount of 50 work remaining at the 0 start of each Visual indicator of how quickly a team is moving toward its goal Work Remaining (hours) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Scrum Day 20