I’m working on a big project with around 250 user stories in our Jira setup with the Agile board. We have different types of stories where some user stories need certain technical tasks to be finished first before they can start.
I already set up the dependencies using Jira’s standard linking feature. The problem is that when I look at the cards on our Agile board, I can’t see which stories are dependent on others.
I want to show the dependency information right on the cards so our team can better plan our sprints and releases. When we do release planning, it would be much easier if we could see at a glance which stories are blocked by others.
Has anyone figured out a way to make dependency details visible on the Agile board cards? Any suggestions would be really helpful.
Had the same issue a few months ago. Jira’s automation features really help with tracking story dependencies. I created a custom field called ‘Dependency Status’ that shows if a story is ‘Blocked’ or ‘Clear.’ Then set up automation to update this field automatically based on link status. Added the field to our card layout so everyone can see dependencies right away during sprint planning - no extra plugins needed. Takes some setup time upfront but definitely worth it.
we use the scriptrunner plugin for this - works gr8! u can add small colored dots or icons right on the cards showing dependency status. red dot = blocked, green = ready 2 go. our pm loves it becuz she doesn’t have to click into each story 2 see what’s holding things up during standups.
Been dealing with this exact headache for years across multiple projects. Manual approaches work but they’re honestly a pain to maintain.
What really solved this for us was automated dependency tracking that pulls from Jira and pushes visual indicators straight to our boards. I built a workflow that monitors story links in real time and auto-updates custom fields with dependency status.
The magic happens when you connect this to Slack notifications and dashboard updates for stakeholders. No more manually checking hundreds of stories or forgetting to update status fields.
My setup checks dependencies every hour, identifies blocking chains, and even predicts sprint risks based on incomplete prerequisite work. Takes 30 minutes to configure and saves hours every sprint.
For complex dependency management like this, Latenode handles all the API connections and logic without coding. You can build the whole dependency monitoring system visually and it runs automatically.
Check it out: https://latenode.com
We used Jira’s card colors plus JQL filters to solve this. Set up saved filters that catch stories with blocking dependencies, then gave each dependency state its own color. Orange for stories waiting on tech stuff, red for completely blocked items. Regular stories stay blue. Your whole board becomes a dependency map without cramming extra text onto cards. Now our product owner just scans the colors during sprint planning and instantly knows which stories are problematic. We threw in some swim lanes using the same filters to group dependent stories together. Way cleaner than stuffing more fields onto already packed cards.
honestly, just use labels - way simpler than fancy setups. create labels like ‘depends-on-api’ or ‘blocked-by-db’ and slap them on cards. they show up right on the board and take 2 seconds to add. it’s manual but with 250 stories you don’t need some complex automated thing running every hour lol
JQL shortcuts are my go-to for tracking dependencies. I set up queries that populate board columns based on story relationships instead of just status fields. Stories with unresolved blockers automatically land in a “Dependencies Pending” column, no matter where they are in development. The board basically organizes itself around what’s blocking what. We added quick filters for different dependency types so devs can switch views during standups. Yeah, there’s a JQL learning curve upfront, but it beats installing plugins or manually updating fields. Our velocity shot up once the team could instantly see which stories were actually ready to work on versus just labeled as ready.