| <?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><p> |
| 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. |
| </p> |
| <p> |
| 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 <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>. |
| </p> |
| <p> |
| Since iterations are relatively short this should not cause undue delay in dealing with urgent and important change |
| requests. |
| </p> |
| <p> |
| Consider the following when choosing the future iteration where the change request will be addressed: |
| </p> |
| <ul> |
| <li> |
| 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. |
| </li> |
| <li> |
| Assign change requests that mitigate high risks to the earliest iteration possible. |
| </li> |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |