Follow

Defining and Using Project Phases

Defining multiple project phases helps modeling the changing nature of development over a project timeline. For example, often teams have a ramp-up time, staff is added partway through the project, and more defects get reported in the latter phases of a project when there is more system to test. Phases help model these changes in performance and occurrence rate over time. 

To define multiple phases of a project, SimML now supports phases in the following ways:

  1. Any number of non-intersecting phases can be defined and named.
  2. Phases are defined by a start and end percentage values based on the amount of work completed out of the ORIGINAL backlog (Kanban) or the amount of work started (Scrum).
  3. Kanban: Each phase can apply its own occurrenceMultiplier and estimateMultiplier that apply globally whilst the Kanban project is simulating within that phase.
  4. Scrum: Each phase can apply its own occurrenceMultiplier, estimateMultiplier and iterationMultiplier that apply globally whilst the project is simulating within that phase.
  5. Defect, Added Scope and Blocking Events can target all, one or any combination of phases by adding a phase attribute value to their definition. For example an empty or omitted phase attribute value applies to every phase and where no phase is applied. Phases can be specified by name, and multiple can be defined by pipe separating them within the phase string value, e.g. "Phase1|Phase 3".
  6. Current phase is shown in the progress label near the top of Visualizer application window.

Defining phases:

      <setup>
           <phases>
              <phase startPercentage="0" endPercentage="20">phase1</phase>
              <phase startPercentage="26" endPercentage="75">phase2</phase>
              <phase startPercentage="80" endPercentage="100">phase3</phase>
          </phases>

 

Rules:

  • startPercentage must be less than endPercentage. These must be numeric values.
  • If multiple phases are valid for the current progress percentage, the first defined phase will apply.
  • Names must be unique and not contain < or > symbols, and be plain unicode characters.
  • If no phase is defined that covers current progress, a phase called "Default" will be displayed in the visualizer application.

Applying estimate, occurrence and iteration multipliers

To apply 20% extra to all estimates, and have events occur 20% more often during the first 20% and last 20% of a project (simulating ramp-up and ramp-down phases that are typical), the following phase definition can be used -

 

       <phases>
           <phase startPercentage="0" endPercentage="20"   occurrenceMultiplier="0.8" estimateMultiplier="1.2" />
           <phase startPercentage="21" endPercentage="80"   occurrenceMultiplier="1.0" estimateMultiplier="1.0" />
           <phase startPercentage="81" endPercentage="100"   occurrenceMultiplier="0.8" estimateMultiplier="1.2" /></phases>

 

Scrum only: You can also specify an iterationMultiplier to simulate different velocities throughout a project -

 

      <phases>
              <phase startPercentage="0" endPercentage="20" iterationMultiplier="0.8">Ramp up</phase>
              <!-- 21 to 80 will be default -->
              <phase startPercentage="80" endPercentage="100"  iterationMultiplier="0.8">Ramp down</phase>
        </phases>

 

Event Targeting Phases

To allow different event configuration to target different project phases, events can now specify what phases they target.

<defect phases="phase1|phase3" - defect only applies when phase1 OR phase3 is active.
<addedScope phases="phase3" - added scope only applies when phase 3 is active.
<blockingEvent phases="" - blocking event applies to ALL phases and when no phase is active (all the time)
<addedScope - added scope applies to ALL phases and when no phase is active (all the time)

 

0 Comments

Please sign in to leave a comment.