Nine Jira apps
Delivery rules with teeth.
A workflow document cannot stop an incomplete ticket moving forward. We built nine Jira apps to bring readiness, estimation, dependencies and delivery history into the working board.
- 9Focused Jira apps
Readiness, commits, spillover, sprint health, retrospectives, points, dependencies, bulk editing and transition auditing.
- 10Recent sprints in the health view
Velocity, carry-over and completion across the ten most recent sprints.
- Per issueBulk edit results
Failures and successes are reported separately.
- DefineChoose the delivery rule or question.
- ReadUse issue fields, links, sprint membership and changelogs.
- ActShow the finding or enforce the configured transition.
- ExplainKeep the missing requirement or recorded change visible.
The problem
A board can look orderly while its numbers tell the wrong story. Parent and child estimates get counted together. Work carries between sprints without an explanation. Missing acceptance criteria become a conversation after development has started. A dashboard cannot repair those habits if the rules live somewhere nobody has to look.
We approached this as a set of specific problems. Some need an enforced gate. Some need an audit trail. Others need a clearer view of existing data. Giving each problem an appropriate tool avoids turning every delivery decision into another mandatory form.
Who it’s for
Jira administrators, delivery leads and engineering teams that need clearer gates and more useful sprint reporting.
What we built
Ready Check evaluates required description sections, fields and estimation rules and can block a configured workflow transition. CommitGuard checks branch and commit conventions, reports violations on the issue and offers a pattern tester before rules are saved. Point Health finds missing estimates, off-scale values and points counted on both parents and children.
Sprint Spillover records carry-over and re-estimation. Sprint Health Dashboard shows velocity, carry-over and completion across recent sprints. Retro Automation prepares summaries from sprint data, including repeated carry-over, completed work and changes in velocity. Each view keeps the underlying issue history in reach.
Dependency Mapper builds a graph of linked issues and flags circular dependencies or blockers stuck in an early status. Bulk Field Editor applies selected field changes to a JQL result set with a result for each issue. Workflow Transition Auditor examines time in status, backward moves and skipped steps.
How it works
The apps run on Atlassian Forge and appear as Jira pages, dashboard gadgets and issue panels where appropriate. Configuration and cached summaries live with the app. Issue events keep relevant checks up to date, while scheduled scans support project-wide reporting.
Permissions follow the job. The dependency map and sprint-health reporting read work without changing issues. Tools that update estimates or fields need write access. Ready Check must be attached to the relevant workflow transition before it can enforce a gate; installing an app alone does not change a workflow.
The suite remains in the lab. We have deployed and installed the apps on our Jira site, while public Marketplace distribution remains unfinished. That gives us a working environment for developing the tools before a wider release.
What was hard
Delivery data has assumptions hidden inside it. Story-point fields differ by site. Status names do not always mean the same thing. The current transition auditor uses our workflow order and ignores names outside it, so adapting it to another organisation requires an explicit mapping rather than an unsupported claim of universal compatibility.
The first parallel deployments also exposed a shared manifest error across five apps. Fixing that established the difference between a recognisable app name and a valid execution environment. The broader lesson is practical: deployment, configuration, permissions and distribution all have to work before a useful feature becomes a product.