| <?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.3/uma.ecore" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-G1Oxlk6F0R09vClqy1EzOw" name="work_items_list,_7vEXEMA4EdqSgKaj2SZBmg" guid="-G1Oxlk6F0R09vClqy1EzOw" changeDate="2006-08-31T13:22:12.278-0700"> |
| <mainDescription><h3> |
| Introduction |
| </h3> |
| <p> |
| The <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.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> |
| <p> |
| Some of the work items may still be poorly defined, representing a big chunk of work requiring potentially several |
| staff months of effort. As the priority of these work items increase, 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, see Figure 1. |
| </p> |
| <br /> |
| <img height="369" alt="work item list overview" src="./resources/wil_overview.bmp" width="600" /><br /> |
| <br /> |
| <p> |
| <strong><em>Figure 1. Work Items List provides one prioritized list of scheduled and proposed work.</em></strong> |
| </p> |
| <p> |
| A Work Item may represent work associated with a defect, enhancement request, use case, scenario, user story, |
| supporting requirement, or anything else that captures a potential requirement or improvement to your system. A Work |
| Item may reference any type of requirement, defect, enhancement request, or other useful information guiding you in |
| what needs to be done. |
| </p> |
| <p> |
| A big advantage with the <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;is that it enables you to prioritize only one list |
| containing all 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 separately prioritize the risk list. |
| </p> |
| <p> |
| Nothing in the project will get done if not represented or mapped to a Work Item. This means that all requirements, |
| defects and change requests have to at some stage be mapped to a work item. 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 status of the project. |
| </p> |
| <p> |
| There are two major types of Work Items: |
| </p> |
| <ul> |
| <li> |
| <strong>Un-scheduled 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. |
| </li> |
| <li> |
| <strong>Scheduled Work Items:</strong> These Work Items are assigned to an iteration, and typically have an |
| additional set of attributes filled in, such as detailed effort estimates. |
| </li> |
| </ul> |
| <h3> |
| Un-scheduled Work Items |
| </h3> |
| <p> |
| Most Work Items are initially un-scheduled, 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_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>. |
| </li> |
| <li> |
| State, such as New, Assigned, Resolved, Verified, Closed, see Work Items States below |
| </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> |
| Once a Work Item has been assigned to an iteration, it becomes scheduled. Note that we only assign Work Items 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_basic/guidances/guidelines/iteration_planning,_0auiMMlgEdmt3adZL5Dmdw.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_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.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 do <a class="elementLinkWithType" href="./../../../openup_basic/guidances/reports/iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: Iteration Burndown</a> by tracking how much work is left. |
| </p> |
| <h3> |
| Work Items States |
| </h3> |
| <p> |
| We have found the following states to be useful to track Work Items: |
| </p> |
| <ul> |
| <li> |
| New: Work Item has been created, but not yet assigned to a team member. |
| </li> |
| <li> |
| Assigned: A team member has been identified as responsible for the Work Item. |
| </li> |
| <li> |
| Resolved: The team member responsible for the work items has implemented and tested the Work Item. |
| </li> |
| <li> |
| Verified: The Work Item has been independently tested. |
| </li> |
| <li> |
| Closed: 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> |