My organization recently moved from tracking external requests in Jira as DSTs to using dependencies in Jira Align. We have an extensive review and prioritization process requests we get and it can take sometimes months to move to COMMIT status. With DSTs in Jira, we used labels to track and monitor the status of the requests as we conducted our internal review. However, it appears that Jira Align allows no such method of triaging or groping dependencies. Our backlog can often have over 100 requests, so currently Jira align seems to offer no way of organizing this mass of non committed dependencies.
I thought that we might be able to export the "Chats" associated with the Dependencies, but the resulting CSV file does not include this field despite changing the displayed columns on the dependency page.
The exported CSV file does allow the user to capture the reason why a dependency is blocked, but our organization would not prefer us to block all dependencies in our pre review.
Anyone have any advice? I was hoping that Jira Align would make our lives easier, but this inability to track dependencies at a granular level is resulting in a lot of disruption in our organization.
Will it help to filter the requests in the dependency grid by status? Start with the ones Not Committed and then move to Proposed and also Blocked. You could also review those that have No Work selected to have the teams discuss that scenario as well.
Dependencies now supported in API 2.0
We’ve added an endpoint for dependencies in the API 2.0. This enables you to create, read, update, and delete dependencies. API details are available in swagger, and documentation on using API 2.0 can be found here.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm not clear on what types of label values you are using in Jira, so it's kind of difficult to recommend a solution in Align.
You could probably use the comments as you describe and create the required export file using Jira Aligns API.. My bad ...dependency API is not released yet.
A pretty elaborate hack might be to make use of custom rooms. Each work item at the required level would need to use a field to indicate one or more rooms that the it's associated dependencies should appear in. Whomever is managing those dependencies would periodically open the room and status/etc. the Dependencies. The downfall of this approach is that all dependencies for the work item will show up in any room to which they are "tagged". Some pics below:
--------------
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.