<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI 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">
  <org.eclipse.epf.uma:ProcessDescription xmi:id="-aXudKqi6rjimd3UsF0smZA" name="ongoing_tasks,__ZInMdOEEdyqlogshP8l4g" guid="-aXudKqi6rjimd3UsF0smZA" version="7.2.0">
    <mainDescription>&lt;p>
    This activity includes a task for requesting changes. This task may occur any time during the lifecycle in response to
    an observed defect, a desired enhancement, or a change request. It is not planned, which means that it does not appear
    as a scheduled activity on the project plan, iteration plan, or work items list. Nevertheless, it is a critical
    activity that must be performed to ensure project success, because your environment is not static.
&lt;/p>
&lt;p>
    Any role may perform this task, however the most common sources of &lt;a class=&quot;elementLink&quot; href=&quot;./../../practice.tech.continuous_integration.base/guidances/concepts/change_requests_AD4868FE.html&quot; guid=&quot;_6jdvECb3Edqh1LYUOGRh2A&quot;>Change Requests&lt;/a> are stakeholders (enhancement requests and change requests) and
    testers (defect reports).
&lt;/p></mainDescription>
  </org.eclipse.epf.uma:ProcessDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-giG0nmV9ZE9q-25Wm3nzBQ" name="work_items_list,_HGqkMdnTEdyNj6EOmqy5Rg" guid="-giG0nmV9ZE9q-25Wm3nzBQ">
    <keyConsiderations>&lt;p>&#xD;
    Work Items should contain estimates. See guidelines on managing work items and agile estimation.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    This artifact provides a focal point for the entire team:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        It provides one list containing all requests for additional capabilities or enhancement for that application. Note&#xD;
        that some of these requests may never be implemented, or be implemented in later projects.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It provides one list of all the work to be prioritized, estimated, and assigned within the project. The risk list&#xD;
        is prioritized separately.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It provides one place to go to for the development team to understand what&amp;nbsp;micro-increments&amp;nbsp;need to be&#xD;
        delivered, get references to material required to carry out the work, and report progress made.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    These are the typical work items that go on this list:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Use cases (and references to use-case specifications)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        System-wide requirements&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Changes and enhancement requests&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Defects&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Development tasks&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Work items can be very large in scope, especially when capturing requests for enhancements, such as &quot;Support Financial&#xD;
    Planning&quot; for a personal finance application. To allow the application to be developed in micro-increments, work items&#xD;
    are analyzed and broken down into smaller work items so that they can be assigned to an iteration, such as a use-case&#xD;
    scenario for&amp;nbsp;&quot;Calculate Net Worth&quot;. Further breakdown may be required to identify suitable tasks to be assigned to&#xD;
    developers, such as &quot;Develop UI for Calculate Net Worth&quot;. This means that work items often have parent/child&#xD;
    relationships, where the lowest level is a specification and tracking device for micro-increments.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
</xmi:XMI>
