In GreenHopper 6.1.2 for both Kanban and Scrum issues, the concept of blocked appears to be implemented as a value for priority ("Blocker"). This seems like a mismatch since something that was high priority before being blocked is probably still high priority, but to convey the message that it is blocked, I've got to give up it's actual priority and use that field to convey the state that it is in. When it becomes unblocked, I apparently need to dig through the change history of the issue to recall the actual priority -- clunky.
A better approach (in my opinion) would be to add a state for Blocked and slide the issue into that state while maintaining it's actual priority.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
In this post you will discover more about the evolution of K15t software, some big topics they're currently focusing on in the app space, and a rare (not not funny!) photo of founders Mike Cannon-Bro...
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!
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