<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:DeliverableDescription 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" xmi:id="-Lo_rjBFuf6JDjdUw5nJjYw" name="new_deliverable,_EopWMPddEeCG79QDqBlPXg" guid="-Lo_rjBFuf6JDjdUw5nJjYw" changeDate="2012-05-30T14:26:25.810-0700" version="7.5.1">
  <mainDescription>&lt;p>&#xD;
    A release consists of integrated, compiled code that runs cleanly, independently, and in its entirety. This is an&#xD;
    important rule because in order to be released or even &quot;potentially shippable,&quot; a release increment must be able to&#xD;
    stand on its own, otherwise it is not shippable. Releases&amp;nbsp;can be created at either the program or team level.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    There are three potential uses for a release:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;strong>It is not used outside of the program:&lt;/strong> It has been produced to minimize risks linked to technology&#xD;
        and a program's capability to integrate components and to produce a Build. This situation usually happens at the&#xD;
        beginning of a new product lifecycle.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>It is used by beta customers and the program manager:&lt;/strong> It allows end users to test it in a Beta&#xD;
        test environment, which provides immediate feedback and reduces risks associated with user interface ergonomics.&#xD;
        customer feedback will influence the program backlog for later consideration.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>It is deployed or shipped and used by end users:&lt;/strong> This result provides immediate value to the end&#xD;
        users.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    In many organizations, a program release typically is timeboxed to 2 to 3 months of development effort and 2 to 4 weeks&#xD;
    of hardening which results in a scheduled release approximately every 90 days. Releases for individual development&#xD;
    teams usually occur more often than those for programs, but there are no hard and fast rules regarding how often&#xD;
    releases should be scheduled. The only requirement is that working software should be delivered &quot;frequently&quot; by both&#xD;
    development teams and programs. Although the example timeframe described above is arbitrary, empirical evidence&#xD;
    suggests it is about right for most companies and fits nicely into quarterly planning cycles.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Each release has a set of release objectives and a projected delivery date; it also has a planned number of&#xD;
    sprint/iterations. For example, a brief description of a release might be: &quot;The goal of Release 2 is to provide B2B&#xD;
    scheduling capability for the Ordering and Logistics Department. The release is targeted for June 31 and will consist&#xD;
    of five 2-week feature development sprint/iterations and&amp;nbsp;one 2-week release sprint/iteration.&quot;&#xD;
&lt;/p></mainDescription>
  <purpose>&lt;p>&#xD;
    The purpose of this work product is to:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        At the team level, bring closure to a sprint/iteration or series of sprint/iterations by delivering working, tested&#xD;
        software that can be potentially used by the end user community for whom the system was (or is being) developed&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        At the program level, deliver an integrated, value-added product increment to customers that was developed in&#xD;
        parallel by multiple, coordinated, and synchronized development team members&#xD;
    &lt;/li>&#xD;
&lt;/ul></purpose>
</org.eclipse.epf.uma:DeliverableDescription>