<?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">
  <org.eclipse.epf.uma:ProcessDescription xmi:id="-L0i6JTmgEzTPleQgpqGmZA" name="Initiate Project,_SafS8bjaEe2ItPaV9bHRfA" guid="-L0i6JTmgEzTPleQgpqGmZA"/>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-KkMdSFU3igWvU1Xig8QJTg" name="iteration_plan,_XqirxLjkEe2ItPaV9bHRfA" guid="-KkMdSFU3igWvU1Xig8QJTg">
    <keyConsiderations>&lt;p>&#xD;
&#xD;
    Work items assigned to an iteration do not necessarily have the same priority. When selecting work items from the Work&#xD;
&#xD;
    Items List, the iteration plan may end up having work items with different priorities (for example, you assign the&#xD;
&#xD;
    remaining high priority work items, plus a few mid priority ones from the Work Items List). No matter what previous&#xD;
&#xD;
    priorities the work items had, when assigned to an iteration&amp;nbsp;the team has to make sure they are able to develop&#xD;
&#xD;
    what has been&amp;nbsp;assigned to the&amp;nbsp;iteration, and deciding on&amp;nbsp;what to&amp;nbsp;develop first (or&#xD;
&#xD;
    even&amp;nbsp;develop things in parallel) on an iteration will vary from project to project, from iteration to iteration.&#xD;
&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    The main objectives of the iteration plan is to provide the team with one central place for information regarding&#xD;
    iteration objectives, detailed plan with task assignments, and evaluation results. This artifact also helps the team to&#xD;
    monitor the progress of the iteration and keeps the results of the iteration assessment that may be usefull for&#xD;
    improving the next one.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The task assignments for an iteration is a subset of all tasks on the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/workproducts/work_items_list_39D03CC8.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;>Artifact: Work Items List&lt;/a>, therefore the iteration plan ideally references those work items.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-y_Tv4vcwM1i0ogyyhyq-Hg" name="work_items_list,_Xqirx7jkEe2ItPaV9bHRfA" guid="-y_Tv4vcwM1i0ogyyhyq-Hg">
    <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 &lt;a class=&quot;elementLink&quot;&#xD;
        href=&quot;./../../openup/guidances/concepts/micro_increments.html&quot;&#xD;
        guid=&quot;_S80VwCNbEdyCq8v2ZO4QcA&quot;>Micro-Increments&lt;/a>&amp;nbsp;need to be delivered, get references to material required&#xD;
        to carry out the work, and one place to go to report progress made.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    These are the typical work items that go into 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;
        Supporting 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 “Support Financial&#xD;
    Planning” 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 they can be assigned to an iteration, such as a use-case&#xD;
    scenario for&amp;nbsp;“Calculate Net Worth”. Further breakdown may be required to identify suitable tasks to be assigned to&#xD;
    developers, such as “Develop UI for Calculate Net Worth”. 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>&lt;p/>&lt;p>&#xD;
    Work Items should contain estimates, see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/guidelines/work_items_list_32AC6ABD.html&quot; guid=&quot;_7vEXEMA4EdqSgKaj2SZBmg&quot;>Guideline: Managing Work Items&lt;/a>&amp;nbsp;and &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html&quot; guid=&quot;_CGHskBEdEdqY7JB6N6CW2w&quot;>Guideline: Agile Estimation&lt;/a>.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-6BoJ9-MdGzaZ2y37qEsH1w" name="risk_list,_XqiryrjkEe2ItPaV9bHRfA" guid="-6BoJ9-MdGzaZ2y37qEsH1w">
    <keyConsiderations>&lt;p>&#xD;
    This list should capture the critical and serious risks. If you find this list extending beyond 20, carefully consider&#xD;
    whether they are really serious risks. Tracking more than 20 risks is an onerous task.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    This list identifies, in decreasing order of priority, all the &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup/guidances/termdefinitions/risk_33255339.html&quot; guid=&quot;_ii2LUEvGEdunZcj9T5hrMQ&quot;>risks&lt;/a> associated to a project.&amp;nbsp;It serves as a focal point for project&#xD;
    activities and is the basis around which iterations are organized.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    See &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/concepts/risk_AF5840DA.html&quot; guid=&quot;_0bsLgMlgEdmt3adZL5Dmdw&quot;>Concept: Risk&lt;/a>&amp;nbsp;for more details.&lt;!--EndFragment-->&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-KG7jg8sLqnntei-WqJO2tQ" name="iteration_plan,_XqZh0bjkEe2ItPaV9bHRfA" guid="-KG7jg8sLqnntei-WqJO2tQ">
    <keyConsiderations>&lt;p>&#xD;
