Idea Transcript
Pearls of Wisdom For Agile Software Methodology
TA G A RCHI V E S : DI S A G G RE G A TI O N
PEARL V: A Purview on Techniques for Estimation in Agile s/w Methodology Posted on May 19, 2014 PEARL V: A Purview on Techniques for Estimation in Agile s/w Methodology Estimation is one of the most misused elements in all of software development. Estimates should reflect the relative difficulty and length of work to guide planning and prioritization — not commit the team to mandatory Saturdays. With estimates in hand, stakeholders can make smart tradeoffs and reasonable forecasts. Plans are only as good as the estimates, that the plans are based on, and estimates always come second to actual. The real world has this horrible habit of destroying plans.The customer has the right to an overall plan, to see progress and to be informed of schedule changes, Whereas the developer has the right to make and update his own estimates and to accept responsibility instead of having responsibility assigned to him. You can’t put 10 pounds of groceries into a 5 pound bag. Forecasting tomorrow’s weather is much more difficult than telling what the weather was like yesterday. Don’t try to be too sophisticated; estimates will never be anything other than approximate, however hard you try. Most software is not a predictable or mass manufacturing problem. Software development is new product development. It is rarely possible to create upfront unchanging and detailed specs.Near the beginning, it is not possible to estimate. As empirical data emerge, it becomes increasingly possible to plan and estimate.Adaptive steps driven by build-feedback cycles are required. Creative adaptation to unpredictable change is the norm. Change rates are high. We can often spend a little time thinking about an estimate and come up with a number that is nearly as good as if we had spent a lot of time thinking about it. we often need to expend just a fraction of that effort to get adequate results.
As effort on estimation increases, the accuracy may decrease after a certain amount of effort on estimation. Vary the effort you put into estimating according to purpose of the 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. First, no matter how much effort is invested, the estimate is never at the top of the accuracy that is 90 % to 100 % accurate.No matter how much effort you put into an estimate, an estimate is still an estimate. No amount of additional effort will make an estimate perfect. It is possible to put too much effort into estimating, with the result being a less accurate estimate. Agile teams, acknowledge that we cannot eliminate uncertainty from estimates, 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 produce more reliable plans because they frequently deliver small increments of fully working, tested, integrated code. Contrasting Traditional and Agile Estimation Techniques An average software project begins when a team or person outlines a project and receives approval to go forward. The project may be started by a product manager with an idea for an existing product, or by a customer request, or by the signing of a contract. In the early stages of a project, someone guesses how long it will take to deliver. This person may be a salesperson, project manager, or development manager. They may make a guess based on their experience, or they may have some quick chats with seasoned employees and solicit their opinions. When the timeline guess is in place, the project begins. If the project is related to a product, there may be marketing requirements to reference. If the project is for a customer, there may be a statement of work to reference. In either case, it’s common for an analyst team to convert the information into functional specifications. After the functional specifications are completed, a conversation begins with the development team, designs begin to evolve, and some teams may document a technical design and architectural plan. When this work is complete, the development team provides estimates based on the anticipated approach. The team also estimates their capacity by resource type. Then the estimates, capacity, and known dependencies are entered into a project plan. At this point, the team has a schedule that they feel confident in, and they share it with the stakeholders. This exercise may take several weeks or months to complete. If a project is timeboxed, the team may find that there isn’t enough time to deliver all the features for which they created functional specifications, designs, and estimates. The team then has to scope back the features for the project to meet the timeline, realizing they’ve wasted valuable time in estimating features that won’t be pursued. Agile estimation techniques address the shortcomings of this method. You don’t design and estimate all your features until there has been a level of prioritization and you’re sure the features are needed. You used a phased approach to estimation, recognizing that you can be more certain as the project progresses and you learn more about the features. At a high level, the phased process looks like this: 1. Estimate the features in a short, time-boxed exercise during which you estimate feature size, not duration. 2. Use feature size to assign features to iterations and create a release plan. 3. Break down the features you assigned to the first iteration. Breaking down means identifying the specific tasks needed to build the features and estimating the hours required. 4. Re-estimate on a daily basis during an iteration, estimating the time remaining on open tasks. Agile estimating is also different in that you involve the entire team in the estimation process. Whole Team Estimation Every year, Best Buy Corporation tries to predict how many gift cards will be sold at Christmas. The typical process is to solicit the opinion of upper management and internal estimation experts to forecast a number. In 2005, the CEO of Best Buy decided to try an experiment. The CEO followed the normal process for obtaining the estimates but also sent an email to approximately 100 random employees throughout the company, asking them how many gift cards they believed would be sold. The only information provided to both groups was the sales number for the previous year. After the Christmas season was completed, the predictions of both groups were reviewed. The expert panel was accurate within 95 percent of the actual number of cards sold. The random group of employees was accurate within 99.9 percent of the number of cards sold . How did a random group beat the internal estimation experts? In his book The Wisdom of Crowds, author James Surowiecki makes a case that a diverse set of independently thinking individuals can provide better predictions than a group of experts. Surowiecki qualifies this assertion by stating that the diversity needs to be in the way a group views problems and the heuristics each individual uses to analyze a problem or question. For example, a person’s age can greatly influence their perspective on an issue. Best Buy Corporation realized improved estimation accuracy by querying a large, diverse group of employees. The diverse set of employees consistently delivered better estimates than the inhouse estimation experts.
Surowiecki’s work draws many parallels to the issues with estimating software development. We often get together a group of specialists or experts to estimate the work that needs to be completed. These experts may be managers or leads who facilitate the work of their various teams. The fact that all the experts may be a part of management limits their diversity in opinion. And the fact that these experts may work together frequently may lead to standardized thinking, also known as groupthink. In an Agile environment, you increase the accuracy of your feature estimates by estimating the features together as a team. Estimates aren’t limited to managers or leads but also include developers, testers, analysts, DBAs, and architects. The features are viewed from various perspectives, and you merge these perspectives to create a common, agreed-on estimate. Entire-team estimation has additional benefits beyond diverse opinion. First, you get estimates from people who are closer to the work. Team members’ opinions may be diverse, but they provide better estimates because they know your existing code, architecture, and domains and what it takes to deliver in your environment. A second benefit is team ownership of the estimate. If a manager provides the estimate, they hope the team supports the estimate and buys into it. If the team provides the estimate, they’re immediately closer to owning the estimate, and they feel more responsible for making the dates they provided. Moving to team-based estimation isn’t easy. Managers may not welcome additional input, and team members may be reluctant to challenge the experts and instead echo whatever the experts say. It will take time to overcome these hurdles, but you can do one thing to expedite the change: when you perform team-based estimation, have the meeting facilitated by an indirect manager such as a project manager or ScrumMaster. This person can treat all people as equals regardless of title and proactively query team members who are reluctant to contribute. You can also use the planning poker process discussed in the next section to prevent one person’s estimate from influencing another’s. 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 for this. Size of story is given in “story points” (an abstract unit). The team defines how a story point translates to effort (typically: 1 story point = 1 ideal day of work). The number of story points that a team can deliver in an iteration is called “team velocity”. Agile Estimation There are three main concepts team need to understand to do agile estimation, Estimation of Size gives a high-level estimate for the work item, typically measured using a neutral unit such as story points Velocity tells us how many points this project team can deliver within an iteration; Estimation of Effort translates the size (measured in points) to a detailed estimate of effort typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how long it will take the team member(s) to complete the assigned work item(s). Estimation of Size Story Points is a relative measure that can be used for agile estimation of size. The team decides how big a story point is, and based on that size, determines how many story points each work item is. To make estimation go fast, use only full story points, 1, 2, 3, 5, 8, and so on, rather than fractions of a point, such 0.25, or 1.65 story points. To get started, look at 10 or so representative work items, give the smallest the size of one story point, and then go through all other work items and give them a relative story point estimate based on that story point. Note that story points are used for high-level estimates, so do not spend too much time on any one item. This is especially true for work items of lower priority, to avoid wasting effort on things that are unlikely to be addressed within the current iteration. A key benefit of story points is that they are neutral and relative. Let’s say that Ann is 3 times more productive than Jack. If Ann and Jack agree that work item A is worth 1 story point, and they both think work item B is roughly 5 times as big, they can rapidly agree that work item B is worth 5 points. Ann may however think work item B can be done in 12 hours, while Jack thinks it can be done in 36 hours. That is fine, they may disagree about the actual effort required to do it, but we do not care at this point in time, we only want the team to agree on the relative size. We will later use Velocity to determine how much ‘size’, or how many points, the team can take on within an iteration. One project team may say that a work item of a certain size is worth 1 point. Another project team would estimate the same sized work item to be worth 5 points. That is fine, as long as you are consistent within the same project. Make sure that the entire team is involved in assessing size, or at least that the same people are involved in all your size estimates, to ensure consistency within your project. We will see how the concept of velocity will fix also this discrepancy in a point meaning different things to different project teams. You can also use other measures of size, where the most common alternative is Ideal Days. Velocity Velocity is a key metric used for iteration planning. It indicates how many points are delivered upon within an iteration for a certain team and project. As an example, a team planned to accomplish 20 points in the first iteration. At the end of the iteration, they noticed that they only delivered upon 14 points, their velocity was hence 14. For the next iteration, they may plan for fewer points, let’s say 18 points, since they think they can do a little better than in previous iteration. In this iteration, they delivered 17 points, giving them a velocity of 17. Expect the velocity to change from iteration to iteration. Some iterations go smoother than others, and points are not always identical in terms of effort. Some team members are more effective than others, and some problems end up being harder than others. Also, changes to the team structure, learning new skills, changes to the tool environment, better teaming, or more overhead with meetings or tasks external to the project will all impact velocity. In general, velocity typically increases during the project as the team builds skills and becomes more cohesive. Velocity compensates for differences between teams in terms of how big a point is. Let’s assume that project team Alpha and project team Beta are equally efficient in developing software, and they run the same project in parallel. Team Alpha, however, assesses all work items as being worth 3 times as many points as team Beta’s estimates. Team Alpha assesses work item A, B, C, and D to correspond to 30 points, and team Beta estimates the same work items to correspond to 10 points. Both teams deliver upon those 4 work items in the next iteration, giving team Alpha a velocity of 30, and team Beta a velocity of 10. It may sound as if team Alpha is more effective, but let’s look at what happens when they plan the next iteration. They both want to take on work item E-H, which team Alpha has estimated to be 30 points, and team Beta as normal has estimated to be 1/3 as many points, or 10 points. Since a team can typically take on as many points as indicated by their velocity, they can both take on all of E-H. The end result is that it does not matter how big a point is, as long as you are consistent within your team. Velocity also averages out the efficiency of different team members. Let’s look at an example; Let’s assume that Ann always works 3 times as fast as Jack and Jane. Ann will perhaps deliver 9 points per iteration, and Jack and Jane 3 points each per iteration. The velocity of that 3-person team will be 15 points. As mentioned above, Ann and Jack may not agree on how much effort is associated with a work item, but they can agree on how many points it is worth. Since the team velocity is 15, the velocity will automatically translate the point estimate to how much work can be taken on. As you switch team members, or as team members become more or less efficient, your velocity will change, and you can hence take on more or less points. This does however not require you to change the estimate of the size. The size is still the same, and the velocity will help you to calculate how much size you can deliver upon with the team at hand for that iteration. Estimation of Effort Estimation of Effort translates the size (measured in points) to a detailed estimate of effort typically using the units of Actual Days or Actual Hours. As you plan an iteration, you will take on a work item, such as detail, design, implement and test a scenario, which may be sized to 5 points. Since this is still a reasonably big work item, break it down into a number of smaller work items, such as 4 separate work items for Detailing, Designing, Implementing and Testing Server portion, and Implementing and Testing Client portion of the scenario. Team members are asked to sign up for the tasks, and then detail the estimate of the actual effort, measured in hours or days, for their tasks. In this case, the following actual estimates were done (with person responsible within parenthesis): Detailing scenario (Ann): 4 hours Designing scenario (Ann and Jack): 6 hours Implementing and Testing Server portion of scenario (Jack): 22 hours Implementing and Testing Client portion of scenario (Ann): 12 hours Total Effort Estimate for Scenario: 44 hours If other people would be assigned to the tasks, the estimated actual hours could be quite different. There is hence no point doing detailed estimates until you know who will do the work, and what actual problems you will run into. Often, some level of analysis and design of the work item needs to take place before a reasonable estimate can be done. Remember that estimates are still estimates, and a person assigned to a task should feel free (and be encouraged) to re-estimate the effort required to complete the task, so we have a realistic view of progress within an iteration. 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. S/he may be busy when the time comes, and someone else will work on it. So because anyone may work on anything, it is important that everyone have input into the estimate. Second, even though we may expect the database guru to do the work, others may have something to say about her estimate. Suppose that the team’s database 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 feature like that, it took a lot longer. I think you’re forgetting how hard it was last time.” At that point Kristy may offer a good explanation of why it’s different this time. However, more often than not 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 order 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. Because we are best within a single order of magnitude, we would like to have most of our estimates in such a range. Two estimation scales are of good success which are u 1, 2, 3, 5, and 8 u 1, 2, 4, and 8 There’s a logic behind each of these sequences. The first is the Fibonacci sequence. Agilists 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 preference is for the first. 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.You may want to consider including 0 as a valid number within your estimation 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 reasons 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 involved in the project (especially the product owner) needs to understand that 13 × 0 ≠ 0 . Agilists never had the slightest problem explaining this to product owners, 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 estimate 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. However, if you go with larger numbers, such as 10 to 100, Agilists still recommend that you pre-identify the numbers you will use within that range. Do not, for example, 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 discern 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 3-tier story sizing estimation is a great approach when managing work from the Portfolio to Program to Project level. Corporate initiatives (investment themes) are implemented by Features. These are coarse grain, high level items used for Product Road Mapping and the Story Point sizing is a very rough estimate of the total effort. As Features get broken down into Epics and then stories, each progressive refinement results in more granular Story Points estimates that can be used for Release and Sprint Planning. 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 paper clip if working with note cards) and treated as a single entity for either 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 important 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 iterations) need to be small enough that they can be completed in a single iteration. These items should be estimated within one order of magnitude. Agilists use the sequence 1, 2, 3, 5, and 8 for this. User stories or other items that are likely to be more distant than a few iterations can be left as epics or themes. These items can be estimated in units beyond the 1 to 8 range. To accommodate estimating these larger items Agilists add 13, 20, 40, and 100 to preferred sequence of 1, 2, 3, 5, and 8. Deriving an Estimate The three most common techniques for estimating are u Expert opinion u Analogy u 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 expert 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 functionality. Developing this functionality is likely to require a variety of skills normally 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 for which estimates are associated with tasks, this is not as significant of a problem, 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). Analogy 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 estimated 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 relative size than we are at estimating absolute size (Lederer and Prasad 1998; Vicinanza 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- tle smaller than a story you estimated at eight. Disaggregation Disaggregation refers to splitting a story or feature into smaller, easier-to-estimate pieces. If most of the user stories to be included in a project are in the range of two to five days to develop, it will be very difficult to estimate a single story that may be 100 days. Not only are large things notoriously more difficult to estimate, but also in this case there will be very few similar stories to compare. Asking “Is this story fifty times as hard as that story” is a very different question from “Is this story about one-and-a-half times that one?” The solution to this, of course, is to break the large story or feature into multiple smaller items and estimate those. However, you need to be careful not to go too far with this approach. Not only does the likelihood of forgetting a task increase if we disaggregate too far, but summing estimates of lots of small tasks also leads to problems. Planning Poker The best way Agilists have found for agile teams to estimate is by playing planning poker (Grenning 2002). Planning poker combines expert opinion, analogy, and disaggregation into an enjoyable approach to estimating that results in quick but reliable estimates. Participants in planning poker include all of the developers on the team. Remember that developers refers to all programmers, testers, database engineers, analysts, user interaction designers, and so on. On an agile project, this will typically not exceed ten people. If it does, it is usually best to split into two teams. Each team can then estimate independently, which will keep the size down. The product owner participates in planning poker but does not estimate. At the start of planning poker, each estimator is given a deck of cards. Each card has written on it one of the valid estimates.
Each estimator may, for example, be given a deck of cards that reads 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. The cards should be prepared prior to the planning poker meeting, and the numbers should be large enough to see across a table. Cards can be saved and used for the next planning poker session. For each user story or theme to be estimated, a moderator reads the description. The moderator is usually the product owner or an analyst. However, the moderator can be anyone, as there is no special privilege associated with the role. The product owner answers any questions that the estimators have. The goal in planning poker is not to derive an estimate that will withstand all future scrutiny. Rather, the goal is to be somewhere well on the left of the effort line, where a valuable estimate can be arrived at cheaply. After all questions are answered, each estimator privately selects a card representing his or her estimate. Cards are not shown until each estimator has made a selection. At that time, all cards are simultaneously turned over and shown so that all participants can see each estimate. It is very likely at this point that the estimates will differ significantly. This is actually good news. If estimates differ, the high and low estimators explain their estimates. It’s important that this does not come across as attacking those estimators. Instead, you want to learn what they were thinking about. As an example, the high estimator may say, “Well, to test this story, we need to create a mock database object. That might take us a day. Also, I’m not sure if our standard compression algorithm will work, and we may need to write one that is more memory efficient.” The low estimator may respond, “I was thinking we’d store that information in an XML file—that would be easier than a database for us. Also, I didn’t think about having more data—maybe that will be a problem.” The group can discuss the story and their estimates for a few more minutes. The moderator can take any notes she thinks will be helpful when this story is being programmed and tested. After the discussion, each estimator re-estimates by selecting a card. Cards are once again kept private until everyone has estimated, at which point they are turned over at the same time. In many cases, the estimates will already converge by the second round. But if they have not, continue to repeat the process. The goal is for the estimators to converge on a single estimate that can be used for the story. It rarely takes more than three rounds, but continue the process as long as estimates are moving closer together. It isn’t necessary that everyone in the room turns over a card with exactly the same estimate written down. Again, the point is not absolute precision but reasonableness. Smaller Sessions It is possible to play planning poker with a subset of the team, rather than involving everyone. This isn’t ideal but may be a reasonable option, especially if there are many, many items to be estimated, as can happen at the start of a new project. The best way to do this is to split the larger team into two or three smaller teams, each of which must have at least three estimators. It is important that each of the teams estimates consistently. What your team calls three story points or ideal days had better be consistent with what other team calls the same. To achieve this, start all teams together in a joint planning poker session for an hour or so. Have them estimate ten to twenty stories. Then make sure each team has a copy of these stories and their estimates and that they use them as base-lines for estimating the stories they are given to estimate. When to Play Planning Poker Teams will need to play planning poker at two different times. First, there will usually be an effort to estimate a large number of items before the project officially begins or during its first iterations. Estimating an initial set of user stories may take a team two or three meetings of from one to three hours each. Naturally, this will depend on how many items there are to estimate, the size of the team, and the product owner’s ability to clarify the requirements succinctly. Second, teams will need to put forth some ongoing effort to estimate any new stories that are identified during an iteration. One way to do this is to plan to hold a very short estimation meeting near the end of each iteration. Normally, this is quite sufficient for estimating any work that came in during the iteration, and it allows new work to be considered in the prioritization of the coming iteration. Alternatively, Kent Beck suggests hanging an envelope on the wall with all new stories placed in the envelope. As individuals have a few spare minutes, they will grab a story or two from the envelope and estimate them. Teams will establish a rule for themselves, typically that all stories must be estimated by the end of the day or by the end of the iteration. Agilists like the idea of hanging an envelope on the wall to contain unestimated stories. However, they prefer that when someone has a few spare minutes to devote to estimating, he find at least one other person and that they estimate jointly. Why Planning Poker Works it’s worth spending a moment on some of the reasons why it works so well. First, planning poker brings together multiple expert opinions to do the estimating. Because these experts form a crossfunctional team from all disciplines on a software project, they are better suited to the estimation task than anyone else. After completing a thorough review of the literature on software estimation, Jørgensen (2004) concluded that “the people most competent in solving the task should estimate it.” Second, a lively dialogue ensues during planning poker, and estimators are called upon by their peers to justify their estimates. This has been found to improve the accuracy of the estimate, especially on items with large amounts of un-certainty (Hagafors and Brehmer 1983). Being asked to justify estimates has also been shown to result in estimates that better compensate for missing information (Brenner et al. 1996). This is important on an agile project because the user stories being estimated are often intentionally vague. Third, studies have shown that averaging individual estimates leads to better results (Hoest and Wohlin 1998) as do group discussions of estimates (Jørgensen and Moløkken 2002). Group discussion is the basis of planning poker, and those discussions lead to an averaging of sorts of the individual estimates. Finally, planning poker works because it’s fun.Expending more time and effort to arrive at an estimate does not necessarily increase the accuracy of the estimate. The amount of effort put into an estimate should be determined by the purpose of that estimate. Although it is well known that the best estimates are given by those who will do the work, on an agile team we do not know in advance who will do the work. Therefore, estimating should be a collaborative activity for the team. Estimates should be on a predefined scale. Features that will be worked on in the near future and that need fairly reliable estimates should be made small enough that they can be estimated on a nonlinear scale from 1 to 10 such as 1, 2, 3, 5, and 8 or 1, 2, 4, and 8. Larger features that will most likely not be implemented in the next few iterations can be left larger and estimated in units such as 13, 20, 40, and 100. Some teams choose to include 0 in their estimation scale. To arrive at an estimate, we rely on expert opinion, analogy, and disaggregation. A fun and effective way of combining these is planning poker. In planning poker, each estimator is given a deck of cards with a valid estimate shown on each card. A feature is discussed, and each estimator selects the card that represents his or her estimate. All cards are shown at the same time. The estimates are discussed and the process repeated until agreement on the estimate is reached. Planning for Iterations During project planning, iterations are identified, but the estimates have an acceptable uncertainty due to the lack of detail at the project inception. This task is repeated for each iteration within a release. It allows the team to increase the accuracy of the estimates for one iteration, as more detail is known along the project. Ensure that the team commits to a reasonable amount of work for the iteration, based on team performance from previous iterations. Prioritize the work items list before you plan the next iteration. Consider what has changed since the last iteration plan (such as new change requests, shifting priorities of your stakeholders, or new risks that have been encountered). When the team has decided to take on a work item, it will assign the work to one or several team members. Ideally, this is done by team members signing up to do the work, since this makes people motivated and committed to doing the job. However, based on your culture, you may instead assign the work to team members. Wall Estimation Planning poker is a fantastic tool for estimating user stories, but it would take an inordinate amount of time to estimate hundreds of stories, one at a time, using planning poker. If you have a raw backlog filled with hundreds of stories that have not been estimated or prioritized, you’re going to need a faster way to estimate. Wall Estimation is designed to allow teams to eliminate discussions of 2 versus 3 and 5 versus 8 and instead group things in a purely relative manner along a continuum, at least initially. It also allows stakeholders to give a general prioritization to a large group of stories without getting hung up on whether one story is slightly more important than another.
To do Wall Estimation, you must first print your user stories on cards. Then gather your team and stakeholders in a room with a big empty wall (about 14 feet long by 8-10 feet high); Understand two things about the wall: Height determines priority. Stories at the top are higher; stories at the bottom are lower. A story’s priority can be based on ROI, business value, or something as simple as “it’s just important, and I don’t know why.” Width is reserved for size. Stories on the left are smaller; stories on the right are bigger. (You can reverse this and move from right to left if you’re in, say, Japan and it’s more logical.) The important thing is to envision a line going horizontally and one going vertically. Team members and stakeholders should ask themselves, where, relative to the other stories, does this one fit? The team will use the wall to size all of the stories. The stakeholders will use the wall to prioritize stories. As with planning poker, we’re using relative sizing, but instead of using two reference stories for comparison, the wall becomes the constant. Small story? Move to the left. Big story? Move to the right. Important story? Place it high. A story that we can live without for now? Place it low. Although the stakeholders do not have to be there while the stories are being estimated, the team does need to be in the room while the stories are being prioritized. The ScrumMaster and product owner must attend both the estimation and prioritization activities. Prioritization Although customers and stakeholders will want to know how big a story is to help them determine its priority, they’ll be much more focused on finding the stories that relate to them and making sure those stories get done. Expect your stakeholders to disagree about priority—your product owner will use this information to help decide the ultimate priority. Ask the stakeholders to help determine the relative priority of all of these stories by moving these stories up or down inside the taped columns. Remind them that the higher up a story is on the wall, the higher its priority to the business. Set the following rules: If you place a story at the top, be prepared to justify the placement. You may ask each other why one story is more important than another. Feel free to ask each other, “Who moved this one down (or up)?” or to say aloud, “I think this one needs to move. Who wants to disagree?” This enables conversation between the interested parties, without facilitation. If you move a story lower on the wall than someone else did, mark it with a colored dot to alert us. The biggest benefit to prioritizing as a group is that all the stakeholders can better understand the priorities of various stories. If a discussion goes on too long without resolution, the product owner should collect the card, identify the two stakeholders who cannot agree, and make a note to meet with them privately later. The exercise could take 2-6 hours, depending on the number of stories and the number of stakeholders. When you are finished, the wall will look something like the picture shown below.
Your wall will break down roughly into four quadrants. The stories in the top left are high priority and small so they’ll end up in the top of the product backlog. The stories in the top right are high priority but are also large. These stories should be broken down soon so they can be brought into upcoming sprints.
The lower left quadrant is made up of small stories that are lower in priority. They will likely fall to the bottom of the backlog. The lower right quadrant is filled with large stories that are also lower in priority. These stories are your epics or themes. They’ll eventually need to be broken down into smaller, more manageable stories but not until they rise in priority. Spend some time looking at the wall as a whole with the group. If a story is in the wrong quadrant, move it. If a high-priority story must be broken down and time allows, do it while everyone is in the room. At the end of wall estimation, you’ll have the start of a release plan. If you know the team’s historical velocity, you can even supply a rough range of which stories in the upper-left quadrant will be finished. Estimation is hard because there is so much uncertainty at the beginning of a project. Product Owners and agile project managers try to maximize value early learning by having conversations with their product owners and stakeholders, producing working software, and integrating feedback about that software to get to a releasable state. But even agile projects must provide some estimate of when a set of features will be ready for release. Quadrus Estimation Methodology Quadrus is a recognized leader in IT professional services and solutions. Headquartered in Calgary, Alberta, Quadrus has delivered hundreds of successful projects across Western Canada since 1993. They are committed to providing the highest quality service to valued clients. Quadrus has developed the Quadrus Estimation Methodology which is different for a few key reasons: QEM recognizes that way in which people estimate – and when forming overall project estimates, QEM employs Monte-Carlo simulation to aggregate individual estimates in a statistically correct way. QEM takes into account those project tasks that are often left out of project estimates. Activities such as requirements clarification, task management and coordination, meetings, demos, testing and deployment are all included in the project estimate. QEM recognizes that often not all project requirements are known up front. QEM provides a mechanism for estimating the percentage of known requirements (versus the percentage of unknown requirements), and the overall project estimate is appropriate scaled to reflect the reality of unknown requirements. QEM recognizes that most people naturally create single-point estimates for tasks or stories – and QEM is able to work with these (less-than-perfect) estimates. The input to QEM consists, quite simply, of the single-point estimate that the developer feels is the most intuitive estimate (the median) together with an uncertainty factor (Low, Medium or High) to indicate the range of the distribution curve to use. If a task seems to have many unknowns or perhaps uses new technologies – or if it may have an element of research or invention – then the uncertainty will be higher than a task that is known and recognized (lower uncertainty). This uncertainty is very important; recognizing it exists can drastically change how much time we should assume a task can take. One story may have a lower numeric estimate than another but with a greater level of uncertainty could actually end up taking more time. These inputs are not onerous to produce compared to the inputs demanded by other estimation methodologies that have been tried in the past (e.g., feature points, estimated lines of code, etc.). Together the single-point estimate/uncertainty pair provides enough information to calculate an expected average estimate for the individual story together with a range. Quadrus has codified the Quadrus Estimation Methodology as a modern AJAX-powered, intuitive and easy to use web application named the Quadrus Estimator. The Quadrus Estimator has many features, such as support for the user-story importance to be ranked using a star-rating and enabling stories to be labeled. The star-rating and labels can be used to manage and filter the list of tasks and also to include or exclude stories from an estimate for “what-if” scenarios based on less important stories or certain features being postponed for future phases. The simulation also accepts additional inputs to allow additional effort to be counted for which is often overlooked when creating estimates. This is in the form of “Story Glue” to represent nondevelopment time that is still project related and must be accounted for (e.g., meetings, writing reports, demos, etc.). The Quadrus Estimator calculates the total effort to complete the project in man-months. Along with the effort estimate, a combination of proven industry guidelines and research is applied to identify the ideal balance between resources (people) and duration (timescale). While either can be adjusted in the Estimator, the system shows the cost of favoring the other in terms of additional effort (overall cost), more resources (for faster delivery), or longer timescales (for team-size constraints).
Posted in Estimation | Tagged Agile Estimation, Analogy, Disaggregation, Epic, Estimation scales, Expert Opinion, Fibonacci sequence, Planning Poker, Prioritization, Story, Story Points, Theme, Velocity, Wall Estimation | Leave a reply