# See which sprint tickets actually have code behind them

> A board that matches every Jira ticket in your active sprint to its Bitbucket pull requests, so you catch the ones with no code before sprint review.

- Workflow type: app
- Services: Bitbucket, Jira
- Categories: Engineering, Product
- Published: 2026-08-14

## What it does

- 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 you'll need

- 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

## Prompt

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.

## How to customize

- 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

## FAQ

### 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.

Use this prompt in General Input: https://www.generalinput.com/prompts/see-which-sprint-tickets-actually-have-code-behind-them