Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Navigate to 
    Jira Legacy
    showSummaryfalse
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyREQ-1
  2. Select More==>Clone++
  3. Follow the steps in the dialog to clone the issue in the same project (i.e., REQ).  Make sure that the checkbox, "copy issues in epic" is selected.
  4. Modify the "epic name" and "description" fields for your requirement.
  5. Set the "Fix Version" field to the release name for which the use case is intended (e.g., "Frankfurt")
  6. Set the "Assignee" field to the requirement owner.
  7. If the requirement has other requirements or tasks as dependencies, add the requirements in the "Issues in Epic" field.
  8. Add a link to the JIRA issue in the appropriate column of the table on the release requirements page.
  9. Once the TSC has determined the priority for the requirement (0 - 4), set the value in the "TSC Priority" field.
  10. The template includes three sub-tasks for the TSC approvals at MS1, MS3, and MS4.  As these approvals are achieved, add a comment to the sub-task with a link to the approval documentation and mark the task as done.

Structure and Organization of Related Issues

The purpose of the Release Requirements (REQ) JIRA project is to create a single point from which all issues related to a particular release requirement may be found.  This association is nicely accomplished using the JIRA linking capability.  We will use two links, in particular:  1) "is blocked by"; and 2) "is related to".  Notice that we do not use "blocks".  This is because we want the REQ issue to be at the root of a network of related issues.  The REQ issue served an administrative function by creating a single connecting point for the network, while all of the other issues fill in the user story, features, tasks, and bugs.  

Gliffy
size1200
nameissue organization
pagePin2