Techniques for Estimating

Techniques For Estimating-PDF Download

  • Date:09 Jan 2020
  • Views:69
  • Downloads:0
  • Pages:12
  • Size:303.75 KB

Share Pdf : Techniques For Estimating

Download and Preview : Techniques For Estimating


Report CopyRight/DMCA Form For : Techniques For Estimating


Transcription:

50 Chapter 6 Techniques for Estimating,Accuracy 50. Figure 6 1 Additional estimation effort yields very little value beyond a certain point. To understand this relationship better suppose you decide to estimate how. many cookies I ve eaten in the past year You could put no effort into the esti. mate and just take a random guess Mapping this onto Figure 6 1 you d be com. pletely to the left on the effort axis and your estimate would be unlikely to be. accurate You could move to the right on the effort axis by spending a half hour. or so researching national averages for cookie consumption This would improve. your accuracy over the pure guess If you felt the need to be more accurate you. could do some research call my friends and family subpoena my past cookie. orders from the Girl Scouts and so on You could even follow me around for a. day or better yet a month and then extrapolate your observations into how. many cookies you think I eat in a year, Vary the effort you put into estimating according to purpose of the estimate. If you are trying to decide whether or not to send me a box of cookies as a gift. you do not need a very accurate estimate If the estimate will be used to make a. software build versus buy decision it is likely enough to determine that the. project will take six to twelve months It may be unnecessary to refine that to the. point where you can say it will take seven or eight months. Look carefully at Figure 6 1 and notice a couple of things First no matter. how much effort is invested the estimate is never at the top of the accuracy axis. No matter how much effort you put into an estimate an estimate is still an esti. mate No amount of additional effort will make an estimate perfect Next notice. how little effort is required to move the accuracy up dramatically from the base. line As drawn in Figure 6 1 about 10 of the effort gets 50 of the potential ac. curacy Finally notice that eventually the accuracy of the estimate declines It is. From Agile Estimating and Planning by Mike Cohn,Copyright 2005 Addison Wesley. Estimates Are Shared 51, possible to put too much effort into estimating with the result being a less accu. rate estimate, When starting to plan a project it is useful to think about where on the.
curve of Figure 6 1 we wish to be Many projects try to be very high up the accu. racy axis forcing teams far out on the effort axis even though the benefits dimin. ish rapidly Often this is the result of the simplistic view that we can lock down. budgets schedules and scope and that project success equates to on time on. budget delivery of an up front precisely planned set of features This type of. thinking leads to a desire for extensive signed requirements documents lots of. up front analysis work and detailed project plans that show every task a team. can think of Then even after all this additional up front work the estimates still. aren t perfect, Agile teams however choose to be closer to the left in a figure like. Figure 6 1 They acknowledge that we cannot eliminate uncertainty from esti. mates but they embrace the idea that small efforts are rewarded with big gains. Even though they are less far up the accuracy effort scale agile teams can pro. duce more reliable plans because they frequently deliver small increments of. fully working tested integrated code,Estimates Are Shared. Estimates are not created by a single individual on the team Agile teams do not. rely on a single expert to estimate Despite well known evidence that estimates. prepared by those who will do the work are better than estimates prepared by. anyone else Lederer and Prasad 1992 estimates are best derived collaboratively. by the team which includes those who will do the work There are two reasons. First on an agile project we tend not to know specifically who will perform a. given task Yes we may all suspect that the team s database guru will be the one. to do the complex stored procedure task that has been identified However. there s no guarantee that this will be the case She may be busy when the time. comes and someone else will work on it So because anyone may work on any. thing it is important that everyone have input into the estimate. Second even though we may expect the database guru to do the work oth. ers may have something to say about her estimate Suppose that the team s data. base guru Kristy estimates a particular user story as three ideal days Someone. else on the project may not know enough to program the feature himself but he. may know enough to say Kristy you re nuts the last time you worked on a fea. ture like that it took a lot longer I think you re forgetting how hard it was last. From Agile Estimating and Planning by Mike Cohn,Copyright 2005 Addison Wesley. 52 Chapter 6 Techniques for Estimating, time At that point Kristy may offer a good explanation of why it s different this. time However more often than not in my experience she will acknowledge that. she was indeed underestimating the feature,The Estimation Scale.
Studies have shown that we are best at estimating things that fall within one or. der of magnitude Miranda 2001 Saaty 1996 Within your town you should be. able to estimate reasonably well the relative distances to things like the nearest. grocery store the nearest restaurant and the nearest library The library may be. twice as far as the restaurant for example Your estimates will be far less accu. rate if you are asked also to estimate the relative distance to the moon or a. neighboring country s capital Because we are best within a single order of mag. nitude we would like to have most of our estimates in such a range. Two estimation scales I ve had good success with are. 1 2 3 5 and 8,1 2 4 and 8, There s a logic behind each of these sequences The first is the Fibonacci se. quence 1 I ve found this to be a very useful estimation sequence because the gaps. in the sequence become appropriately larger as the numbers increase A one. point gap from 1 to 2 and from 2 to 3 seems appropriate just as the gaps from 3. to 5 and from 5 to 8 do The second sequence is spaced such that each number is. twice the number that precedes it These nonlinear sequences work well because. they reflect the greater uncertainty associated with estimates for larger units of. work Either sequence works well although my slight personal preference is for. Each of these numbers should be thought of as a bucket into which items of. the appropriate size are poured Rather than thinking of work as water being. poured into the buckets think of the work as sand If you are estimating using 1. 2 3 5 and 8 and have a story that you think is just the slightest bit bigger than. the other five point stories you ve estimated it would be OK to put it into the. five point bucket A story you think is a 7 however clearly would not fit in the. five point bucket, 1 A number in the Fibonacci sequence is generated by taking the sum of the previous. two numbers,From Agile Estimating and Planning by Mike Cohn. Copyright 2005 Addison Wesley,User Stories Epics and Themes 53. You may want to consider including 0 as a valid number within your estima. tion range Although it s unlikely that a team will encounter many user stories. or features that truly take no work including 0 is often useful There are two rea. sons for this First if we want to keep all features within a 10x range assigning. nonzero values to tiny features will limit the size of largest features Second if. the work truly is closer to 0 than 1 the team may not want the completion of the. feature to contribute to its velocity calculations If the team earns one point in. this iteration for something truly trivial in the next iteration their velocity will. either drop by one or they ll have to earn that point by doing work that may not. be as trivial, If the team does elect to include 0 in their estimation scale everyone in.
volved in the project especially the product owner needs to understand that. 13 0 0 I ve never had the slightest problem explaining this to product own. ers who realize that a 0 point story is the equivalent of a free lunch However. they also realize there s a limit to the number of free lunches they can get in a. single iteration An alternative to using 0 is to group very small stories and esti. mate them as a single unit, Some teams prefer to work with larger numbers such as 10 20 30 50 and. 100 This is fine because these are also within a single order of magnitude How. ever if you go with larger numbers such as 10 to 100 I still recommend that. you pre identify the numbers you will use within that range Do not for exam. ple allow one story to be estimated at 66 story points or ideal days and another. story to be estimated at 67 That is a false level of precision and we cannot dis. cern a 1 5 difference in size It s acceptable to have one point differences be. tween values such as 1 2 and 3 As percentages those differences are much. larger than between 66 and 67,User Stories Epics and Themes. Although in general we want to estimate user stories whose sizes are within one. order of magnitude this cannot always be the case If we are to estimate every. thing within one order of magnitude it would mean writing all stories at a fairly. fine grained level For features that we re not sure we want a preliminary cost. estimate is desired before too much investment is put into them or for features. that may not happen in the near future it is often desirable to write one much. larger user story A large user story is sometimes called an epic. Additionally a set of related user stories may be combined usually by a pa. per clip if working with note cards and treated as a single entity for either. From Agile Estimating and Planning by Mike Cohn,Copyright 2005 Addison Wesley. 54 Chapter 6 Techniques for Estimating, estimating or release planning Such a set of user stories is referred to as a. theme An epic by its very size alone is often a theme on its own. By aggregating some stories into themes and writing some stories as epics a. team is able to reduce the effort they ll spend on estimating However it s impor. tant that they realize that estimates of themes and epics will be more uncertain. than estimates of the more specific smaller user stories. User stories that will be worked on in the near future the next few itera. tions need to be small enough that they can be completed in a single iteration. These items should be estimated within one order of magnitude I use the se. quence 1 2 3 5 and 8 for this, User stories or other items that are likely to be more distant than a few iter.
ations can be left as epics or themes These items can be estimated in units be. yond the 1 to 8 range I recommend To accommodate estimating these larger. items I add 13 20 40 and 100 to my preferred sequence of 1 2 3 5 and 8. Deriving an Estimate, The three most common techniques for estimating are. Expert opinion,Disaggregation, Each of these techniques may be used on its own but the techniques should. be combined for best results,Expert Opinion, If you want to know how long something is likely to take ask an expert At least. that s one approach In an expert opinion based approach to estimating an ex. pert is asked how long something will take or how big it will be The expert relies. on her intuition or gut feel and provides an estimate. This approach is less useful on agile projects than on traditional projects On. an agile project estimates are assigned to user stories or other user valued func. tionality Developing this functionality is likely to require a variety of skills nor. mally performed by more than one person This makes it difficult to find suitable. experts who can assess the effort across all disciplines On a traditional project. From Agile Estimating and Planning by Mike Cohn,Copyright 2005 Addison Wesley. Disaggregation 55, for which estimates are associated with tasks this is not as significant of a prob.
lem because each task is likely performed by one person. A nice benefit of estimating by expert opinion is that it usually doesn t take. very long Typically a developer reads a user story perhaps asks a clarifying. question or two and then provides an estimate based on her intuition There is. even evidence that says this type of estimating is more accurate than other more. analytical approaches Johnson et al 2000, An alternative to expert opinion comes in the form of estimating by analogy. which is what we re doing when we say This story is a little bigger than that. story When estimating by analogy the estimator compares the story being esti. mated with one or more other stories If the story is twice the size it is given an. estimate twice as large There is evidence that we are better at estimating rela. tive size than we are at estimating absolute size Lederer and Prasad 1998 Vici. nanza et al 1991, When estimating this way you do not compare all stories against a single. baseline or universal reference Instead you want to estimate each new story. against an assortment of those that have already been estimated This is referred. to as triangulation To triangulate compare the story being estimated against a. couple of other stories To decide if a story should be estimated at five story. points see if it seems a little bigger than a story you estimated at three and a lit. Agile teams however choose to be closer to the left in a figure like Figure 6 1 They acknowledge that we cannot eliminate uncertainty from esti mates but they embrace the idea that small efforts are rewarded with big gains Even though they are less far up the accuracy effort scale agile teams can pro

Related Books