| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-G1Oxlk6F0R09vClqy1EzOw" |
| name="work_items_list,_7vEXEMA4EdqSgKaj2SZBmg" guid="-G1Oxlk6F0R09vClqy1EzOw" |
| changeDate="2007-07-23T18:39:42.625-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, see <a class="elementLink" href="./../../../openup/guidances/concepts/micro_increments_C8773066.html" guid="_S80VwCNbEdyCq8v2ZO4QcA">Micro-Increments</a>. 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 face="Verdana, Arial, Helvetica, sans-serif" size="2">Work Items List provides one prioritized list of
 |
| scheduled and proposed work</font></strong>
 |
| </p>
 |
| <div align="center">
 |
| <br />
 |
| <img alt="" src="resources/work_item_prioritization_diagram.jpg" /><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>
 |
| <h3>
 |
| Unscheduled Work Items
 |
| </h3>
 |
| <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>
 |
| <h3>
 |
| Scheduled Work Items
 |
| </h3>
 |
| <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>
 |
| <h3>
 |
| Work Item states
 |
| </h3>
 |
| <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> |
