<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_CYRMgBEdEdqY7JB6N6CW2w" name="agile_estimation,_CGHskBEdEdqY7JB6N6CW2w" guid="_CYRMgBEdEdqY7JB6N6CW2w" changeDate="2008-07-11T09:20:35.000-0700" version="7.2.0">
  <mainDescription>&lt;h3>&#xD;
    Agile Estimation&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    There are three main concepts you need to understand to do agile estimation, see [&lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
    href=&quot;./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#COH05&quot;&#xD;
    guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>COH05&lt;/a>] for more information:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;strong>Estimation of Size&lt;/strong> gives a high-level estimate for the work item, typically measured using a&#xD;
        neutral unit such as points&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Velocity&lt;/strong> tells us how many points this project team can deliver within an iteration;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Estimation of Effort&lt;/strong> translates the size (measured in points) to a detailed estimate of effort&#xD;
        typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how long it will take&#xD;
        the team member(s) to complete the assigned work item(s).&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Estimation of Size&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    &lt;strong>Points&lt;/strong> is a relative measure that can be used for agile estimation of size.&amp;nbsp;The team decides how&#xD;
    big a point is, and based on that size, determines how many points each work item is. To make estimation go fast, use&#xD;
    only full points, 1, 2, 3, 5, 8, and so on, rather than fractions of a point, such 0.25, or 1.65 points. To get&#xD;
    started, look at 10 or so representative work items, give the smallest the size of one point, and then go through all&#xD;
    other work items and give them a relative point estimate based on that point. Note that points are used for high-level&#xD;
    estimates, so do not spend too much time on any one item. This is especially true for work items of lower priority, to&#xD;
    avoid wasting effort on things that are unlikely to be addressed within the current iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A key benefit of points is that they are neutral and relative. Let's say that Ann is 3 times more productive than Jack.&#xD;
    If Ann and Jack agree that work item A is worth 1 point, and they both think work item B is roughly 5 times as big,&#xD;
    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,&#xD;
    while Jack thinks it can be done in 36 hours. That is fine, they may disagree about the actual effort required to do&#xD;
    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&#xD;
    Velocity to determine how much 'size', or how many points, the team can take on within an iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    One project team may say that a work item of a certain size is worth 1 point. Another project team would estimate the&#xD;
    same sized work item to be worth 5 points. That is fine, as long as you are consistent within the same project. Make&#xD;
    sure that the entire team is involved in assessing size, or at least that the same people are involved in all your size&#xD;
    estimates, to ensure consistency within your project. We will see how the concept of velocity will fix also this&#xD;
    discrepancy in a point meaning different things to different project teams.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    You can also use other measures of size, where the most common alternative is Ideal Days. See for example [&lt;a&#xD;
    class=&quot;elementLinkWithUserText&quot;&#xD;
    href=&quot;./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html&quot;&#xD;
    guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>COH05&lt;/a>] for more information.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Velocity&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Velocity is a key metric used for iteration planning. It indicates how many points are delivered upon within an&#xD;
    iteration for a certain team and project. As an example, a team planned to accomplish 20 points in the first iteration.&#xD;
    At the end of the iteration, they noticed that they only delivered upon 14 points, their velocity was hence 14. For the&#xD;
    next iteration, they may plan for fewer points, let's say 18 points, since they think they can do a little better than&#xD;
    in previous iteration. In this iteration, they delivered 17 points, giving them a velocity of 17.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Expect the velocity to change from iteration to iteration. Some iterations go smoother than others, and points are not&#xD;
    always identical in terms of effort. Some team members are more effective than others, and some problems end up being&#xD;
    harder than others. Also, changes to the team structure, learning new skills, changes to the tool environment, better&#xD;
    teaming, or more overhead with meetings or tasks external to the project will all impact velocity. In general, velocity&#xD;
    typically increases during the project as the team builds skills and becomes more cohesive.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Velocity compensates for differences between teams in terms of how big a point is. Let's assume that project team Alpha&#xD;
    and project team Beta are equally efficient in developing software, and they run the same project in parallel. Team&#xD;
    Alpha, however, assesses all work items as being worth 3 times as many points as team Beta's estimates. Team Alpha&#xD;
    assesses work item A, B, C, and D to correspond to 30 points, and team Beta estimates the same work items to correspond&#xD;
    to 10 points. Both teams deliver upon those 4 work items in the next iteration, giving team Alpha a velocity of 30, and&#xD;
    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&#xD;
    plan the next iteration. They both want to take on work item E-H, which team Alpha has estimated to be 30 points, and&#xD;
    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&#xD;
    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&#xD;
    big a point is, as long as you are consistent within your team.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Velocity also averages out the efficiency of different team members. Let's look at an example; Let's assume that Ann&#xD;
    always works 3 times as fast as Jack and Jane. Ann will perhaps deliver 9 points per iteration, and Jack and Jane 3&#xD;
    points each per iteration. The velocity of that 3-person team will be 15 points. As mentioned above, Ann and Jack may&#xD;
    not agree on how much effort is associated with a work item, but they can agree on how many points it is worth. Since&#xD;
    the team velocity is 15, the velocity will automatically translate the point estimate to how much work can be taken on.&#xD;
    As you switch team members, or as team members become more or less efficient, your velocity will change, and you can&#xD;
    hence take on more or less points. This does however not require you to change the estimate of the size. The size is&#xD;
    still the same, and the velocity will help you to calculate how much size you can deliver upon with the team at hand&#xD;
    for that iteration.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Estimation of Effort&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Estimation of Effort translates the size (measured in points) to a detailed estimate of effort typically using the&#xD;
    units of Actual Days or Actual Hours. As you plan an iteration, you will take on a work item, such as detail, design,&#xD;
    implement and test a scenario, which may be sized to 5 points. Since this is still a reasonably big work item, break it&#xD;
    down&amp;nbsp;into a number of smaller work items, such as 4 separate work items for Detailing, Designing, Implementing and&#xD;
    Testing Server portion, and Implementing and Testing Client portion of the scenario. Team members are asked to sign up&#xD;
    for the tasks, and then detail the&amp;nbsp;estimate of the actual effort, measured in hours or days, for their tasks. In&#xD;
    this case, the following actual estimates were done (with person responsible within parenthesis):&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Detailing scenario (Ann): 4 hours&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Designing scenario (Ann and Jack):&amp;nbsp; 6 hours&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Implementing and Testing Server portion of scenario (Jack): 22 hours&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Implementing and Testing Client portion of scenario (Ann): 12 hours&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Total Effort Estimate for Scenario:&lt;/strong> 44 hours&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    If other people would be assigned to the tasks, the estimated actual hours could be quite different. There is hence no&#xD;
    point doing detailed estimates until you know who will do the work, and what actual problems you will run into. Often,&#xD;
    some level of analysis and design of the work item needs to take place before a reasonable estimate can be done.&#xD;
    Remember that estimates are still estimates, and a person assigned to a task should feel free (and be encouraged) to&#xD;
    re-estimate the effort required to complete the task, so we have a realistic view of progress within an iteration.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
