Story Points.fm Page 33 Tuesday, May 25, 2004 8:50 PM Chapter 4 Story Points: Estimating Magnitude In a good shoe, I wear a size six, but a seven feels so good, I buy a size eight. Dolly Parton in Steel Magnolias Suppose a new restuarant opens nearby and you decide to try it. For the first course, you can have either a cup or a bowl of soup. You can have the entrée as either a full or half portion. And you can have either a small or a large soda. You ve probably been to many restaurants like this and can quite easily order about the right amount of food without asking how many ounces are in the cups and bowls of soup and exactly how big the entrée portions are. In cases such as these you are ordering by relative rather than measured size. You re saying, give me the large portion or I d like the small serving. You are not ordering by exact size such as, I d like fourteen ounces of soda, 9 ounces of lasagna and 2 ounces of bread. It s possible to estimate an agile project s user stories, features, or tasks in the same way. When I m at an unfamiliar restaurant and order a large soda (instead of a small, medium, or extra-large one) I don t really know how many ounces I ll get. About all I do know is that a large soda is larger than a small or medium soda and that it s smaller than an extra-large one. I also know from past experience that when I m about as thirsty as I am now, a large soda at other restaurants has been the right size. Fortunately, this is all the knowledge I need. And on software projects it s even easier: All I need to know is whether a particular story, feature, or task is larger or smaller than other stories, features, or tasks. Story Points Are Relative Story points are a technique for estimating the magnitude of a user story, feature, task, or other unit of work. When we estimate with story points we assign a point 33
Story Points.fm Page 34 Tuesday, May 25, 2004 8:50 PM 34 Chapter 4 Story Points: Estimating Magnitude value to each task. The raw value we assign is unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as big as a story that is assigned a 1. It should also be half as big as a story assigned a 4. These relationships need to hold whether you re assigning story points in units like 1, 2, and 4 or 100, 200, and 400. The easiest way to get started is find a story that seems somewhat medium-sized and give it a number somewhere in the middle of the range you expect to use. This is often a story that will take two or three days to fully develop. If you start with a story like this and give it a number like 5, 10, or 20 then you ll have plenty of room below it to assign smaller numbers to smaller stories. Alternatively, since there s always room to assign a bigger number, you can find a story that is as small as you re likely to use and call that a 1. Once you ve fairly arbitrarily assigned a story point value to the first story, each additional story is compared to the first story and assigned story points commensurate with the story s relative magnitude. The best way to see how this works is to try it. Instead of story points, assign dog points representing the magnitude of each of these breeds of dog: Labrador Retriever Terrier Great Dane Poodle Dachshund German Shepherd St. Bernard Bulldog Before reading on, really spend a moment thinking about how many dog points you would assign to each of these breeds. The discussion that follows will be much more clear if you do. What did you decide determines the bigness of a dog? Was it weight? Height? My initial thought was height and I assigned dog points as shown in Table 4.1. Table 4.1 One possible assignment of dog points. Breed Dog Points Labrador Retriever 5 Terrier 3 Great Dane 10
Story Points.fm Page 35 Tuesday, May 25, 2004 8:50 PM What s Larger? 35 Table 4.1 One possible assignment of dog points. (Continued) Breed Dog Points Poodle 3 Dachshund 1 German Shepherd 5 Saint Bernard 9 Bulldog 3 I determined the values in Table 4.1 by starting with Labrador Retriever. They seem about like medium-sized dogs to me, so I gave that breed a 5. Great Danes seem about twice as big so I gave them a 10. Saint Bernards seem a little less than twice so I gave them a 9. A dachshund seems about as small as a dog gets and so got a 1. Bulldogs are short so I gave them a 3 although if I was assessing magnitude based on weight, I would have given a higher number. On agile projects, we work with user stories or other loosely-defined requirements. We need to associate an estimate with each story, even those that are looselydefined or incomplete. You ve already seen how to do this if you assigned dog points to poodle and terrier above. Without more detail, it should have been difficult to assign dog points to poodle and terrier. There are toy, miniature, and standard poodles, each of a different height. Similarly, terrier is a group of more than twenty breeds. Some terriers (West Highland, Norwich, Norfolk) are less than a foot tall; others (Airedale) are nearly two feet tall tall. When you re given a loosely-defined user story (or dog), you make some assumptions, take a guess, and move on. In Table 4.1, I took a guess for terrier and poodle and assigned each 3 dog points. I reasoned that even the largest are smaller than labrador retrievers and that the small terriers and poodles would be 1 or 2 point dogs, so on average a 3 seemed reasonable. What s Larger? There is no universal definition of a story point. Better, there doesn t need to be and never will be. Instead, each team defines story points as they see fit. The best I ve found is to define story points to be a measure of the magnitude of a task, where magnitude represents the bigness of a task based on the time it will take to complete and the inherent difficulty of doing it. For example, suppose you are asked to estimate the following tasks: 1. Code 100 screens, each with 2 fields on it
Story Points.fm Page 36 Tuesday, May 25, 2004 8:50 PM 36 Chapter 4 Story Points: Estimating Magnitude 2. Code 1 screen with 200 fields on it 3. Remove the recursion from the ABC class and make it thread-safe 4. Write a Hello, World servlet Tasks 1 and 2 are probably of the same magnitude as each task involves 200 fields and neither is very difficult. The magnitude of task 3 is related to the amount and quality of the source code. Finally, writing a servlet is not a very large task but it may have a high degree of difficulty for someone who doesn t know Java. For the dog example, I chose to assign dog points based on height. I could have just as easily have chosen a different definition. For example, suppose an air freight company might define dog pounds based on the weight of the breed so that they could estimate when a plane is at its cargo capacity. A kennel might define dog points as the amount of exercise a dog needs so as not to over-schedule their dog walkers. Tee Shirt Estimating As a variation on estimating in story points, it is possible to estimate magnitude by assigning each story a size such as small, medium, large, or extra-large. This is what Peter Schuh (2004) calls tee shirt estimating because of the correlation between task sizes and shirt sizes. Estimating in this way may seem easier at first but you will eventually need to convert each shirt size into a number of story points. You may, for example, say that a small is worth 1 story point, a medium is worth 5, and so on. David Anderson (2003) stresses the importance of using a non-linear scale when estimating this way. For a five-point scale he suggests values of 0.5, 1, 2, 4, and 8. If you re going to have to convert tee shirt estimates into specific story point values, you might as well start with story points. Doing so gives you more freedom to assign values in between or outside a predefined range. However, if your team is having trouble getting started directly with story points, you might want to try tee shirt estimating. Advantages of Estimating Magnitude The first advantage to estimating duration is that many developers find it easier to do than estimating in elapsed or even ideal time. Instead of having to think about how long a task will take, it is only necessary to relate the task to one or more other tasks. As we saw with the introduction of archetypal programmer days in the previous chapter, estimating time is difficult because each programmer works at a different speed.
Story Points.fm Page 37 Tuesday, May 25, 2004 8:50 PM Disadvantages to Estimating Magnitude 37 The magnitude of a task, however, is independent of the speed of the developers who are estimating it. You and I can agree that a particular story has a magnitude of 10 story points even though it may take you one day to code while it will take me three days. Second, estimates of magnitude can be generated very quickly. Not a lot of research or heavy thinking is required to say this is like that. This makes this approach very useful on projects with a lot of work to be estimated. It often takes developers a little time to adjust to such an unconventional way of estimating. But, once they become accustomed to it, estimates can be made very quickly. Third, the abstractness of estimating only the magnitude of a task (and not the amount of time it will take to do) frees the estimators from the feelings of coercion that affect many time-based estimates. Often when a developer is asked for an estimate, she knows the answer her boss is looking for. This knowledge will very frequently influence the estimate given by the developer. A developer who thinks the work is much longer than her boss thinks may be inclined to reduce her estimate to please her boss. Similarly, a developer who thinks the work is much shorter may increase her estimate because she knows her boss is expecting to wait that long. In both cases, knowledge of the expectation has influenced the creation of the estimate. When estimating magnitude in story points, the expectations of the estimator s boss do not influence the estimate because each is expressed in a different unit of measure. The expectations are expressed in time or as a date ( My boss wants this in eight weeks, or by May 15 ) while the estimate is given in story points. Another advantage to estimating magnitude is that you will rarely need to re-estimate. If you estimate tasks in elapsed time and then become a faster programmer (perhaps through training or experience), your elapsed-time estimates are now wrong. If you had, instead, estimated magnitude, your estimates would remain accurate. Something big (say a 10 ) is still big, and something twice as big is still twice as big. Estimating magnitude has a final advantage: we can complete the estimating process without associating specific developers with specific tasks. As we saw in Chapter XXX, when we associate a name with a task, we increase the likelihood of the task affecting the delivery date of the overall project. The fewer tasks with designated developers, the better. When estimating magnitude we avoid this potential problem because big is big, regardless of who works on it. Disadvantages to Estimating Magnitude On the opposite side, we must weigh the disadvantages of estimating magnitude. The most significant disadvantage is that magnitude must eventually be converted into an estimate of duration. The CEO doesn t want to hear that a project will be done in 13 larges, 20 mediums, and 11 smalls. Similarly, the CEO doesn t want to hear that
Story Points.fm Page 38 Tuesday, May 25, 2004 8:50 PM 38 Chapter 4 Story Points: Estimating Magnitude you ll be done in 418 story points unless you can accompany that with an estimate of how many story points the team expects to complete per month. We ll look at how to do this in Chapter 10, Simple Release Planning. A second and related disadvantage is that when you estimate in magnitude it makes it difficult to forecast the team s initial velocity. With estimates in ideal time (or archetypal programmer days) it s easy to see how you could guess how many elapsed hours are needed to do one ideal hour of work. With magnitude there is really no way other than guessing to come up with an initial velocity. Of course, this problem only exists at the very start of a project. Once a team has completed a few iterations, they have actual velocity measures that can be used to predict the duration of the project. However, there are still many times when it is critical to have a credible estimate of velocity before the project starts. Like estimating in ideal time, some programmers when estimating magnitude will make implicit conversions from elapsed time to magnitude. For example, a programmer may look at a story and say to herself, Three-point stories take about a day, this seems like about a day of work, I ll say it s a three. Implicit conversions like this are really a hidden form of elapsed time estimating. The programmer in this example is really saying that this story will take one working day to complete. She is not saying that this story is like other three-point stories and about half the size of the six-point stories. A final disadvantage is that estimating magnitude can be very difficult at first for some developers. There are just some of us who are very uncomfortable thinking about how one thing is like another. And, to be fair, there is a very odd feeling when first estimating magnitude and you find yourself arguing about numbers that don t mean anything. I know you think it s a 30 but I say it s a 45, can be an interesting argument when 30 and 45 don t mean anything other than one is 50% larger than the other. Fortunately, most developers quickly become accustomed to estimating magnitude, usually after only a few estimating sessions. Summary SUMMARY POINTS WILL BE ADDED LATER Questions