Defect States inconsistent in active sprint view in release projects Edited

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 screenshotsScreenshot1.jpgScreenshot2.jpgScreenshot3.jpg 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

 

1 comment

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.

Comment

Log in or Sign up to comment
Community showcase
Published Apr 22, 2018 in Jira Software

How-to setup a secured Jira Software 7.9.0 on Ubuntu 16.04.4 in less than 30 minutes

...PermissionsStartOnly=true User=www-data Group=www-data ExecStart=/opt/jira/bin/startup.sh ExecStop=/opt/jira/bin/shutdown.sh TimeoutStartSec=120 TimeoutStopSec=600 PrivateTmp=true [Install] WantedBy...

1,491 views 10 12
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you