Sprint planning agenda collected before the session starts
Sprint planning runs long for one reason: the discussion that should have happened beforehand happens in the room. Dependencies get discovered live, an absent person turns out to be the only one who can answer, and the session overruns.
Agendair front-loads that. Anyone on the team can submit a planning item during the sprint — a dependency, an unclear requirement, a piece of tech debt worth arguing for. Each row names the people whose input the item needs, so the program email makes attendance requirements explicit before planning starts.
Commitments then get written back into the same sheet with an owner and status, giving you a plain-text record of what the team took on each sprint that anyone can read without opening the tracker.
What sits in a sprint planning agenda
| Row in the sheet | How Agendair handles it |
|---|---|
| Carry-over from the previous sprint | Open rows appear automatically at the top. |
| Candidate items and their dependencies | Submitted during the sprint, not invented in the room. |
| Unclear requirements needing product input | Product owner tagged as a required participant. |
| Tech debt and reliability work | A standing row so it competes on equal footing. |
| Capacity, leave and on-call | Pasted in before the session by whoever owns the rota. |
The same sheet records what the sprint planning decided.
| Decision | Owner | Status |
|---|---|---|
| Take the migration in two sprints rather than one | Tech lead | Closed |
| Drop the admin filter work to protect the launch | Product owner | Closed |
| Spike the search rewrite before committing | Engineer | New |
Closed rows fold out of the default view but are never deleted. The agenda is the register — there is no second document to keep in sync.
Build this kit — $39 once