Every engineering team tracks blocked work. So why do developers still have to ask, "Can I start

[#1]

After spending the last few months building on Forge, one workflow kept bothering me.

Not planning.

Not estimation.

Not prioritization.

Blocked work.

Jira makes it easy to link issues using Blocks / is blocked by relationships.

But once an issue becomes blocked, something surprisingly manual happens.

The developer waits.

Not because the dependency isn't finished.

Because they don't know when it becomes finished.

And that's where teams quietly lose engineering time.

---

The hidden "waiting tax"

Imagine this scenario.

Story: Build Checkout UI

Blocked by:
✅ Backend API
✅ Database Migration
✅ Security Review
⬜ UX Approval

The developer moves on to another task.

Hours later...

The UX review is completed.

The Story is technically ready to begin.

But nobody tells the developer.

Instead, one of these things usually happens:

• They keep opening the blocker issue throughout the day.

• They ask a teammate, "Is it done yet?"

• They watch the blocker and receive dozens of notifications that don't require action.

• They only discover it's ready during stand-up or while reviewing the board later.

The dependency was resolved.

The waiting wasn't.

---

Small interruptions become expensive

A single dependency doesn't seem like a problem.

Now imagine this across:

• 30 developers

• hundreds of linked issues

• multiple teams

• several projects

• every sprint

Developers spend time checking Jira instead of writing code.

Engineering managers wonder why blocked work remains idle.

Jira administrators build increasingly complex Automation rules.

Slack fills with status updates that nobody enjoys sending.

Not because anyone is doing something wrong.

Because the workflow depends on humans remembering to check.

---

We all try the same workarounds...

👀 Become a Watcher

Now developers receive notifications for:

• comments

• estimates

• description changes

• labels

• priorities

• every workflow transition

The one notification they actually care about gets buried with everything else.

---

⚙️ Build Jira Automation

This works...

Until dependencies become more realistic.

What if an issue has four blockers?

What if blockers span multiple projects?

What if workflows differ between teams?

What starts as one Automation rule gradually becomes another system Jira administrators have to maintain.

And every dependency check consumes native Jira Automation executions that could be used for business workflows instead.

---

So I asked myself...

What if Jira simply told you one thing?

"Your issue is now ready to work on."

Not twenty updates.

Not another email.

Not another Slack message.

Just one notification.

At exactly the moment every blocker has been resolved.

---

That's why we built Unblocked: Blocker Resolved Notifications for Jira.

Instead of asking developers to monitor dependencies, Unblocked continuously evaluates linked blocker issues and notifies the assignee only when work is genuinely ready to continue.

Some scenarios where this has been especially useful:

✅ Stories waiting on multiple development teams

✅ QA waiting for engineering fixes

✅ Cross-project dependencies

✅ Release readiness

✅ Infrastructure or security approvals

✅ Large programs where work spans several Jira projects

One notification.

One decision.

Zero manual dependency checking.

---

An unexpected benefit

Because Unblocked evaluates dependencies using Forge instead of Jira Automation, organizations also preserve native Jira Automation executions for the workflows that truly need them.

That wasn't the original goal.

It became a valuable side effect.

---

I'd love your perspective

I'm curious how other Jira admins and Marketplace partners handle blocked work today.

• Do developers watch blocker issues?

• Have you built custom Automation rules?

• Do you rely on Slack messages?

• Or have you found a better approach?

I'd genuinely love to learn how others are solving this problem.

Vendor disclosure: I'm from development team of Unblocked, a Forge app for Jira. I'm sharing this because it's a workflow challenge I've consistently observed while working with Jira teams, and I'm interested in hearing how others approach dependency management.

[MeghnaP_LogicLemur Labs]

One thing I'm still curious about:

How many Jira admins are solving dependency notifications with Automation today versus relying on Watchers or Slack?

I'd love to hear what has worked (or not worked) for your teams. You may check also check Unblocked: Blocker Resolved Notifications for Jira on marketplace. 

[MeghnaP_LogicLemur Labs]

One interesting scenario I didn't include in the post is how often QA gets blocked waiting for multiple bug fixes before testing can begin.

The challenge isn't knowing that an issue is blocked. It's knowing exactly when it's no longer blocked.

While building Unblocked, I found that evaluating dependencies wasn't the difficult part. The tricky bit was making sure a notification was sent only after every blocker had been resolved, especially when blockers span multiple projects, while saving the Jira automation limits for critical business flows. 

I'm curious how others are handling this today. Are you relying on Jira Automation, Watchers, or have you found another approach that scales well for multi-dependency workflows?