Jira and Bitbucket sprint delivery board

PromptCreate

Build me an internal app called Sprint Delivery Board that answers the question I ask in every standup: does the code behind this ticket actually exist yet. It joins the active sprint in Jira to pull requests in Bitbucket and shows me loudly where the two disagree.

On first load, let me pick the Jira board and then the sprint, defaulting to the active one, using Get Board Sprints. Let me pick the Bitbucket workspace and one or more repositories using List Workspaces and List Repositories in Workspace. Remember these choices per user so the board opens straight to my team's sprint next time.

The main view is a table of the sprint's issues loaded with Get Sprint Issues, with an option to supply my own JQL instead through Search Issues (JQL) when one board is not the whole picture. Columns: issue key, summary, assignee, Jira status, story points, and a delivery state badge.

Matching tickets to code is by naming convention, not by any real API link between Jira and Bitbucket, and the app copy should say that plainly rather than pretending the link is authoritative. For each configured repository, fetch pull requests once with List Pull Requests and match in memory rather than querying per issue. List Pull Requests defaults to OPEN only and caps pagelen at 50, so pass an explicit state filter through the q parameter using BBQL to cover OPEN, MERGED and DECLINED, and follow the next link to page through. Pull request states are uppercase. A pull request belongs to an issue when the issue key appears in the pull request title or in the source branch name. Match case-insensitively and respect word boundaries so that PROJ-12 never swallows PROJ-123. Also call List Branches per repository and match branch names the same way, so I can see when someone pushed a branch but never opened a pull request.

Set each row's delivery state badge from what the match found. Merged when at least one matching pull request is MERGED. In review when there is a matching OPEN pull request and nothing merged. No branch yet when nothing matches at all. When a branch matched but no pull request exists, keep the row in No branch yet and add a quiet note that a branch was pushed without a pull request.

The whole point is surfacing mismatches, so put a filter above the table with three options: everything, Done with nothing merged (the issue's status category is done but no matching pull request is MERGED), and Merged but still open (at least one matching pull request is MERGED while the issue's status category is not done). Use the Jira status category rather than status names, because every team renames their statuses. Show a count beside each mismatch option so I can see the damage before I click, and style those two states loudly in the table itself.

Clicking a row opens a side pane for that issue. Show every linked pull request with its title, state, source and destination branch, author, reviewers with their approval state, and comment count, from Get Pull Request. Under each pull request, list the commits from List Pull Request Commits with message, author and date, and show the discussion from List Pull Request Comments. Link out to both the pull request in Bitbucket and the issue in Jira.

From that pane let me act without switching tabs. Move the ticket by loading valid options with Get Transitions and applying my choice with Do Transition. Leave a note on the ticket with Add Comment, remembering the body must be Atlassian Document Format. Nudge the code review with Create Pull Request Comment on a chosen pull request. After any action, refresh that row and its pane so what I see matches what now exists.

Fetch fresh data when the board loads, with a manual refresh button and a last updated timestamp. Both APIs are rate limited, so fetch pull requests and branches once per repository per refresh, cache them for the session, and never fan out a request per issue. If a single repository fails, show a warning for that repository instead of blanking the whole board.

What does this prompt do?

Lists every ticket in your active sprint and labels each one no branch yet, in review, or merged, based on the pull requests it can find
Matches tickets to code by looking for the ticket key in pull request titles and branch names, the same convention your team already types
Opens a side pane for any ticket showing its pull requests with reviewers, comment counts, and commits, so you can see the actual work
Filters in one click to the two states that embarrass teams in sprint review: tickets marked done with nothing merged, and merged code whose ticket is still open

What do I need to use this?

A Jira account with the board and sprint your team works from
A Bitbucket account with access to the repositories your team pushes to
The habit of putting the ticket key in branch names or pull request titles, since that is how tickets get matched to code
Permission to move tickets and leave comments, if you want to use the actions as well as the reporting

How can I customize it?

Point it at a different board and sprint, or supply your own saved ticket filter when one board is not the whole picture
Add or remove the repositories it searches, which matters when one team owns several services
Change what counts as a mismatch, for example treating tickets in review as done or ignoring draft pull requests

FAQs

How does it know which pull requests belong to a ticket?

It looks for the ticket key, something like PROJ-142, in pull request titles and in branch names. Jira and Bitbucket do not keep a formal link between a ticket and its code, so this naming convention is what makes the match. If your team already puts keys in branch names, it works straight away.

What happens if nobody puts the ticket key in the branch name?

That ticket shows as no branch yet, even when work is genuinely happening. The board makes the gap visible instead of hiding it, which is usually enough to get everyone naming branches consistently within a sprint or two.

Does it work across more than one repository?

Yes. Pick the repositories your team pushes to and the board searches all of them, so a ticket that touches both a frontend and a backend repo shows both pull requests on the same row.

Can I update tickets from the board, or is it read only?

You can move a ticket to a new status, leave a comment on it, and post a comment on the pull request, all without leaving the board. Everything else is reporting.

Does it run on a schedule and send me a report?

No, this is a board you open when you need it, typically just before standup or sprint review. It pulls fresh data each time you load it, and there is a refresh button with a last updated time.

Related templates

Work your whole Terraform approval queue from one board

Every Terraform run that needs a human, across every workspace, on one board with approve, discard, and plain English plan summaries.

App

Internet scanning campaign explorer for security teams

Browse the mass-scanning campaigns running on the internet right now and see instantly whether any of them target software you actually run.

App

Bulk IP triage queue that clears your SIEM alert backlog

Paste a few hundred alert IPs, split them into scanner noise, safe business services, and real suspects, then suppress or escalate in one pass.

App

Patch prioritization board built on live exploitation data

See which vulnerabilities attackers are actively exploiting, which already have tickets, and which dangerous gaps nobody on your team has logged yet.

App

See every open Confluence action item on one board

Pull every unfinished task out of your meeting notes and project pages into one screen, sorted oldest first, and tick them off without leaving the board.