Sprint Capacity Planning: A Plan That Still Fits When the Team Changes

Thirty-two tickets and a capacity number that will not sit still

Sprint planning starts as arithmetic. Each engineer has a capacity for the two weeks, each ticket has an estimate and a priority, and every open pull request needs a reviewer who knows that part of the code. Fitting thirty-two tickets inside those limits takes an hour with the backlog. Keeping the plan honest for ten working days is the real job.

The pieces live in different places. Capacity, estimates and priority order sit on the Notion sprint page, review history and merge state in GitHub, assigned work in Asana, leave notices in Slack and support escalations in Gmail. By Wednesday someone is out, a must-fix bug has arrived, and the generated status readout in Google Drive still says a pull request merged when it did not.

Who works in the room

Each squad keeps one Kylon room. Myco is the default agent, so a note that someone is out reaches it without a mention, and questions about the readout go to Nova, which owns that check. When Myco changes the plan, it posts the changed tickets in the thread and mentions Nova, so the next readout is checked against the plan as it stands, not as it was on Monday. In this room GitHub is read-only and Asana is add-only: agents read evidence from one and add new work to the other, and only people edit or close what is already there.

Two weeks, six stages

Capacity rules and the priority order live in the room guidelines and on the sprint page, so both agents work from the same numbers. Each stage stops at a person before anything is created.

Midweek, someone is out and a bug jumps the queue

Leave rarely arrives as data. A manager writes in Slack that Leo is out from Wednesday. Myco takes that message as the source for the change and proposes a refit that removes Leo's remaining capacity and moves only his open tickets: each one goes to an engineer with room and relevant review history, or back to the backlog with a note. Nobody else's plan moves.

A must-fix bug works the other way round. Support escalates it by email, the product manager confirms it, and it goes in at the top. Myco shows exactly which low-priority tickets it displaces and why those, and the engineering manager approves before anything new reaches Asana. Teams that already work with Claude Code or Codex can add it to the room to start on the fix in the same thread. Its pull request still goes through a human review like any other.

What the checks catch

• An engineer on leave who still holds open tickets, or whose capacity was never reduced
• An allocation that puts someone over capacity after grooming raised an estimate
• A readout line that marks a pull request merged, or a ticket done, when GitHub shows otherwise
• A displaced ticket that was dropped instead of returned to the backlog with a reason
• A proposed change that would edit or close existing work in Asana, which the room guidelines do not allow

What stays with people

• Approving the allocation and reviewer list before anything is added to Asana
• Deciding whether an escalated bug is must-fix, and what it displaces
• Reviewing and merging every pull request in GitHub
• Sending the weekly readout, which Nova prepares as a Gmail draft

Integrations in this workflow

Kylon is not a project tracker or a code host, and it does not replace either. It works across the tools the team already uses and keeps the coordination for the sprint in one room.

• Asana
• GitHub
• Gmail
• Google Drive
• Notion
• Slack

• Notion holds the sprint page: capacity per engineer, estimates and the priority order
• GitHub is read-only evidence: pull requests, review history and merge state
• Asana receives each allocated ticket and review assignment as new work, added only after approval
• Google Drive keeps the generated status readouts and the team's capacity rules
• Gmail brings support escalations in and carries the weekly readout out, as a draft a person sends
• Slack is where engineers post leave, blockers and quick updates

Where to start

Pick one squad and one sprint. Connect the Notion sprint page, connect GitHub for Myco and Nova with a room guideline that keeps it read-only, and write the one rule that matters most: agents may propose allocations and reviewers, and nothing is created in Asana until the engineering manager approves.

“Every change refits only the tickets it touches, so the rest of the sprint stays where people left it.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.