&#xD;
    Work items assigned to an iteration do not necessarily have the same priority. When selecting work items from the Work&#xD;
&#xD;
    Items List, the iteration plan may end up having work items with different priorities (for example, you assign the&#xD;
&#xD;
    remaining high priority work items, plus a few mid priority ones from the Work Items List). No matter what previous&#xD;
&#xD;
    priorities the work items had, when assigned to an iteration&amp;nbsp;the team has to make sure they are able to develop&#xD;
&#xD;
    what has been&amp;nbsp;assigned to the&amp;nbsp;iteration, and deciding on&amp;nbsp;what to&amp;nbsp;develop first (or&#xD;
&#xD;
    even&amp;nbsp;develop things in parallel) on an iteration will vary from project to project, from iteration to iteration.&#xD;
&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    The main objectives of the iteration plan is to provide the team with one central place for information regarding&#xD;
    iteration objectives, detailed plan with task assignments, and evaluation results. This artifact also helps the team to&#xD;
    monitor the progress of the iteration and keeps the results of the iteration assessment that may be usefull for&#xD;
    improving the next one.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The task assignments for an iteration is a subset of all tasks on the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/workproducts/work_items_list_39D03CC8.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;>Artifact: Work Items List&lt;/a>, therefore the iteration plan ideally references those work items.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-DJRzdm65iL1C3H89L-B7Vg" name="work_items_list,_XqZh1LjkEe2ItPaV9bHRfA" guid="-DJRzdm65iL1C3H89L-B7Vg">
    <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 &lt;a class=&quot;elementLink&quot;&#xD;
        href=&quot;./../../openup/guidances/concepts/micro_increments.html&quot;&#xD;
        guid=&quot;_S80VwCNbEdyCq8v2ZO4QcA&quot;>Micro-Increments&lt;/a>&amp;nbsp;need to be delivered, get references to material required&#xD;
        to carry out the work, and one place to go to report progress made.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    These are the typical work items that go into 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;
        Supporting 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 “Support Financial&#xD;
    Planning” 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 they can be assigned to an iteration, such as a use-case&#xD;
    scenario for&amp;nbsp;“Calculate Net Worth”. Further breakdown may be required to identify suitable tasks to be assigned to&#xD;
    developers, such as “Develop UI for Calculate Net Worth”. 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>&lt;p/>&lt;p>&#xD;
    Work Items should contain estimates, see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/guidelines/work_items_list_32AC6ABD.html&quot; guid=&quot;_7vEXEMA4EdqSgKaj2SZBmg&quot;>Guideline: Managing Work Items&lt;/a>&amp;nbsp;and &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html&quot; guid=&quot;_CGHskBEdEdqY7JB6N6CW2w&quot;>Guideline: Agile Estimation&lt;/a>.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-lD19SSMjAYyyQ_uDRGzbVQ" name="project_plan,_XqZh17jkEe2ItPaV9bHRfA" guid="-lD19SSMjAYyyQ_uDRGzbVQ"/>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-mkNLsLRUrpAV7Vnqb0MFZA" name="risk_list,_XqZh2rjkEe2ItPaV9bHRfA" guid="-mkNLsLRUrpAV7Vnqb0MFZA">
    <keyConsiderations>&lt;p>&#xD;
    This list should capture the critical and serious risks. If you find this list extending beyond 20, carefully consider&#xD;
    whether they are really serious risks. Tracking more than 20 risks is an onerous task.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    This list identifies, in decreasing order of priority, all the &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup/guidances/termdefinitions/risk_33255339.html&quot; guid=&quot;_ii2LUEvGEdunZcj9T5hrMQ&quot;>risks&lt;/a> associated to a project.&amp;nbsp;It serves as a focal point for project&#xD;
    activities and is the basis around which iterations are organized.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    See &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/concepts/risk_AF5840DA.html&quot; guid=&quot;_0bsLgMlgEdmt3adZL5Dmdw&quot;>Concept: Risk&lt;/a>&amp;nbsp;for more details.&lt;!--EndFragment-->&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-cGGoI7grjER8F09J4QaAQA" name="vision,_Xq_XsrjkEe2ItPaV9bHRfA" guid="-cGGoI7grjER8F09J4QaAQA">
    <refinedDescription>&lt;p>&#xD;
    This artifact&amp;nbsp;provides a complete vision for the software system under development and supports the contract&#xD;
    between the customer and the development organization. Every project needs a source for capturing all Stakeholders'&#xD;
    expectations.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This artifact&amp;nbsp;is written from the customers' perspective, focusing on the essential features of the system and&#xD;
    acceptable levels of quality. The artifact should include a description of what &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup/guidances/termdefinitions/feature_4ED64AEE.html&quot; guid=&quot;_PgYREAeYEduWycDgioo5rg&quot;>features&lt;/a>&amp;nbsp;will be included, as well as those considered but not included.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-zuKdmo0uLfGR5NkdSmMkvg" name="supporting_requirements_spec,_Xq_XtbjkEe2ItPaV9bHRfA" guid="-zuKdmo0uLfGR5NkdSmMkvg">
    <refinedDescription>&lt;p>&#xD;
    Supporting Requirements and Use Cases, together, define the system requirements. Use Cases describe the behavioral&#xD;
    requirements for the system, and Supporting Requirements describe system-wide requirements that are not captured within&#xD;
    the Use-Case Specifications. Making this distinction simplifies maintenance.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Supporting Requirements may be categorized according to the FURPS+ model (Functional, Usability, Reliability,&#xD;
    Performance, Supportability + Constraints). For more information on this classification, see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/concepts/supporting_requirements_B2C4D610.html&quot; guid=&quot;_VXZ5wO0IEdqHTdbLTmC5IQ&quot;>Concept: Supporting Requirements&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The figure that follows illustrates the relationship among the Supporting Requirements, Use-Case Specifications, and&#xD;
    Actors.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img height=&quot;400&quot; alt=&quot;&quot; src=&quot;./../../openup/workproducts/./resources/supporting_reguirements2.gif&quot; width=&quot;600&quot; />&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-lPJDO0V2QWZo21f8J37AKA" name="glossary,_Xq_XuLjkEe2ItPaV9bHRfA" guid="-lPJDO0V2QWZo21f8J37AKA">
    <keyConsiderations>&lt;p>&#xD;
    In some projects that do not involve business or domain modeling, the Glossary is the primary artifact for capturing&#xD;
    information about the project's business domain.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Although listed as an output from, and an input to tasks associated with the requirements discipline, this artifact can&#xD;
    be updated at any time, by any role, as new terms are identified.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    The Glossary helps you avoid miscommunication by providing two essential resources:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        A central location to look for terms and abbreviations that are new to development team members&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Definitions of terms that are used in specific ways within the domain&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Definitions for the Glossary terms come from several sources, such as requirements documents, specifications, and&#xD;
    discussions with Stakeholders and domain experts.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-FamOadiVpox1vM8WorlDZQ" name="enterprise_vendor,_F9ty4bnPEe2ItPaV9bHRfA" guid="-FamOadiVpox1vM8WorlDZQ">
    <refinedDescription>&lt;p>&#xD;
    The resuable assets of enterprise are placed in this vendor for resuse in other project.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-JtBEsQIviBkr4hvuqAFLWA" name="non-compete_clause,_F9ty5LnPEe2ItPaV9bHRfA" guid="-JtBEsQIviBkr4hvuqAFLWA">
    <refinedDescription>&lt;p>&#xD;
    A&amp;nbsp;non-compete clause (often NCC) is a clause under which one party (usually an employee) agrees not to enter into&#xD;
    or start a similar profession or trade in competition against another party (usually the employer).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The use of such clauses is premised on the possibility that upon their termination or resignation, an employee might&#xD;
    begin working for a competitor or start a business, and gain competitive advantage by exploiting confidential&#xD;
    information about their former employer's operations or trade secrets, or sensitive information such as customer/client&#xD;
    lists, business practices, upcoming products, and marketing plans.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-DJI2Yl8WTpkkBQ7v6iPNGw" name="non-disclosure_agreement,_F9ty57nPEe2ItPaV9bHRfA" guid="-DJI2Yl8WTpkkBQ7v6iPNGw">
    <refinedDescription>&lt;p>&#xD;
    A non-disclosure agreement (NDA) is a legal contract or part of a contract between at least two parties that outlines&#xD;
    confidential material, knowledge, or information that the parties wish to share with one another for certain purposes,&#xD;
    but wish to restrict access to.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is a contract through which the parties agree not to disclose any information covered by the agreement. An NDA&#xD;
    creates a confidential relationship between the parties, typically to protect any type of confidential and proprietary&#xD;
    information or trade secrets&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-BnurAeQbNZNxI96j5qlARA" name="task_board,_Cy8kYLntEe2ItPaV9bHRfA" guid="-BnurAeQbNZNxI96j5qlARA">
    <refinedDescription>&lt;p>&#xD;
    The task board shows all the work the team is&amp;nbsp;doing during a sprint or daily work. It is updated&amp;nbsp;continuously&#xD;
    throughout the sprint–if someone thinks of a new task they&amp;nbsp;write a new card and puts it on the board. Either&#xD;
    during or before Daily Meeting, estimates are changed (up or down) and cards are moved around the board.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The task board might look like this:&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span class=&quot;articleImage&quot;>&lt;img style=&quot;HEIGHT: 336px; WIDTH: 461px&quot; alt=&quot;&quot; src=&quot;./../../waad/workproducts/./resources/MockedTaskBoard.jpg&quot;&#xD;
    width=&quot;600&quot; height=&quot;447&quot; />&lt;a&#xD; 
    href=&quot;http://www.mountaingoatsoftware.com/system/hidden_asset/file/29/MockedTaskBoard.jpg&quot; >&lt;u>&lt;font&#xD;
    color=&quot;#0000ff&quot;>&amp;nbsp;&lt;/font>&lt;/u>&lt;/a>&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span class=&quot;articleImage&quot;>&lt;br />&#xD;
    &amp;nbsp;&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Each row on the task board is a product backlog item (in this&amp;nbsp; particular example stories). During&#xD;
    the&amp;nbsp;planning meeting the team selects thework items they can complete during the coming sprint or day.&#xD;
    Each&amp;nbsp;work item is turned into multiple backlog&amp;nbsp;items. Each of these is represented by one task card that is&#xD;
    placed on the task board. Each task card starts on the task board in the “To Do” column. The columns are:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Story&lt;/b>–The story description (“As a user I want to…”) shown on that row.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>To Do&lt;/b>–This holds all the cards that are not done or in process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Work In Process&lt;/b>–Any card being worked on goes here. The programmer who chooses to work on it moves it over&#xD;
        when she’s ready to start the task. Often this happens during the Daily Scrum when someone says, “I’m going to work&#xD;
        on the boojum today.”&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>To Verify&lt;/b>–A lot of tasks have corresponding test task cards. So, if there’s a “Code the boojum class” card&#xD;
        there is likely one or more task cards related to testing: “Test the boojum”, “Write FitNesse tests for the&#xD;
        boojum,” “Write FitNesse fixture for the boojum,” etc. Some task cards don’t often get corresponding test cards&#xD;
        (“Fix Bug #321 in Bugzilla”) so those are placed in the “To Verify” column.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Done&lt;/b>–Cards pile up over here when they’re done. They’re removed at the end of the sprint.&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-6LkIt6PYle11e2vu62_V9A" name="project_manager,_xtPY8LnyEe2ItPaV9bHRfA" guid="-6LkIt6PYle11e2vu62_V9A"/>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-a-zCoDupitlUoys7f1A2gw" name="enterprise_vendor,_itbf0rn0Ee2ItPaV9bHRfA" guid="-a-zCoDupitlUoys7f1A2gw">
    <refinedDescription>&lt;p>&#xD;
    The resuable assets of enterprise are placed in this vendor for resuse in other project.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-X_CE4NF0oMMxJ57RvkPsmA" name="non-compete_clause,_itbf1bn0Ee2ItPaV9bHRfA" guid="-X_CE4NF0oMMxJ57RvkPsmA">
    <refinedDescription>&lt;p>&#xD;
    A&amp;nbsp;non-compete clause (often NCC) is a clause under which one party (usually an employee) agrees not to enter into&#xD;
    or start a similar profession or trade in competition against another party (usually the employer).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The use of such clauses is premised on the possibility that upon their termination or resignation, an employee might&#xD;
    begin working for a competitor or start a business, and gain competitive advantage by exploiting confidential&#xD;
    information about their former employer's operations or trade secrets, or sensitive information such as customer/client&#xD;
    lists, business practices, upcoming products, and marketing plans.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-yAp_G_j-VjMsHQZ9iwQhpg" name="non-disclosure_agreement,_itbf2Ln0Ee2ItPaV9bHRfA" guid="-yAp_G_j-VjMsHQZ9iwQhpg">
    <refinedDescription>&lt;p>&#xD;
    A non-disclosure agreement (NDA) is a legal contract or part of a contract between at least two parties that outlines&#xD;
    confidential material, knowledge, or information that the parties wish to share with one another for certain purposes,&#xD;
    but wish to restrict access to.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is a contract through which the parties agree not to disclose any information covered by the agreement. An NDA&#xD;
    creates a confidential relationship between the parties, typically to protect any type of confidential and proprietary&#xD;
    information or trade secrets&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-ys3c0l2oAPRoDeAYJGzF2Q" name="task_board,_itbf27n0Ee2ItPaV9bHRfA" guid="-ys3c0l2oAPRoDeAYJGzF2Q">
    <refinedDescription>&lt;p>&#xD;
    The task board shows all the work the team is&amp;nbsp;doing during a sprint or daily work. It is updated&amp;nbsp;continuously&#xD;
    throughout the sprint–if someone thinks of a new task they&amp;nbsp;write a new card and puts it on the board. Either&#xD;
    during or before Daily Meeting, estimates are changed (up or down) and cards are moved around the board.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The task board might look like this:&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span class=&quot;articleImage&quot;>&lt;img style=&quot;HEIGHT: 336px; WIDTH: 461px&quot; alt=&quot;&quot; src=&quot;./../../waad/workproducts/./resources/MockedTaskBoard.jpg&quot;&#xD;
    width=&quot;600&quot; height=&quot;447&quot; />&lt;a&#xD; 
    href=&quot;http://www.mountaingoatsoftware.com/system/hidden_asset/file/29/MockedTaskBoard.jpg&quot; >&lt;u>&lt;font&#xD;
    color=&quot;#0000ff&quot;>&amp;nbsp;&lt;/font>&lt;/u>&lt;/a>&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span class=&quot;articleImage&quot;>&lt;br />&#xD;
    &amp;nbsp;&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Each row on the task board is a product backlog item (in this&amp;nbsp; particular example stories). During&#xD;
    the&amp;nbsp;planning meeting the team selects thework items they can complete during the coming sprint or day.&#xD;
    Each&amp;nbsp;work item is turned into multiple backlog&amp;nbsp;items. Each of these is represented by one task card that is&#xD;
    placed on the task board. Each task card starts on the task board in the “To Do” column. The columns are:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Story&lt;/b>–The story description (“As a user I want to…”) shown on that row.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>To Do&lt;/b>–This holds all the cards that are not done or in process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Work In Process&lt;/b>–Any card being worked on goes here. The programmer who chooses to work on it moves it over&#xD;
        when she’s ready to start the task. Often this happens during the Daily Scrum when someone says, “I’m going to work&#xD;
        on the boojum today.”&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>To Verify&lt;/b>–A lot of tasks have corresponding test task cards. So, if there’s a “Code the boojum class” card&#xD;
        there is likely one or more task cards related to testing: “Test the boojum”, “Write FitNesse tests for the&#xD;
        boojum,” “Write FitNesse fixture for the boojum,” etc. Some task cards don’t often get corresponding test cards&#xD;
        (“Fix Bug #321 in Bugzilla”) so those are placed in the “To Verify” column.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Done&lt;/b>–Cards pile up over here when they’re done. They’re removed at the end of the sprint.&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-m3iqL798CR7W9dV8zTE3Gg" name="vision,_itxeFLn0Ee2ItPaV9bHRfA" guid="-m3iqL798CR7W9dV8zTE3Gg">
    <keyConsiderations>&lt;p>&#xD;
    It is good practice to keep this artifact brief, so you can release it to stakeholders as soon as possible, and to make&#xD;
    the artifact easy for stakeholders to read and understand. You can accomplish this by including only the most important&#xD;
    features and avoiding details of requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Projects that focus on product development might extend the marketing section and include a more detailed product&#xD;
    position statement that is based on their needs and research.&#xD;
&lt;/p></keyConsiderations>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-LdVLJ5g87Oy3hq9t_PdjXQ" name="work_item_pool,_ityFIbn0Ee2ItPaV9bHRfA" guid="-LdVLJ5g87Oy3hq9t_PdjXQ">
    <refinedDescription>The pool of Requirements, Bugs, Tutorials, Support, Fixed Delivery Date and Intangilble items.</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-vi9IbxjFqQu1kcefs9XSoA" name="vision,_mCq9WLn0Ee2ItPaV9bHRfA" guid="-vi9IbxjFqQu1kcefs9XSoA">
    <keyConsiderations>&lt;p>&#xD;
    It is good practice to keep this artifact brief, so you can release it to stakeholders as soon as possible, and to make&#xD;
    the artifact easy for stakeholders to read and understand. You can accomplish this by including only the most important&#xD;
    features and avoiding details of requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Projects that focus on product development might extend the marketing section and include a more detailed product&#xD;
    position statement that is based on their needs and research.&#xD;
&lt;/p></keyConsiderations>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-c3veEr5myM93B8G3FXoVHQ" name="work_item_pool,_mDHpRbn0Ee2ItPaV9bHRfA" guid="-c3veEr5myM93B8G3FXoVHQ">
    <refinedDescription>The pool of Requirements, Bugs, Tutorials, Support, Fixed Delivery Date and Intangilble items.</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
</xmi:XMI>
