| <?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.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-G1Oxlk6F0R09vClqy1EzOw" |
| name="work_items_list,_7vEXEMA4EdqSgKaj2SZBmg" guid="-G1Oxlk6F0R09vClqy1EzOw" |
| changeDate="2007-07-03T11:28:32.413-0700" version="7.1.0"> |
| <mainDescription>The <a class="elementLinkWithType" href="./../../../openup/workproducts/work_items_list_39D03CC8.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: 
 |
| Work Items List</a>&nbsp;captures all scheduled work to be done within the project, 
 |
| as well as proposed work that may affect the product. Some of the Work Items may 
 |
| be implemented in this project, some of them may be implemented in a future project, 
 |
| and some of them may never be implemented. 
 |
| <p> Some of the Work Items may still be poorly defined; therefore, it could represent 
 |
| a big chunk of work, requiring potentially several staff months of effort. As 
 |
| the priority of these Work Items increases, they are typically decomposed into 
 |
| smaller work items that represent specific and well-defined tasks that may take 
 |
| hours or days to address. In other cases, specific and well-defined Work Items 
 |
| are created directly, representing, for example, a defect to be addressed, as 
 |
| this figure illustrates.</p>
 |
| <p align="center"><strong><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Work Items List provides one prioritized list of scheduled and proposed work</font></strong></p>
 |
| <div align="center"><br />
 |
| <img height="365" alt="" src="resources/workItemPrioritizationDiagram.jpg" width="587" /><br />
 |
| </div>
 |
| <p> A Work Item may represent work associated with a defect, enhancement request, 
 |
| change request, use case, scenario, user story, supporting requirement, stakeholder 
 |
| request, or anything else that captures a potential requirement or improvement 
 |
| to your system. A Work Item may reference any type of requirement or other useful 
 |
| information that guides you in what needs to be done. </p>
 |
| <p> A big advantage with the <a class="elementLinkWithType" href="./../../../openup/workproducts/work_items_list_39D03CC8.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: 
 |
| Work Items List</a>&nbsp;is that it enables you to prioritize only one list 
 |
| containing all of the things that may need to be addressed, whether the Work 
 |
| Item represent a work related to a requirement, enhancement, or defect. The 
 |
| one exception is that we prioritize the risk list separately. </p>
 |
| <p> Nothing in the project will get done if not represented or mapped to a Work 
 |
| Item. This means that all requirements, defect reports, and change requests 
 |
| have to be mapped to a Work Item at some stage. Also, a developer will not take 
 |
| on work that is not represented in a Work Item. Only Work Items needs to be 
 |
| prioritized. This also means that tracking Work Items are a primary means of 
 |
| understanding the status of the project. </p>
 |
| <p>
 |
| There are two major types of Work Items:
 |
| </p>
 |
| <ul>
 |
| 
 |
| <li> <strong>Unscheduled Work Items:</strong> These Work Items have not yet been assigned to an iteration, 
 |
| and there is no detailed effort estimate for the Work Item yet.<br/> </li>
 |
| 
 |
| <li> <strong>Scheduled Work Items:</strong> These Work Items are assigned to an iteration, and they 
 |
| typically have an additional set of attributes filled in, such as detailed 
 |
| effort estimates. </li>
 |
| </ul>
 |
| <h1> Unscheduled Work Items </h1>
 |
| <p> Most Work Items are initially unscheduled, meaning that it has not yet been 
 |
| decided whether to do them and when to do them. Unscheduled Work Items should 
 |
| always represent something meaningful to deliver to stakeholders, such a scenario 
 |
| to be detailed, designed, implemented, and tested. You may consider capturing 
 |
| the following data for such Work Items: </p>
 |
| <ul>
 |
| <li>
 |
| Name
 |
| </li>
 |
| <li>
 |
| Description
 |
| </li>
 |
| <li>
 |
| Priority
 |
| </li>
 |
| <li> Size estimate, such as a point estimate (see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: 
 |
| Agile Estimation</a>)</li>
 |
| <li> State, such as New, Assigned, Resolved, Verified, Closed (see Work Items 
 |
| states, which follows here)</li>
 |
| <li>
 |
| Links to other reference material, such as requirements or detailed specifications of what needs to be done
 |
| </li>
 |
| </ul>
 |
| <h1> Scheduled Work Items </h1>
 |
| <p> After a Work Item has been assigned to an iteration, it becomes <i>scheduled</i>. 
 |
| We assign Work Items only to the current or next iteration. There is no point 
 |
| in assigning Work Items to a specific future iteration, since we cannot predict 
 |
| what a meaningful schedule will be more than an iteration in advance (see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/iteration_planning_C77F13CE.html" guid="_0auiMMlgEdmt3adZL5Dmdw">Guideline: 
 |
| Iteration Planning</a>).</p>
 |
| <p>
 |
| The following additional attributes are useful for Scheduled Work Items:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Target iteration
 |
| </li>
 |
| <li>
 |
| Responsible team member
 |
| </li>
 |
| 
 |
| <li> Effort estimate left, such as actual hours of work (see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: 
 |
| Agile Estimation)</a></li>
 |
| <li>
 |
| Hours worked
 |
| </li>
 |
| </ul>
 |
| <p> This provides the information required to plan and manage an iteration. We 
 |
| can plan iterations by understanding effort involved, and we can <a class="elementLinkWithType" href="./../../../openup/guidances/reports/iteration_burndown_9C1C96F5.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: 
 |
| Iteration Burndown</a> by tracking how much work is left to do. </p>
 |
| <h1> Work Item states </h1>
 |
| <p> We have found the following states to be useful for tracking Work Items: </p>
 |
| <ul>
 |
| 
 |
| <li> <b>New: </b>Work Item has been created, but not yet assigned to a team 
 |
| member. </li>
 |
| 
 |
| <li> <b>Assigned: </b>A team member has been identified as responsible for the 
 |
| Work Item. </li>
 |
| 
 |
| <li> <b>Resolved: </b>The team member responsible for the Work Items has implemented 
 |
| and tested the Work Item. </li>
 |
| 
 |
| <li> <b>Verified: </b>The Work Item has been independently tested. </li>
 |
| 
 |
| <li> <b>Closed:</b> The Work Item is no longer active. </li>
 |
| </ul>
 |
| <p>
 |
| You may choose another set of states, based on your needs.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
