What is a meeting agenda?
A meeting agenda is a list of items, each carrying a verb, an expected outcome and a time box. Not a list of topics — a list of results. A topic answers "what is this about"; an agenda answers "what do we have to walk out with". A meeting missing that second answer ends with "well, we talked it through" and a new invitation.
Three documents sit next to the agenda and get confused with it constantly.
| Document | What's in it | When you need it |
|---|---|---|
| Agenda | Items with a verb, an outcome type and a time box | Any meeting over 15 minutes, or with more than three people in it |
| Topic | One line in the calendar invitation | A short sync between two people where the subject is obvious to both |
| Itinerary | Blocks with clock times, breaks, room changes | Anything longer than three hours: an offsite, a strategy day, a multi-session workshop |
| Minutes | What was decided, who owns it, by when | After the meeting. Written against the same structure as the agenda |
An agenda does three things. It filters people out: seeing the items, someone realises they have nothing to contribute, and that saves them an hour. It sets a boundary — when an adjacent topic surfaces there's something to point at to bring the conversation back. And it forces preparation, not from the attendees but from the author: if you can't draft the agenda in five minutes, the meeting probably isn't needed.
What does a good agenda item look like?
An item isn't a topic, it's a question with an expected outcome. The full form answers four things: what we're doing, what has to come out of it, how long it takes, and who leads that item.
1. Budget
2. Timeline
3. AOB
1. Sign off the phase-two budget — decision, 15 min, Igor
2. Pick a release date from the two options — decision, 10 min, Anna
3. Integration risks — information, 5 min, Lena
"Budget" doesn't say what to do with it: approve it, debate it, or hear a status. People arrive with different expectations and spend the first ten minutes working out why they're there. In the second version every item has a verb, an outcome type, a time box and an owner — and you can see immediately that item three needs no decision, so there's no reason to get stuck on it.
Three types of outcome
- Decision. A choice has to be made between options. Requires someone in the room with the authority to make it — otherwise the item is doomed before it starts.
- Information. Everyone needs to learn the same thing at the same time. The most frequent candidate for replacement by a message.
- Working through. Something nobody understands end to end has to be understood together. The only type that transfers badly to writing.
The outcome type isn't decoration, it's a time-management tool. Information items compress almost losslessly; working-through items don't compress at all. Halve one and you don't get half a result — you get zero, plus a shared sense that the topic has "already been covered".
Which items earn a place on the agenda?
An agenda starts with elimination, not with a list. The test is a single question: what happens if this item is never discussed out loud?
| Criterion | The item stays | The item comes off |
|---|---|---|
| Does it need dialogue | Positions differ, and in writing they'd fan out into ten threads | The information reads the same to everyone — a channel post covers it |
| Is the authority present | The person who can say yes will be in the room | The decision will go for approval to someone who wasn't invited anyway |
| Is the data ready | The numbers are gathered and circulated in advance | No data — the meeting becomes an exercise in assigning someone to collect it |
| How many people it touches | It affects most of the invitees | It affects two of them — fifteen minutes for those two is cheaper than an hour for eight |
| Does it fit the time | It fits its slot whole | It doesn't — so it becomes its own meeting rather than getting squeezed |
If every item on the agenda could be closed with a message in a channel, send the message. A meeting is for putting positions against each other, deciding under disagreement, or working through something that would fan out into ten threads in writing.
What is a skeleton agenda?
A skeleton agenda is a stripped-down draft holding only the standing items and empty slots for everything else. You circulate it a day or two ahead so that attendees fill in their own items and you can see the real volume before the meeting starts rather than during it.
It solves a narrow but expensive problem: an agenda invented by one person always reflects what worries that person. The items that worry everybody else surface under "any other business" at minute forty-five — and routinely turn out to matter more than anything that was planned.
# [Meeting], [date], [time], [duration] Purpose: [one sentence — what has to be different by the end] ## Standing items 1. What closed since last time — information, 5 min 2. Decisions we have to make today — decision, [N] min ## Propose an item Add a line below by [date, time]: wording with a verb | outcome (decision / information / working through) | minutes | who leads - - ## Read beforehand - [link]
How do people submit agenda items?
Collecting items is a procedure, not a polite "let me know if you have anything". It has three parameters, and all three have to be stated up front.
The deadline. Twenty-four hours before a recurring call, forty-eight when data has to be prepared. After that the agenda freezes. The point of the cut-off isn't discipline for its own sake — it's that attendees need time to read the final version.
The form. A line in the same shape as every other item: verb, outcome, minutes, owner. A submission reading "discuss warehouse logistics" goes back to its author for rewording — not on principle, but because there's no way to judge whether it fits inside the hour.
The filter. One person screens, and it's whoever chairs. They don't rule on whether an item is important; they run it against the criteria table above and answer the author one of three ways: on the agenda, its own meeting, or closed with a message. Silence in response to a submission is the fastest way to teach people to stop sending them.
Late items don't disappear — they roll into the next agenda automatically. The exception is anything that expires before then: that item goes in, but something else comes off to make room. Never "let's try to fit it in".
Six formats for different kinds of call
The skeleton depends on the type of meeting: a status call and an incident review have entirely different time logic. The table shows how the formats differ; below it are the full agendas, ready to take.
| Format | Skeleton | Timing |
|---|---|---|
| Status | Closed → in flight → blockers → what we take offline | 20 min, hard stop. Solving anything inside it means the format has broken |
| Planning | Constraints → what's in → what's out → risks → owners | 60 min, half of it spent on the two middle items |
| Retro | Check last time → what worked → what got in the way → what changes | 45 min, 15 of them on the obstacles — not compressible |
| Interview | Context → a real case → a practical task → candidate's questions | 60 min, two 20-minute blocks — otherwise candidates aren't comparable |
| Customer call | How it works now → where it breaks → what they tried → next step | 40 min, no demo before item two |
| Incident review | Timeline → what we saw → why we missed it → what we fix | 50 min, the first 15 are timestamped facts only |
The goal is synchronisation, not discussion. The main risk is that it turns into an hour of planning. Keep the timing strict and take anything contested to a separate meeting.
# Status: [area], [date] 1. What closed since last time — information, 5 min 2. What's in flight and where it's stuck — information, 8 min 3. What's blocking and whose help is needed — decision, 5 min 4. What we take to a separate meeting — decision, 2 min Out of scope: how exactly to solve the problem. Only the fact of the blocker and its owner.
The goal is a plan everyone signs up to. The commonest mistake is starting from tasks instead of constraints. Fix the frame first, fill it afterwards.
# Planning: [period], [date] 1. Constraints: dates, people, budget — information, 10 min 2. What must be in, and why — decision, 15 min 3. What's out, and what happens to it — decision, 15 min 4. Risks and the points where the plan breaks — working through, 15 min 5. Who owns each block — decision, 5 min Before the meeting: the list of candidates for inclusion is circulated.
The goal is to change the process, not to vent. A retro without "what changes and who owns it" turns into a ritual: the same complaints, iteration after iteration.
# Retro: [iteration], [date] 1. What we're checking from the last retro — information, 5 min 2. What worked and why — information, 10 min 3. What got in the way: facts, not judgements about people — working through, 15 min 4. What we change in the process — decision, 10 min 5. One experiment before the next retro: who, what, success criterion — decision, 5 min Rule: no more than one process change per iteration. Otherwise you can't tell which one worked.
The goal is comparable data about the candidate. A free conversation is more pleasant, but two candidates assessed that way can't be compared afterwards.
# Interview: [role], [candidate], [date] 1. Context: the role and how the work is set up — information, 5 min 2. A real case from the candidate's experience — working through, 20 min 3. A practical task matching the role — working through, 20 min 4. The candidate's questions — information, 10 min 5. Next step and when they'll hear back — decision, 5 min The same blocks for every candidate for the role — otherwise the comparison degenerates into an argument about impressions.
The goal is to find out whether there's a problem you solve, and who at the customer can say yes. Presenting the product before that is time spent by both sides.
# Meeting: [company], [date] 1. How the process works today — information, 10 min 2. Where it breaks and what that costs — working through, 10 min 3. What they've tried and why it didn't fit — information, 5 min 4. What a solution looks like from their side — working through, 10 min 5. Who's involved in the decision and what the next step is — decision, 5 min Product demo: only after item two, and only the part that relates to the breakage they named.
The goal is to reconstruct the sequence of events and find the cause in the process, not a person to blame. The moment the conversation turns to blame, facts stop surfacing.
# Incident review: [what happened], [date]
1. Minute-by-minute timeline: what and when — information, 15 min
2. What we saw and when we understood it — working through, 10 min
3. Why we didn't notice sooner — working through, 10 min
4. What fixes the cause rather than the symptom — decision, 10 min
5. Owners and dates — decision, 5 min
Replace statements about people ("didn't check") with statements about
the process ("there was no check at this step").
How do you set the timings?
The practical rule: the items should add up to roughly 80% of the meeting. The rest goes on getting into context at the start and pinning down agreements at the end — those minutes exist whether or not you planned them.
When the items don't fit, the extra one shouldn't be compressed — it should be taken out. A squeezed item still takes the time it needs; it just eats its neighbour, and you end up discussing not what matters most but whatever came earlier in the list.
The second rule is about order. Decision items go in the first third, while attention is intact and everyone is present; information goes at the end, because it's the only kind that survives latecomers. Never put the most contested item last: it will demand time that no longer exists, and end in a postponement.
When an hour isn't the unit
Past about three hours a list of items stops working: people run out of attention before the agenda runs out of lines. That calls for a different instrument — an itinerary built on clock times rather than durations.
# [Session], [date], 10:00–14:00 10:00 Frame: why we're here and what has to change — information, 15 min 10:15 Constraints and the numbers we start from — information, 30 min 10:45 Break, 10 min 10:55 Working through: where the process breaks — 60 min 11:55 Break, 15 min 12:10 Options and the choice between them — decision, 60 min 13:10 Owners, dates, next step — decision, 30 min 13:40 Buffer — 20 min A break every 60–75 minutes. Decision items before lunch.
The buffer at the end isn't insurance in case you overrun: it always gets spent. Leaving it out means the last item — usually the important one — will be discussed in the corridor.
Agenda checklist
When an agenda does harm
An agenda is a tool for a particular class of meeting, and outside that class it works against the result.
It gets in the way where the value is in unpredictability. In brainstorms, exploratory conversations and first customer calls, a rigid list closes off exactly what you came for: the aside that turns out to be the real topic. What works there is one stated goal and a list of areas you'd like to touch on.
It gets in the way in conversations about people. One-to-ones, feedback, conflict: a time-boxed item turns the conversation into a procedure and the person into item number two. Naming the subject in advance is enough for them not to be ambushed.
It gets in the way once it becomes ritual. A six-item agenda for a fifteen-minute sync; an agenda written after the meeting for the record; an agenda where every item is marked "information" — in all three cases the document exists and the function doesn't. That isn't a reason to write it better. It's a reason to cancel the meeting.
And it can't save a meeting that shouldn't happen. If drafting the agenda reveals that every item could be closed with a message, you've just saved eight people an hour, and there's no reason to hide it.
What to do about "any other business"
AOB at the end of an agenda is where everything nobody was willing to raise separately collects. It almost always eats more time than it was given, because what lands there is the most contested material: it stayed off the plan precisely because there's no agreement on it.
The working replacement is a running list of topics that surfaced but aren't on the agenda. At the end of the meeting you go down it in one pass — each topic gets an owner and lands either on the next agenda or in writing. Discussing it right now means substituting the accidental for the planned.
What you don't have to do by hand
There's only one way to check an agenda against reality: look at what the meeting actually reached. Whisperer transcribes the call and, once it ends, builds a meeting map — topics, decisions and action items as separate nodes. Set that against your agenda and you can see which items were left open and which topics surfaced instead of the planned ones. After a month of doing this it usually turns out that two items in six never survive to be discussed at all — which is the most honest reason there is to take them out of the template.
The formats with the strictest agendas are covered separately: identical blocks for every candidate in the piece on structured interviews, and question sequences that don't telegraph the answer in the one on customer discovery.