How to Build a Sprint From GitHub Pull Requests

Most sprint boards drift away from reality the moment a developer opens a pull request the planner forgot about. The fix is to build a sprint from pull requests directly — start from the work that actually exists in GitHub instead of inventing tickets that may never match a branch. KazTrack is GitHub-native, so your repositories and PRs are already in the workspace. This tutorial shows how to turn those open PRs into a planned, assignable, trackable sprint.

Prerequisites

• A KazTrack project with at least one connected repository.
• sprints.manage permission (owners and managers have it by default).
• A few open or recently merged pull requests to plan around.
• Team members already invited to the project so you can assign work.

Step 1: Review the pull requests you want to plan

Before creating anything, get a clear picture of the candidate PRs. Open Pull Requests in your project to see the synced list from your connected repositories. Each row shows its current workflow state, which maps to a GitHub label:

ready_for_testing → in_progress → passed → failed

Note which PRs belong in the upcoming iteration. A good sprint usually mixes work that is ready for testing with a few items still in progress, so testers and developers both have a runway.

Step 2: Create the sprint

1. Go to Sprints and click New sprint.
2. Give it a clear name and date range, for example Sprint 24 — Checkout polish running two weeks.
3. Add a short goal statement so the team knows what “done” means.
4. Save.

An empty sprint is just a container. The value comes from filling it with real PRs in the next step.

Step 3: Add pull requests as sprint items

Now bring the work in. For each PR you flagged in Step 1, add it as a sprint item:

1. Inside the sprint, choose Add item.
2. Select Pull request as the source and pick the PR from your repositories.
3. Repeat for every PR in scope.

Because KazTrack reads PRs from GitHub, each item carries its live context — the branch, the diff, and its workflow label. You are not re-typing ticket titles; you are referencing the source of truth. If a teammate force-pushes or the PR moves to failed, the sprint item reflects that.

You can also add non-PR items (a research task, a doc to write) to the same sprint when the work does not map cleanly to a single pull request.

Step 4: Assign an owner to each item

A sprint without owners is a wish list. Assign each item to the person responsible:

• Developers own the PRs they are coding.
• Testers own items that are ready_for_testing.
• Reviewers can own follow-up items spun off from a review.

Assignment respects your project’s RBAC. Anyone you assign must be a member, and what they can then do to the underlying PR — comment, change labels, record results — is governed by their role (owner, manager, tester, viewer, or a custom role).

Step 5: Set and track item status

Each sprint item has a status you move as work progresses. A typical flow:

1. To do — item is planned but untouched.
2. In progress — someone is actively working it; the linked PR is usually in_progress.
3. In review / testing — the PR is ready_for_testing and a tester picked it up.
4. Done — the PR is passed (and often merged).

Update status as the team works, or let an MCP agent do it. With a per-project token, an automation can set an item’s status when the linked PR’s label flips — keeping the board honest without manual upkeep.

Step 6: Keep the board synced with GitHub

The whole point of building a sprint from pull requests is that the two stay in lockstep. As reviewers and testers work the PRs, the workflow labels update in GitHub and sync back into KazTrack. When a tester marks a PR passed, that signal is visible on the sprint item without anyone copying a status across two tools.

Make a habit of these quick checks during standup:

• Any item stuck in in_progress for several days? It needs unblocking.
• Any PR sitting in failed? It should move back to active work, not silently stall.
• Items with no owner? Assign them before they slip.

Step 7: Close the sprint and capture carryover

At the end of the iteration:

1. Confirm which items reached Done (PR passed/merged).
2. Move unfinished items into the next sprint rather than deleting them — carryover is data, not failure.
3. Use working-time reports to see how long testing actually took per PR, which sharpens your estimates next time.

A sample carryover decision often looks like this:

Item	Linked PR	Status	Decision
Checkout button states	#318	passed	Closed
Coupon edge cases	#322	failed	Carry over, reassign
Receipt email copy	#319	in_progress	Carry over

Troubleshooting

• A PR is missing from the picker — its repository may not be connected to this project, or the sync hasn’t refreshed. Confirm the repo appears under your project’s repositories.
• You can’t create a sprint — you likely lack sprints.manage. Ask an owner or manager to grant it or to create the sprint for you.
• Status and label disagree — the sprint item status is set by your team; the workflow label comes from GitHub. They are related but independent, so reconcile them during standup.
• Assignment fails — the person isn’t a project member yet. Invite them first, then assign.

Key takeaways

Building a sprint from pull requests keeps planning anchored to the work that genuinely exists in GitHub. Create the sprint, pull in real PRs as items, assign owners, and let workflow labels sync the truth back and forth. Try it in KazTrack on your next iteration and watch your board stop drifting from your repository.