You are on page 1of 9

Jira CR Workflow

Jira CR process
Suggestion
Backlog

A new CR has been created. The CCB will evaluate the CR to see if it valid. If it is valid it will be placed into the backlog to be implemented in a future release.

If the CR is chosen for release it is evaluated by Comeon tech for technical reliability and if needed More requirement info is added.

Backlog
Open Return to Backlog

A release or sprint meeting has been held and the CR has beem moved to the current release for Implementation. It has been assigned to a developer.

Open
Start Progress Start Progress Stop Progress

The developer has started to work on the issue. If work cannot continue then the issue must be placed In the Open state again.

In-Progess Reopened
Resolve

Resolved
Close Re-open

The developer has finished the implementation. The issue is now ready for Test. Once Test has verified It then the issue can be closed, if the issue is not OK then it shall be moved to Reopened.

Once testing is complete the issue is closed.

Closed

'Suggestion' State

This is the first state of the CR. The CR will be viewed by ComeOn business and ComeOn tech.

The CR will be evaluated, if it is valid it will be prioritized and a best guess time estimation on how long it will take to implement will be noted in the issue. Once the time estimate is complete the CR will be moved to the Backlog state and the assignee will be unassigned.

If the CR is not valid it will be moved to resolved state with the resolution not valid or equivalent.

'Backlog' state

CCB Business/Tech analyse the time estimate and decide whether it can be done in the current release or not.

If the CR is scheduled for the next release it shall be assigned to the developer and the release version set.

If the CR is a large CR in terms of complexity and more information is needed regarding requirements then a subtask can be created, and shall be assigned to 'Requirement Specifier' or assigned to business. If the CR needs to be broken down and assigned to several developers then subtasks can be created and assigned to those individuals. The CR shall be moved to the Open State.

If the CR is not chosen for the release it simply stays in the backlog awaiting to be implemented in a future release.

'Open' State

The CR is now assigned to the developer awaiting to be implemented in the current release. When the developer starts working on the issue then he moves it to the 'In-Progress' state. If the Issue cannot be done in the current release then the issue shall be moved to backlog with comments added.

'In-Progress' state

The state 'In-Progress' means that the assignee has started working on the issue. The issue shall stay in this state until the issue is implemented.

If work cannot continue on the issue for whatever reason then the issue shall be moved back to the 'Open' state via the 'Stop Progress' transition. A comment shall be added.

Once the developer has verified the implementation it can then be set to 'Resolved', and the resolution set to 'Fixed'.

'Resolved' state

When the issue is in this state then the Test department verifies the implementation. If the implementation is correct then the issue shall be moved to closed. If the issue has not been implemented correct then the issue shall be moved to 'Re-opened' state and assigned back to the developer.

'Re-Opened' state

This state is used to identify that the issue has been incorrectly implemented or is not fully complete. The issue shall remain in this state until the developer can implement and fix the problem. Once work has started on the issue again then the issue shall be moved to the In-Progress state via the 'Start Progress' transition.

'Closed' state

This state is used to identify that the issue is now closed. The software in which the issue is implemented can now be shipped to production.