How to warn if blocking tickets are not in a sprint

Question

We had a recent problem that I would have thought Jira could handle but I can't see where this would work.

We are using Jira with scrum/agile. While defining stories we had two stories one larger one that would allow some infrastructure to be made and a smaller ticket that had more apparent value that depended on it. Together they were bigger than we were happy with a story being.

In sprint planning, the business was looking to add some small stories to a sprint, saw the small one and added it. It made sense to them to add a small valuable ticket.

I would have hoped that Jira would have flagged that this wouldn't work, obviously, a ticket that depends on another can't be completed if the other ticket is not done.

Is there a way to get Jira to warn about this or not allow it?

Answer 1

I assume this dependency in jira is with a link between the issues such as "is blocked by"

A possible Solution in jira would be: Your board is fed by a filter. You can edit this filter to exclude issues blocked by items in the sprint (you may need to use advance jql functions like the ones scriprunner provides). If these issues are not in your backlog, nobody can drag them to a sprint. Nonetheless you have to list this items in a dashboard in order to resolve the blocking asap.

I agree with Todd's comment, you cannot have too many fingers in your backlog, ideally this is the only reposibility of the product owner, who would look into this kind of situations

Another thing you could do is try to avoid blockings by writing user stories using INVEST criteria

Answer 2

Some things to think about based on what I've observed from your question:

While defining stories we had two stories one larger one that would allow some infrastructure to be made and a smaller ticket that had more apparent value that depended on it. Together they were bigger than we were happy with a story being.

This stuck out to me because it indicates a need to further refine the work at hand. The development team is ultimately responsible for managing and organizing their work, thus they should be empowered to refine the work until they are comfortable with the size, effort, and plan of attack from a development approach.

In sprint planning, the business was looking to add some small stories to a sprint, saw the small one and added it. It made sense to them to add a small valuable ticket.

This is another case where this issue can be mitigated by allowing the team to manage and organize their own work. The business can obviously be a stakeholder whose priorities can and should be taken into account in the product backlog, but the sprint backlog is owned 100% by the development team. The development team members decide what gets pulled in based on the priority and shared objectives via work in the product backlog.

By making your work transparent (using a Kanban board via JIRA indicates you're already in a good place with this), you can link dependencies and work through those dependencies with your team by empowering them to reorganize their work in a way that can provide value in the form of an increment. JIRA supports flags. You can also link cards by

• Opening the card you want to link
• Clicking 'More' (...) > Link > Jira Issue
• Choosing the type of Issue
• Specifying the other card you want to link this card to (text search works here)
• Adding a comment if needed

That said, it makes sense to address the process breakdown instead of masking the issue with tooling. There are many models for properly breaking down work into manageable pieces. I concur with the INVEST model but more can be found with a simple Google search in the event one fits your needs better than another. Tooling customization can make the team issues more transparent, which should mitigate a need for automated warnings, but coaching the team and larger organization on Agile principles addresses the larger issue you've identified in your question. Good luck; hope this helps!