u/jain_archit1986

Hey Community👋

After working with Jira for several years, I kept running into the same challenge.

Jira lets you link issues, but once a Sprint grows, it becomes surprisingly difficult to answer questions like:

• Which issues are blocked?
• What is this issue waiting on?
• If this ticket slips, what else gets impacted?
• Are there dependency chains across projects?

So I decided to build a Forge app called Linked Issue Dependency Mapper.

The goal wasn't to replace Jira—just to make linked issues easier to visualize and manage from a single place.

Linked Issue Dependency Mapper

Some of the things it supports today:

Visual dependency mapping
Cross-project linked issues
Filter and search dependencies
Export to Excel
Inline comments and @mentions

I'd genuinely love feedback from people who deal with dependencies regularly.

If you'd like to try it, there's a 30-day free trial, and I'd be happy to hear any suggestions or feature requests.

Thanks!

I recently built a Forge app after noticing something interesting.

Every Scrum team I worked with handled the end of a sprint slightly differently.

• Some moved unfinished issues to the next sprint.
• Some moved everything back to the backlog.
• Some decided on a case-by-case basis.
• Some forgot until the following Monday.

None of these approaches are necessarily wrong, but the process was always manual and inconsistent across teams.

So I built a Forge app that lets teams define those rules once and lets Jira handle the repetitive work.

Here's what it looks like.

Auto Sprint Start Stop

I'd love to know:

• How does your team handle sprint rollover?
• Is it something you've automated?
• Or is it one of those "it takes two minutes, so nobody worries about it" tasks?
• Would you like to know more about the app?

Every Scrum Team has a Definition of Done (DoD). But if your DoD had a flavor, what would it taste like?

🍯 Sweet – Clear, practical, and shared by the whole team. Work is reviewed, tested, accepted, and ready to deliver value.

🧂 Salty – A few key ingredients are missing. Maybe testing is skipped or acceptance criteria aren't fully met. It works... until the rework starts.

🍞 Bland – Too vague to be useful. "Reviewed" and "tested" sound good, but nobody agrees on what they actually mean.

🍋 Sour – So many conditions that getting a story to Done feels harder than delivering the value itself.

☕ Bitter – Imposed on the team instead of created with the team. Compliance happens, but commitment doesn't.

The best DoDs I've seen aren't perfect. They're just clear enough to build trust, quality, and predictability without slowing the team down.

If you had to describe your team's Definition of Done as a flavor, what would it be and why?

On paper, blocks / is blocked by sounds straightforward.

But in practice, once work spans multiple epics, teams, or projects, I’ve seen dependencies become surprisingly hard to keep track of.

A blocker exists… but nobody notices until delivery slips. Or the relationship is technically in Jira, but hard to surface/understand once sprint work gets busy.

Curious what people actually do in the real world:

• rely on linked issues (blocks / is blocked by)?
• dashboards/JQL?
• team conventions/process?
• spreadsheets 😅
• Marketplace tooling?
• something else?

At what point do dependencies start becoming painful (if they do)?

Genuine question for Scrum teams using Jira.

How common is it for sprint start/end timing to slip a bit in practice?

Not because of bad intent — just normal things like PTO, time zones, coordination gaps, or someone forgetting.

Do teams mostly just absorb this as operational reality, or do you have a consistent process to keep sprint timing disciplined?

Curious what happens in the real world vs what’s ideal.