OpenUP/OpenUP_SP/library/openup_basic/guidances/guidelines/assign_changes_to_iteration.xmi

<?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" epf:version="1.0.0" xmi:id="-bUmvEAAtFf6B0aUCux8k9Q" name="changes_at_iter_bound,__yQQ4L6REdqti4GwqTkbsQ" guid="-bUmvEAAtFf6B0aUCux8k9Q" changeDate="2006-09-22T10:37:52.530-0700">
  <mainDescription>&lt;p&gt;
    Most iterative software development processes recommend that changes not be introduced during an iteration. The main
    idea is that the iterations should be short and with clearly defined scope so that they can be time-boxed.
&lt;/p&gt;
&lt;p&gt;
    To limit scope within an iteration, change requests are reviewed and prioritized as soon as possible, but are not
    assigned for implementation until a future iteration via the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;&gt;Artifact: Work Items List&lt;/a&gt;.
&lt;/p&gt;
&lt;p&gt;
    Since iterations are relatively short this should not cause undue delay in dealing with urgent and important change
    requests.
&lt;/p&gt;
&lt;p&gt;
    Consider the following when choosing the future iteration where the change request will be addressed:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Group similar change requests in the same iteration. For example multiple change requests focused on the same
        functionality or that are dependent on each other.
    &lt;/li&gt;
    &lt;li&gt;
        Assign change requests that mitigate high risks to the earliest iteration possible.
    &lt;/li&gt;
&lt;/ul&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>