Workflow Overview

Currently we have several operational workflows.  Bugs, tasks, and subtasks have simple workflows managed by JIRA.  Improvements and New Features are assigned subtasks for the standard work items required to complete feature changes or additions.

Workflow for Improvements and New Features

A New Feature or Improvement is a change to the software to add functionality (not fix a bug).  This requires basic software development steps such as design, implementation, test etc.  We manage those tasks using subtasks and those subtasks can be performed in parallel in many cases (test cases can be written before coding is done for example).   

We use agile-like processes and only perform detailed scheduling for near term work.  When a ticket is identified for near term work, appropriate subtasks are created on the ticket and assigned to team members.  The owner of the master task monitors progress and ensures work is getting done and reports progress to the team.   For significant changes that have both GUI and script changes, the subtasks below are used.   For minor changes, only the appropriate subtasks are created.   (Note:  The second level bullets below are NOT subtasks, they simply identify the type of work performed for the parent subtask.)

• Functional Design
  • Requirements
  • Interface/Behavior description
  • Test procedures
  • Key Test cases
• Implementation
  • New design needed or simple mod to existing features
  • Refactoring that would have significant pay-off
  • Write code
  • Developer QA
  • Fix Bugs
• Script Test
  • Numeric
  • Edge
  • Stress
• GUI Test
  • Validation
  • System
• Doc
  • User guide updates (specs, screenshots)
  • Spec cleanup
  • Requirement migration

You can quickly create subtasks using the Create Multiple Subtasks option in the More menu of an active ticket. Make sure "Prefix Subtasks" is enabled so the titles make sense individually.

Workflow of a Bug

The workflow of a bug is illustrated in the diagram below.  Each state in the workflow is defined below the diagram.

1. Open Here the bug gets triaged and assigned to the person who will fix it. The assignee changes the state to In Progress.
2. In Progress The assignee works on the bug, makes comments as appropriate, and tracks time using the Time Tracking feature. When finished, the assignee marks the bug as Resolved. If the Resolution is Fixed or Cannot Reproduce, the assignee assigns it to the reporter or Default, whichever is more appropriate. The Default assignee is the feature lead. If the Resolution is anything else, the assignee immediately marks the bug as Closed.
3. Resolved At this point the bug has been fixed, but needs to be verified independently. The assignee should either verify the fix, or assign it to another someone else for verification. When the fix has been verified, the assignee marks the bug as Verified.
4. Verified If more work needs to be done (such as regression testing or documentation), it should be assigned to the appropriate person, and discussion should happen in the comments section. When all extra work is done, the bug should be marked as Closed.
5. Closed All work is done on this bug.

Workflow of Tasks and Subtasks

Tasks and subtasks use the simplified workflow shown below.