OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/agile_estimation.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>\openup_basic\guidances\guidelines\agile_estimation.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: agile_estimation.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_CGHskBEdEdqY7JB6N6CW2w CRC: 1236859462 -->Agile Estimation<!-- END:presentationName,_CGHskBEdEdqY7JB6N6CW2w -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_CGHskBEdEdqY7JB6N6CW2w CRC: 1733553587 -->This guideline explains three key concepts, and their interrelationships, for doing agile estimation; estimation of size, velocity, and estimation of effort.<!-- END:briefDescription,_CGHskBEdEdqY7JB6N6CW2w -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,_CYRMgBEdEdqY7JB6N6CW2w CRC: 1918863300 --><h3>
     Agile Estimation
 </h3>
 <p>
     There are three main concepts you need to understand to do agile estimation:
 </p>
 <ul>
     <li>
         <strong>Estimation of Size</strong> gives you a high-level estimate for the work item, typically measured using a
         neutral unit such as points
     </li>
     <li>
         <strong>Velocity</strong> tells us how many points this project team can deliver within an iteration;
     </li>
     <li>
         <strong>Estimation of Effort</strong> 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) assigned to the work item to do the work.
     </li>
 </ul>
 <h4>
     Estimation of Size
 </h4>
 <p>
     Agile estimation of size is typically done using a relative measure called <strong>points</strong>.&nbsp; You decide
     how big a point is, and based on that size, you determine how many points each work item is. To make estimation go
     fast, you want to use 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 started, look at 10 or so representative work items, give the smallest the size of one point, and then
     go through all other work items and give them a relative point estimate based on that point. Note that 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, since you would then waste effort on things that are unlikely to be addressed within the current
     iteration.
 </p>
 <p>
     A key benefit of 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 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.
 </p>
 <p>
     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.
     You&nbsp;want to 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.
 </p>
 <p>
     You can also use other measures of size, where the most common alternative is Ideal Days. See for example [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>] for more information.
 </p>
 <h4>
     Velocity
 </h4>
 <p>
     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 may plan for taking on 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.
 </p>
 <p>
     You should 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 tha project as the team builds skills and becomes more cohesive.
 </p>
 <p>
     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. 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.
 </p>
 <p>
     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.
 </p>
 <h4>
     Estimation of Effort
 </h4>
 <p>
     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. Typically you at this time break down this still reasonably big work item 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. You would now do a detailed estimate of the actual effort,
     measured in hours or days, associated with each of those 4 tasks. This estimate should be done by the person assigned
     to do the task. In this case you may assign the following actual estimates (with person responsible within
     parenthesis):
 </p>
 <ul>
     <li>
         Detailing scenario (Ann): 4 hours
     </li>
     <li>
         Designing scenario (Ann and Jack):&nbsp; 6 hours
     </li>
     <li>
         Implementing and Testing Server portion of scenario (Jack): 22 hours&nbsp;
     </li>
     <li>
         Implementing and Testing Client portion of scenario (Ann): 12 hours
     </li>
     <li>
         <strong>Total Effort Estimate for Scenario:</strong> 44 hours
     </li>
 </ul>
 <p>
     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,
     you have to do some level of analysis and design of the work item before you can come up with a reasonable estimate.
     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.<br />
 </p><!-- END:mainDescription,_CYRMgBEdEdqY7JB6N6CW2w -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>\openup_basic\guidances\guidelines\agile_estimation.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: agile_estimation.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_CGHskBEdEdqY7JB6N6CW2w CRC: 1236859462 -->Agile Estimation<!-- END:presentationName,_CGHskBEdEdqY7JB6N6CW2w -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_CGHskBEdEdqY7JB6N6CW2w CRC: 1733553587 -->This guideline explains three key concepts, and their interrelationships, for doing agile estimation; estimation of size, velocity, and estimation of effort.<!-- END:briefDescription,_CGHskBEdEdqY7JB6N6CW2w -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,_CYRMgBEdEdqY7JB6N6CW2w CRC: 1918863300 --><h3>
	Agile Estimation
	</h3>
	<p>
	There are three main concepts you need to understand to do agile estimation:
	</p>
	<ul>
	<li>
	<strong>Estimation of Size</strong> gives you a high-level estimate for the work item, typically measured using a
	neutral unit such as points
	</li>
	<li>
	<strong>Velocity</strong> tells us how many points this project team can deliver within an iteration;
	</li>
	<li>
	<strong>Estimation of Effort</strong> 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) assigned to the work item to do the work.
	</li>
	</ul>
	<h4>
	Estimation of Size
	</h4>
	<p>
	Agile estimation of size is typically done using a relative measure called <strong>points</strong>.  You decide
	how big a point is, and based on that size, you determine how many points each work item is. To make estimation go
	fast, you want to use 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 started, look at 10 or so representative work items, give the smallest the size of one point, and then
	go through all other work items and give them a relative point estimate based on that point. Note that 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, since you would then waste effort on things that are unlikely to be addressed within the current
	iteration.
	</p>
	<p>
	A key benefit of 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 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.
	</p>
	<p>
	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.
	You want to 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.
	</p>
	<p>
	You can also use other measures of size, where the most common alternative is Ideal Days. See for example [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>] for more information.
	</p>
	<h4>
	Velocity
	</h4>
	<p>
	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 may plan for taking on 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.
	</p>
	<p>
	You should 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 tha project as the team builds skills and becomes more cohesive.
	</p>
	<p>
	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. 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.
	</p>
	<p>
	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.
	</p>
	<h4>
	Estimation of Effort
	</h4>
	<p>
	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. Typically you at this time break down this still reasonably big work item 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. You would now do a detailed estimate of the actual effort,
	measured in hours or days, associated with each of those 4 tasks. This estimate should be done by the person assigned
	to do the task. In this case you may assign the following actual estimates (with person responsible within
	parenthesis):
	</p>
	<ul>
	<li>
	Detailing scenario (Ann): 4 hours
	</li>
	<li>
	Designing scenario (Ann and Jack):  6 hours
	</li>
	<li>
	Implementing and Testing Server portion of scenario (Jack): 22 hours
	</li>
	<li>
	Implementing and Testing Client portion of scenario (Ann): 12 hours
	</li>
	<li>
	<strong>Total Effort Estimate for Scenario:</strong> 44 hours
	</li>
	</ul>
	<p>
	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,
	you have to do some level of analysis and design of the work item before you can come up with a reasonable estimate.
	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.<br />
	</p><!-- END:mainDescription,_CYRMgBEdEdqY7JB6N6CW2w -->
	</body>
	</html>