Part III: Estimating Size

Transcription

1 Part III: Estimating Size Separate estimates of size from estimates of duration Example: Moving a pile of dirt example Size: 300 cubic feet of dirt Convert size to an estimate of duration Wheelbarrow holds 6 cubic feet 300 divided by 6 = 50 trips Each trip takes 6 minutes (load, walk, dump, return) Estimated time: 6 * 50 = 300 minutes or 5 hours

2 Begin with estimating size Desired Features Estimate Size

3 Begin with estimating size Desired Features Estimate Size Derive Duration Schedule

4 Ch. 4 Estimating Size with Story Points Compare stories (or features) Estimate relative sizes For each story (or feature), is it larger or smaller that the others? Story points Unit of measure representing the size of a story Relative values A 2-point Story is twice as big as a 1-point story Each estimate represent the effort, complexity and risk associated with developing that story

5 Example: Dog points Points represents relative height of dog at the shoulder Breeds: Labrador Terrier Great Dane Poodle Dachshund German shepherd Saint Bernard Bulldog Start with estimating the medium size BREED DOG POINTS Labrador 5 Terrier 3 Great Dane 10 Poodle 3 Dachshund 1 German shepherd 5 Saint Bernard 9 Bulldog 3

6 Velocity Velocity is a measure of rate of progress Sum of the story points completed in each iteration Complete 3 stories (estimated size of each is 5) Velocity is 15 Desired Features Estimate Size Derive Duration Schedule The sum of the story point estimates for all the features is the total size of the project

7 Example: Deriving Duration from Size estimates Sum of user stories is 100 story points Team s experience has been 10 points per 2-week iteration Assume team will continue at the same velocity Team estimated duration, 20 weeks If you have no team experience to use in deriving your duration estimate, velocity may need to be estimated (guessed)

8 Example: Velocity corrects Estimation Errors Team estimates project at 200 points of work, and Iteration can complete 25 points per iteration Estimated completion in 8 iterations Project begins team finishes only 20 points in the iteration Reset the velocity to 20 per iteration, and re-estimated completion is reset to 10 iterations Planning errors are self-correcting

9 Example: Ch. 5 Estimating in Ideal Days Soccer game: two 45 minute halves Ideal Time Elapsed Time The referee may make an allowance for time lost through substitutions, injured players requiring attention, or other stoppages. If the game is tied at the end of regulation time it may go into extra time, which consists of two further 15 minute periods. If the score is still tied after extra time, penalty shootouts determine which team will progress to the next stage of the tournament. Actual Elapsed Time Ideal Time

10 Ideal Time and Software Development Actual Elapsed Time Ideal Time Due to overhead costs that occur during the day: Supporting the current release Sick time Meetings Demonstrations Personnel issues Phone calls Special projects Training Reviews and walk-throughs Interviewing candidates Task switching Bug fixing in current releases Management review

11 Research findings: Managers work an average of only five minutes between interruptions, (Hobbs 1987) Typical developer is interrupted only one-third as often, every 15 minutes. Multitasking: time is required in switching between two (or more) tasks. Ideal time assumes: The story being estimated is the only thing being worked on! Everything you need will be on hand when you start There will be no interruptions

12 Using Ideal Days as a measure of Size Represents the measure of the actual expected work on the project When organizational overhead is ignored, ideal days can be used as another estimate of size like story points With additional (non-project related) demands, the time needed to complete and ideal day, obviously, will increase.

13 One estimate, not many! Assign one estimate to each story Agile advice: do not distribute the work (time) to individual roles (programmer, database engineer, user interaction designer, tester) Shifts thinking (collaboration) away from we re all in this together. Note: assigning work increases the work needed you would need to track velocity of each individual roleplayer

14 Summary Estimates of user story duration is easier if ideal days are used Estimations using elapsed time would need to include estimates of time for the many possible interruptions Ideal time estimates only include the time the story will take a true estimate of size