Scrum Template sample project: Workflows

Helix ALM includes workflows that can be configured to match the way your team works. Each item type has a workflow. In the Scrum Template project, the team configured a basic workflow for each item type to match their straightforward development process.

Epics

The team developed a simple workflow to manage epics from concept through development and release. The workflow has four states (represented by squares) and a few events (represented by arrows) to move epics between states.

State	Description
Draft	All epics start in this state.
Approved	After the epic is fully developed and broken into stories and tasks, it moves to this state and is ready to be scheduled for a sprint or release. If priorities change after the epic is approved, it can move to the Backlog state.
Implemented	When all related stories and tasks are complete and the epic meets the team’s criteria for ‘Done’, it moves to this state.
Backlog	If priorities change after the epic is approved, it can move to this state before implementation. It can move back to the Approved state when it ready to be worked on again.

User Stories

The team developed a simple workflow to keep user stories moving through the development process. The workflow consists of five states (represented by squares) and a few events (represented by arrows) to move user stories between states.

State	Description
Open	User stories and tasks share a workflow and start in this state.
New Story	When a new user story is added, an automation rule automatically moves it to this state.
In Progress	When work starts on the user story, it moves to this state. Test cases can be generated from user stories in this state.
Blocked	If the user story cannot be worked on, it moves to this state until the blockage is cleared.
Done	When the user story meets the team’s criteria for ‘Done’, it moves to this state. Test cases can be generated from user stories in this state.

Tasks

The team developed a simple workflow to keep tasks moving through the development process. The workflow consists of five states (represented by squares) and a few events (represented by arrows) to move tasks between states.

State	Description
Open	User stories and tasks share a workflow and start in this state.
New Task	When a new user story is added, an automation rule automatically moves the task to this state.
In Progress	When work starts on the task, it moves to this state. Test cases can be generated from tasks in this state.
Blocked	If the task cannot be worked on, it moves to this state until the blockage is cleared.
Done	When the task meets the team’s criteria for ‘Done’, it moves to this state. Test cases can be generated from tasks in this state.

Test Cases

The team uses the workflow to segregate test cases based on if they are in development, ready to test, or no longer relevant. This ensures the team is not using incomplete or out of date test cases during testing. The workflow consists of three states (represented by squares) and a few events (represented by arrows) to move test cases between states.

State	Description
Draft	All test cases start in this state.
Ready	When the test case is complete and ready to use in testing, it moves to this state. Manual test runs can be generated from test cases in this state.
Obsolete	Test cases that no longer apply to the tested application move to this state. This ensures that the team does not waste time generating tests from out-of-date test cases.

Manual Test Runs

The team tracks and reports on testing progress using a simple pass/fail workflow. The workflow has four active states (represented by squares) and a few events (represented by arrows) to move manual test runs between states.

State	Description
Ready	All manual test runs start in this state.
Passed	After a manual test run is executed and results are determined, it moves to this state or Failed based on the results.
Failed	After a manual test run is executed and results are determined, it moves to this state or Passed based on the results.
On Hold	If a manual test run cannot be executed for some reason, it moves to this state until the blockage is cleared.

Defects

The team starts managing new defects with a simple yes/no decision in the workflow. New defects are reviewed and then either accepted or rejected. The processes of fixing and verifying are also split out to ensure the right people are performing each activity with metrics that show how each part of the process is working. The workflow has five active states (represented by squares) and a few events (represented by arrows) to move defects between states.

State	Description
New Defect	All new defects start in this state.
Accepted	Each defect is reviewed and, if a fix is needed, it moves to this state.
Fixed	After the defect is fixed, it moves to this state.
Resolved	After the defect fix is verified, it moves to this state.
Closed	Each defect is reviewed and, if a fix is not needed, it moves to this state.