| <?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="-b0rH1AkPSmj1YKyweFWSuQ" |
| name="new_guideline,_oVMZADSoEdy07ZJqOGUGaQ" guid="-b0rH1AkPSmj1YKyweFWSuQ" changeDate="2007-07-19T11:38:29.015-0700"> |
| <mainDescription><h3>
 |
| What Is Prioritized?
 |
| </h3>
 |
| <p>
 |
| Work items are used to prioritize among others:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| enhancement requests and requirements at a level of abstraction appropriate for stakeholders prioritization, such
 |
| as use cases and scenarios,
 |
| </li>
 |
| <li>
 |
| project tasks, such as setting up required infrastructure,
 |
| </li>
 |
| <li>
 |
| defects,
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| or any other work that needs to be prioritized. The <a class="elementLink"
 |
| href="./../../../openup/workproducts/work_items_list.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a> hence
 |
| provides us with one place for prioritizing work. Prioritizing too small units of work may lead to analysis-paralysis.
 |
| </p>
 |
| <h3>
 |
| Who Prioritizes?
 |
| </h3>
 |
| <p>
 |
| Prioritization is done by the extended team. Here are some examples on how different team members contribute to the
 |
| prioritization:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <a class="elementLink" href="./../../../openup/roles/analyst.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a>s
 |
| collaborate with stakeholders to establish the initial priorities for work items to implement, such as features,
 |
| use cases and scenarios.
 |
| </li>
 |
| <li>
 |
| <a class="elementLink" href="./../../../openup/roles/architect.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a>s
 |
| collaborate with stakeholders and development team to identify the architecturally significant use cases and
 |
| scenarios, and re-prioritizes these so the team understands what needs to be done to drive down technical risk and
 |
| to progress the evolution of the product in a technically sensible fashion.
 |
| </li>
 |
| <li>
 |
| <a class="elementLink" href="./../../../openup/roles/developer.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Developer</a>s
 |
| and <a class="elementLink" href="./../../../openup/roles/tester.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a>s
 |
| calls out (not decides) the priorities of defects relative to achieving iteration objectives.
 |
| </li>
 |
| <li>
 |
| <a class="elementLink" href="./../../../openup/roles/project_manager.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project
 |
| Manager</a>s facilitates (not decide) driving convergence on what the team should focus on when planning a project,
 |
| planning an iteration, and managing an iteration to ensure smooth execution, and that the perspectives of all team
 |
| members are properly heard. When the team cannot gain consensus in a reasonable time, the project manager has final
 |
| say on the priority of work items to small to warrant the attention of the paying stakeholder(s).
 |
| </li>
 |
| <li>
 |
| <a class="elementLink" href="./../../../openup/roles/stakeholder.html"
 |
| guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s that pay for the application has the final say on what capabilities
 |
| to prioritize.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| When Do You Prioritize?
 |
| </h3>
 |
| <p>
 |
| When you put in a new work item in a <a class="elementLink" href="./../../../openup/workproducts/work_items_list.html"
 |
| guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>, you should give it an initial priority. Priorities are always
 |
| changing, and below we describe what (re-)prioritization is done when Planning a Project, Planning an Iteration, and
 |
| Managing an Iteration.
 |
| </p>
 |
| <h4>
 |
| Prioritizing When Planning a Project
 |
| </h4>
 |
| <p>
 |
| When planning the project, see <a class="elementLink" href="./../../../openup/tasks/plan_the_project.html"
 |
| guid="_0lC70MlgEdmt3adZL5Dmdw">Plan Project</a>, key features, use cases, and scenarios are prioritized and potentially
 |
| assigned to iterations as a part of laying out the project plan and what should be done when. These prioritizes will be
 |
| revised later on as iterations are planned.
 |
| </p>
 |
| <p>
 |
| When starting a project where we enhance an existing application, we may have an existing work items list from past
 |
| projects and usage of the application. If this is the case, we go through the work items list to survey and
 |
| re-prioritize existing work items, so we understand which to focus on.
 |
| </p>
 |
| <h4>
 |
| Prioritizing When Planning an Iteration
 |
| </h4>
 |
| <p>
 |
| When planning what to deliver for an iteration, see <a class="elementLink"
 |
| href="./../../../openup/tasks/plan_iteration.html" guid="_0keUEMlgEdmt3adZL5Dmdw">Plan Iteration</a>, the team needs to
 |
| balance what delivers immediate value to the stakeholders with mitigating risk, see <a class="elementLink"
 |
| href="./../../../openup/guidances/concepts/project_lifecycle.html" guid="_nSfVwCNYEdyCq8v2ZO4QcA">Project
 |
| Lifecycle</a>. The chosen balance should be reflected in the iteration objectives, which are then driving further
 |
| prioritization and assignments of work items to the next iteration. This exercise should be done by the entire team to
 |
| reflect all key perspectives, such as technical (“doing A before B saves you time”), managerial (“we do not have
 |
| anybody that knows that legacy application until next iteration”, or business (“this scenario is more important than
 |
| that scenario”).
 |
| </p>
 |
| <h4>
 |
| Prioritizing When Managing an Iteration
 |
| </h4>
 |
| <p>
 |
| We recommend against expanding or changing the scope of an iteration, see <a class="elementLink"
 |
| href="./../../../openup/tasks/manage_iteration.html" guid="_8S2aICbYEdqh1LYUOGRh2A">Manage Iteration</a>, since this
 |
| will almost certainly lead to scope creep, and potentially confusion among the team what to work on. This means that as
 |
| you can up with new enhancement requests, you should capture them to a work item, but not assign them to the current
 |
| iteration.
 |
| </p>
 |
| <p>
 |
| During an iteration, you are developing and testing code. As you develop solution increments, you will find defects. In
 |
| most cases, you will directly fix the defect since it is trivial, best done by you, and should be fixed now. Examples
 |
| of such defects are the many problems you find as you implement your code using a test-driven development approach. In
 |
| other cases, the defect should captured as a work item. This allows it to be prioritized, potentially developed by
 |
| somebody else and at a different time. If a defect needs to be addressed to provide an iteration build of reasonable
 |
| quality that addresses the iteration objectives, it should be addressed to the current iteration. Note that this is not
 |
| a creep or change of scope, since it merely indicates that we need to fix something to deliver what we already
 |
| committed to.
 |
| </p>
 |
| <h3>
 |
| How Do You Prioritize
 |
| </h3>
 |
| <p>
 |
| Prioritizing is the difficult balancing of frequently competing priorities. For more information on the art of
 |
| prioritizing, see for example [<a class="elementLinkWithUserText"
 |
| href="./../../../openup/guidances/supportingmaterials/references.html#COH05" guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>].
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
