Engineering
The two hours before planning that nobody schedules
Carry-over, gaps and blockers assembled the day before, so the meeting is about commitment.
What the worker does
Sprint planning preparation is assembly work an AI worker can do overnight. The worker reads the tracker, the repository and the team calendar, then posts a brief listing carry-over issues with their age, issues with no estimate, work assigned to people on leave during the sprint, and items blocked on another team. The team still decides what it can commit to.
- Runs
- The day before planning
- Connections
- Linear, GitHub, Google Calendar
- Output
- A pre-planning brief
Planning meetings mostly reconstruct state
The first half hour goes on remembering why an issue carried over, discovering that three items have no estimate, and realising that the person who owns the migration is away for the first week of the sprint. By the time everyone has the same picture, the energy for the actual decision is gone.
All of that state is retrievable before anyone sits down. It just requires someone to spend an hour in four systems the evening before, and nobody volunteers for that.
What the brief contains
Four lists, each answering a question that otherwise gets asked out loud.
| List | The question it answers | Where it comes from |
|---|---|---|
| Carry-over, by age | How long has this been rolling? | Tracker issue history |
| No estimate | What are we about to commit to blind? | Tracker fields |
| Owner unavailable | Who is away while their work is scheduled? | Google Calendar |
| Blocked externally | What is waiting on another team? | Issue links and labels |
| Open pull requests | What is nearly done but not merged? | GitHub |
The parts that matter more than they look
Age, not count
Ten carry-over issues is a number. One issue that has carried over five sprints is a problem, and it only shows up if the brief reports age.
Leave against ownership
Cross-referencing the calendar against assignments catches the single most common planning failure, which is committing to work whose owner is on a plane.
Nearly-merged work
Open pull requests are the cheapest capacity in the sprint. Listing them first puts that capacity in front of the team before anyone reaches for new work.
Assembly against decision
The worker brings
- Every issue's current state and age
- The gaps in estimates and ownership
- Calendar conflicts against assignments
- The list of external blockers with links
The team decides
- What the sprint goal is
- How much the team can honestly commit to
- Which carry-over should be dropped rather than rolled
- Whether to estimate or to split
Questions people ask
+Does this work if we use Jira rather than Linear?
The connection catalog covers Linear, and Polaris itself has workstreams, lanes and a board that can hold the sprint directly. Teams on other trackers usually run the sprint in Polaris and give the worker GitHub and Google Calendar for the rest of the picture.
+Can the worker assign issues for the next sprint?
No. It delivers the brief as a comment on a task and the task stays open until a person closes it. Assignment during planning is a negotiation about capacity, and it happens with people in the room.
+How does it know who is on leave?
Through the Google Calendar connection, using whatever convention your team already uses to mark time off. Naming that convention in the worker's SKILL.md is what makes the check reliable rather than approximate.
+Is it worth running for a two-week sprint?
Most teams find the leave and estimate checks pay for themselves in the first cycle, and hours are metered per job with a five-minute floor rather than charged per seat. If a run stops being useful, you stop assigning the task and there is nothing to cancel.
Related
The engineering work that is not writing code
Five jobs that sit between an engineer and the code, and what an AI teammate does with each.
Forty new issues on Monday, half of them the same bug
Every new issue checked for duplicates, version and repro before an engineer opens it.
Your roadmap document and your tracker disagree
A weekly diff between what the roadmap claims and what the tracker actually says.
Connect Linear to Polaris
A Linear API key carries one person's visibility, so the account you make it on decides what every worker can see.
Connect Google Calendar to Polaris
Scheduling is the one thing an assistant is asked for first, and it is the one connection still waiting on Google sign-in.
What keeps running after you close the lid
The honest version: nothing on your laptop survives, so the work has to not be on your laptop.
Hire an AI project coordinator
The unglamorous half of running projects, done every week without anyone having to be the person who nags.