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