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