OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/guidelines/iteration_planning.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\iteration_planning.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: iteration_planning.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_0auiMMlgEdmt3adZL5Dmdw CRC: 3350302035 -->Iteration Planning<!-- END:presentationName,_0auiMMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_0auiMMlgEdmt3adZL5Dmdw CRC: 4112489180 -->The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the iteration and produce a sufficiently detailed plan outlining who needs to do what.<!-- END:briefDescription,_0auiMMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,_71hDkMPgEdmbOvqy4O0adg CRC: 1440019586 --><h3>
     Introduction
 </h3>
 <p>
     The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the
     iteration, produce a sufficiently detailed plan outlining who needs to do what to accomplish those objectives, and
     define how to assess that you accomplished what you set out to accomplish.
 </p>
 <p>
     Iteration planning is ideally done with the entire team in a meeting, typically lasting a few hours, at the beginning
     of an iteration. This ensures that the entire team understands what needs to be done, and they become committed to the
     success of the team. In some cases, it is preferred to have a smaller subset of people, such as the Project Manager, an
     Architect and an Analyst to meet in advance to prep the meeting with a draft iteration plan.
 </p>
 <h3>
     Define High-Level Objectives
 </h3>
 <p>
     A key aspect of an iteration is to focus the team on a short term deliverable of measurable value. Document 1-5
     high-level objectives to make sure that you don't lose focus on what to accomplish during the iteration. Typically, the
     project plan should outline one or several objectives for each iteration, and those objectives are used as a starting
     point. If you need to further detail or clarify the objectives as you plan your iteration, do so.
 </p>
 <p>
     The objectives are usually based on the following factors:
 </p>
 <ul>
     <li>
         <strong>Critical risks not yet mitigated:</strong> Iteration goals often include driving down the most critical
         risks.
     </li>
     <li>
         <strong>The time allocated to the iteration:</strong> Iterations are usually timeboxed, so the Project Manager must
         ensure that the goals for the iteration are realistic relative to the time and the resources allocated to the
         iteration.
     </li>
     <li>
         <strong>The highest priority features:</strong> requirements are prioritized to ensure that the critical features
         of the application will be developed and tested early on.
     </li>
 </ul>
 <h3>
     Produce an Iteration Plan
 </h3>
 <p>
     There is an Iteration Plan per iteration that should outline who will implement which Work Item in how long a time.
     Since iterations are time-boxed, we need to understand how big our ‘box” is by assessing how many hours of actual work
     can be taken on. Let’s assume that you have 6 team members, and you have 15 working days in your iteration, and you on
     average can do 5 actual hours of work per person and day. This will give you 6x15x5h = 450 hours of actual work. Note
     that the average team member only performs 4-6 hours of actual project work per day, with the rest being consumed by
     e-mails, meetings, and other overhead activities not directly related to the project.
 </p>
 <p>
     The team should then revisit and update priorities for all the high-priority items in the Work Items List, to make sure
     that an important Work Item is not missed that would otherwise fall just below the list of what can be taken on in this
     iteration.
 </p>
 <p>
     Pick the top-priority Work Item and see if it matches the objectives of the iteration. If it does, assess whether the
     Work Item is too big to take on within an iteration. If it is too big, break it down into smaller Work Items. Once the
     Work Item has been decomposed, the team determines whether to take on one or several child Work Items.
 </p>
 <p>
     <em>Example: The team would like to take on Work Item “Develop Use Case A”, but it would take roughly 300 hours to
     develop, so they feel that it is only necessary to do a subset of the use case to achieve their iteration objectives,
     allowing them to take on other high-priority Work Items. They divide the Work Item into 5 smaller work items
     representing different scenarios of use case A. The team decides to take on one out of the 5 identified scenarios in
     this iteration.</em>
 </p>
 <p>
     When a 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,
     but based on culture, you may instead have the project manager assign the work.
 </p>
 <p>
     The next step is for team member(s) to assess how many actual hours or days it will take to do the work. Ideally, you
     want to have each work assignment to be no more than 2 days of work. If the Work Item is too big, consider breaking it
     down into smaller Work Items.
 </p>
 <p>
     The team sums up the actual estimate for each Work Item they have committed to, and checks if they can commit to any
     more work.
 </p>
 <p>
     <em>Example: Jack signed up to develop the chosen scenario for use case A. He thinks that it would take 50 hours, so he
     decided to develop the work into a set of tasks, and he asks other team members to help out with various subtasks:</em>
 </p>
 <ul>
     <li>
         <em>Detail the requirements (Jack) —5 hours</em>
     </li>
     <li>
         <em>Design the scenario (Jack, Ann, and David) —5 hours</em>
     </li>
     <li>
         <em>Implement and test the dB changes (Ann)—12 hours</em>
     </li>
     <li>
         <em>Implement and test the server portion (David)—16 hours</em>
     </li>
     <li>
         <em>Implement and test the client portion (Jack)—12 hours</em>
     </li>
     <li>
         <em>Total—50 hours</em>
     </li>
 </ul>
 <p>
     As Work Items are decomposed into smaller tasks, estimates can typically be improved. You also better come to
     understand what is involved, and whether other team member may be better suited to take on a subset of the task
 </p>
 <p>
     The team now determines whether they are willing to take on another Work Item by comparing actual hours signed up for
     to the actual hours available. In this case, the team has only signed up for 50 hours so far, and hence have another
     400 hours available
 </p>
 <h3>
     Define Evaluation Criteria
 </h3>
 <p>
     It is critical that it is clear to all team members and other stakeholders how you will measure success at the end of
     the iteration. Obvious success criteria should be that you can test the functionality implemented, and that no or few
     defects are detected. Having too many defects makes it impossible to use the functionality, and it will prevent
     meaningful feedback. Test objectives and test cases need to be clearly outlined.
 </p>
 <p>
     There may be other success criteria, such as that you demo the capabilities to a certain set of stakeholders with
     favorable review comments, or that you can successfully demonstrate or make available a tech preview at a conference.
 </p><!-- END:mainDescription,_71hDkMPgEdmbOvqy4O0adg -->
 </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\iteration_planning.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: iteration_planning.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_0auiMMlgEdmt3adZL5Dmdw CRC: 3350302035 -->Iteration Planning<!-- END:presentationName,_0auiMMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_0auiMMlgEdmt3adZL5Dmdw CRC: 4112489180 -->The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the iteration and produce a sufficiently detailed plan outlining who needs to do what.<!-- END:briefDescription,_0auiMMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,_71hDkMPgEdmbOvqy4O0adg CRC: 1440019586 --><h3>
	Introduction
	</h3>
	<p>
	The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the
	iteration, produce a sufficiently detailed plan outlining who needs to do what to accomplish those objectives, and
	define how to assess that you accomplished what you set out to accomplish.
	</p>
	<p>
	Iteration planning is ideally done with the entire team in a meeting, typically lasting a few hours, at the beginning
	of an iteration. This ensures that the entire team understands what needs to be done, and they become committed to the
	success of the team. In some cases, it is preferred to have a smaller subset of people, such as the Project Manager, an
	Architect and an Analyst to meet in advance to prep the meeting with a draft iteration plan.
	</p>
	<h3>
	Define High-Level Objectives
	</h3>
	<p>
	A key aspect of an iteration is to focus the team on a short term deliverable of measurable value. Document 1-5
	high-level objectives to make sure that you don't lose focus on what to accomplish during the iteration. Typically, the
	project plan should outline one or several objectives for each iteration, and those objectives are used as a starting
	point. If you need to further detail or clarify the objectives as you plan your iteration, do so.
	</p>
	<p>
	The objectives are usually based on the following factors:
	</p>
	<ul>
	<li>
	<strong>Critical risks not yet mitigated:</strong> Iteration goals often include driving down the most critical
	risks.
	</li>
	<li>
	<strong>The time allocated to the iteration:</strong> Iterations are usually timeboxed, so the Project Manager must
	ensure that the goals for the iteration are realistic relative to the time and the resources allocated to the
	iteration.
	</li>
	<li>
	<strong>The highest priority features:</strong> requirements are prioritized to ensure that the critical features
	of the application will be developed and tested early on.
	</li>
	</ul>
	<h3>
	Produce an Iteration Plan
	</h3>
	<p>
	There is an Iteration Plan per iteration that should outline who will implement which Work Item in how long a time.
	Since iterations are time-boxed, we need to understand how big our ‘box” is by assessing how many hours of actual work
	can be taken on. Let’s assume that you have 6 team members, and you have 15 working days in your iteration, and you on
	average can do 5 actual hours of work per person and day. This will give you 6x15x5h = 450 hours of actual work. Note
	that the average team member only performs 4-6 hours of actual project work per day, with the rest being consumed by
	e-mails, meetings, and other overhead activities not directly related to the project.
	</p>
	<p>
	The team should then revisit and update priorities for all the high-priority items in the Work Items List, to make sure
	that an important Work Item is not missed that would otherwise fall just below the list of what can be taken on in this
	iteration.
	</p>
	<p>
	Pick the top-priority Work Item and see if it matches the objectives of the iteration. If it does, assess whether the
	Work Item is too big to take on within an iteration. If it is too big, break it down into smaller Work Items. Once the
	Work Item has been decomposed, the team determines whether to take on one or several child Work Items.
	</p>
	<p>
	<em>Example: The team would like to take on Work Item “Develop Use Case A”, but it would take roughly 300 hours to
	develop, so they feel that it is only necessary to do a subset of the use case to achieve their iteration objectives,
	allowing them to take on other high-priority Work Items. They divide the Work Item into 5 smaller work items
	representing different scenarios of use case A. The team decides to take on one out of the 5 identified scenarios in
	this iteration.</em>
	</p>
	<p>
	When a 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,
	but based on culture, you may instead have the project manager assign the work.
	</p>
	<p>
	The next step is for team member(s) to assess how many actual hours or days it will take to do the work. Ideally, you
	want to have each work assignment to be no more than 2 days of work. If the Work Item is too big, consider breaking it
	down into smaller Work Items.
	</p>
	<p>
	The team sums up the actual estimate for each Work Item they have committed to, and checks if they can commit to any
	more work.
	</p>
	<p>
	<em>Example: Jack signed up to develop the chosen scenario for use case A. He thinks that it would take 50 hours, so he
	decided to develop the work into a set of tasks, and he asks other team members to help out with various subtasks:</em>
	</p>
	<ul>
	<li>
	<em>Detail the requirements (Jack) —5 hours</em>
	</li>
	<li>
	<em>Design the scenario (Jack, Ann, and David) —5 hours</em>
	</li>
	<li>
	<em>Implement and test the dB changes (Ann)—12 hours</em>
	</li>
	<li>
	<em>Implement and test the server portion (David)—16 hours</em>
	</li>
	<li>
	<em>Implement and test the client portion (Jack)—12 hours</em>
	</li>
	<li>
	<em>Total—50 hours</em>
	</li>
	</ul>
	<p>
	As Work Items are decomposed into smaller tasks, estimates can typically be improved. You also better come to
	understand what is involved, and whether other team member may be better suited to take on a subset of the task
	</p>
	<p>
	The team now determines whether they are willing to take on another Work Item by comparing actual hours signed up for
	to the actual hours available. In this case, the team has only signed up for 50 hours so far, and hence have another
	400 hours available
	</p>
	<h3>
	Define Evaluation Criteria
	</h3>
	<p>
	It is critical that it is clear to all team members and other stakeholders how you will measure success at the end of
	the iteration. Obvious success criteria should be that you can test the functionality implemented, and that no or few
	defects are detected. Having too many defects makes it impossible to use the functionality, and it will prevent
	meaningful feedback. Test objectives and test cases need to be clearly outlined.
	</p>
	<p>
	There may be other success criteria, such as that you demo the capabilities to a certain set of stakeholders with
	favorable review comments, or that you can successfully demonstrate or make available a tech preview at a conference.
	</p><!-- END:mainDescription,_71hDkMPgEdmbOvqy4O0adg -->
	</body>
	</html>