Problem
Devs do not easily see, if an item in our backlog is blocked by another item. They have to click/open the item details to see it.
Optionally, we could add "Linked Issues" to the Backlog Card Layout, but then we would see all linked items, not just the "blocked by" items. And when a blocker item is done, the blocked by item would still show the linked issue. using the impediment flag makes the board ugly when a lot of future items are flagged. Using a separate item status would make it hard to differentiate and manage items (is it ready but blocked, is it blocked but not refined yet, was is blocked and is ready now, ...)
What we needed
Something which indicates if an item is (still) blocked (by another item).
An item can be "ready for dev" after refinement, but might be blocked by another item.
e.g. Team 1 needs to complete a work (API, config change, design, final marketing text, ...) before Team 2 can start
Note
Our working mode is a mix of XP, Scrum and Lean/Kanban, where the PO prioritizes items within the product backlog, + refinement meetings, where the Devs move the next "ready" and "unblocked" item into the sprint/iteration backlog (without a sprint planning).
My solution
Result
It works and the devs are happy
Question
Do you know any other solutions for this specific issue? How do you handle this?
I guess a standard Jira indicator would be a great enhancement to replace my solution.
Hi @Andreas Safar ,
Your solution is one of the best. Another option is to introduce a new status Blocked in the workflow, add a separate column on the Scrum board and ask engineering to set the Blocked status when needed as well.
As an alternative visualization and sprint health check, I can suggest the app I developed - Multi-team Metrics & Retrospective. But it's worth using if you need to track several metrics/sprint health itself.
Best regards,
Alexey
Hi Alexey,
we used the item status before (someone it was obvious) but we had the following issue:
When the item is not blocked anymore, it was not clear which status to select next. Was/is it ready for refinement or even ready for development? Or is still some qualification work needed? So a combination of an item status and a "blocked" state was more helpful in our case.
Do you know, if the app supports this?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Andreas Safar ,
Great, the important thing is that it suits your case.
Regarding the app - are you asking if the app supports visualizing all the blocked work-items based on a custom field? If so, the answer is yes. The app can visualize any custom metric via JQL. Also, the columns of the table on the screenshot above are customizable, you can display any columns you want. Additionally, you can conduct in-place retrospectives in the same view (here is a bit more about it).
Best regards,
Alexey
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you are fine to explore a mktplace app to view Issues based on Issue Links, I can suggest our app
The app also allows you to view your project issue hierarchy in a tree view. The hierarchy is created based on your issue inks.You can view %complete progress at each parent level. It roll ups the time tracking fields, story point or numeric fields at each parent level. The app can be added to a dashboard as well
Disclaimer : I am one of the app team member
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I like it!
An idea: maybe if you also "flagged" the work item in the automation rule, it would make the "blocked" state even more intuitive.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Aron,
I agree. Using the "flagged" feature can be definitely used to mark an item as blocked.
In our case, we have a lot of dependencies between the items, which would set many items within the backlog as "flagged". Technically this is fine, but our developers really did not like to have so many items colored within the backlog (because of to the "flagged" setting). It was hard to read/look at the backlog.
Plus, in our case the "flagged" feature is used also for other cases. So without knowing the context, it was not clear why an item is flagged.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Andreas Safar,
If you're open to solutions from the Atlassian Marketplace, you may want to have a look at the app that my team and I are working on: JXL for Jira.
JXL is a full-fledged spreadsheet/table view for your issues that allows viewing, inline-editing, sorting, and filtering by all your issue fields - including an issue's issue links - much like you’d do in e.g. Excel or Google Sheets. In many cases, you can configure how exactly these fields should be displayed - e.g., for the issue links column, you can choose the exact issue link types you want to see.
This is how it looks in action:
Here, I've added two issue links columns: One to show all issue links, and one to only show "blocks" issue links. This is really just an example; you have full control over which issue link types you want to show.
I should also add that JXL can do much more than the above: From support for configurable issue hierarchies, to issue grouping by any issue field(s), sum-ups, or conditional formatting. Of course, you can always export your data to XSLX (i.e, Excel or Google Sheets) or CSV in just one click.
Any questions just let me know,
Best,
Hannes
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.