Defect States inconsistent in active sprint view in release projects Edited

[Dnyaneshwar Ramesh Borase]

Hello Team,

For the Defect issue type it have different transition state To Do/Open--Assign --Resolved--Closed Issue--Reopen Defect--Re-assign. This workflow is properly worked in Defect backlog project. But it doesn’t work when we use same workflow in release project after starting Sprint, once we planned the defect in the same sprint.

We are experiencing an issue with the Defect issue type. A Defect does not have the same states of stories and tasks so we have created a column mapping in our board to map the Resolved state of a defect to the “In Progress” state of the active sprints view.

However, the problem is that the representation of a Defect issue created within a System Release project does not seem to be consistent.  When a Defect is set to the resolved state the issue key becomes strikeout. But it shouldn’t be cause its status is not mapped to Done. If the defect is re-opened (state is moved back to TODO) then the key becomes not strikeout. When the defect is re-assigned the key becomes strikeout yet the Defect is still in the In Progress state.

In the release project we have only three state To Do--In Progress--Done & we are creating board in the project. In column management added column as shown in screenshot1

Please find attached screenshots regarding Workflow for Defect Issue type for your reference; Screenshot2 & Screenshor3

Please let me know how to resolve this problem.

Thanks in Advance!

Regards,

Swapnashilpa

[Nic Brough]

There's three key things you need to consider here, and one very important concept.  Resolution and Status are totally independent

1.  Resolution is a flag - when empty, JIRA considers the issue as needing attention.  When it is set to any value, it strikes out the issue key, and considers it "resolved"

2. Status is an indication of where the issue is in the workflow.

3. A board only considers an issue "done" when it is in the far right-hand column of the board.

So, you should re-evaluate your workflows and boards a little.  There's nothing intrinsically wrong with them, you have them mostly right, but you need to review what you're doing with resolution and positioning.  Specifically:

• Group up all your status into two sets - open and closed (by "closed", I mean "needs no further attention"). 
• All the "closed" status should be of a "green" category
• All the closed status should usually be in the right-hand column on the boards.  There are exceptions to this rule, and it can be useful to have non-closed status in the column too, but you will need to look at each one to check
• Any transition that goes from a "closed" status to a not-closed one should have a post-function for "clear resolution"
• Any transition that goes from a not-closed status to a closed one should either have a post-function that sets the resolution OR it should go through a "transition screen" that has resolution on it
• Finally, no create or edit screen should have resolution on it.  The field is only for view, and "close issue" type transitions.