Skip to main content

Meetings

Use this catalog to pick the meeting that matches the outcome you need, prepare for it, and leave with a recorded result. Name the type in the invite so people know how to show up.

If a written exchange can produce the outcome, do not meet. See Meetings and async work.

Choose the type​

If you need toUse
Surface progress and blockersStandup
Commit the next sprintPlanning
Change how the team worksRetro
Inspect a change togetherCode review
Decide how to implement a ticketTechnical plan
Critique a proposal before committingTechnical review
Unblock current workHelp
Generate options without decidingBrainstorm
Teach someone to do the workTutorial

Scope​

This page defines working-meeting types, preparation, and outcomes.

It does not define:

Cadence and duration are team-owned unless a linked page already sets them. Do not treat attendance as success.

Standup​

Share completed work, today's focus, and blockers so the team can help and adjust. Do not reconstruct ticket history in the room.

Prepare:

  • Update Jira before the meeting: status, remaining work, dependencies, and blockers.
  • Know what you completed, what you will do next, and what is blocked.
  • Bring the blocker, the help you need, and who can provide it.

Outcome:

  • Today's focus and current blockers are visible.
  • Each blocker has an owner and a next action.
  • Jira matches reality.

Planning​

Select refined work, agree priorities, and make realistic commitments for the next sprint.

Prepare:

  • Tickets are understood enough to commit: outcome, scope, and important uncertainty are visible. Refine first if they are not.
  • Jira is current, including dependencies and date labels (exploration, operating, or external).
  • Know your capacity and any work already in progress.

Outcome:

  • The sprint contains agreed work with visible priorities.
  • Commitments are realistic and labeled honestly.
  • Owners and dependencies for the selected work are clear.

Retro​

Inspect how the work actually went and change the system so the same friction does not recur.

Prepare:

  • Specific observations from the period: what worked, what failed, and what surprised you.
  • Evidence, not only impressions: tickets, incidents, delays, or rework.
  • Candidate changes, not only complaints.

Outcome:

  • Named changes to a process, checklist, test, document, or tool.
  • Each change has an owner and a next action.
  • Learning is written back into the system, not only captured in notes. See Documentation and knowledge sharing.

Code review​

Walk through a published change together so the implementation is understood, corrected, and ready for the next quality gate. Review on the pull request when a shared walkthrough is not required.

Prepare:

  • The pull request is open, linked to the ticket, and locally verified. See Submit the work.
  • Reviewers have read the intended outcome, the plan, and the change.
  • The author can explain accepted decisions, dangers, and what remains for branch or human testing.

Outcome:

  • Findings are named: required changes, questions, or approval.
  • The change is accepted, returned to execution, or split.
  • Decisions live on the pull request, not only in the call. Human acceptance still follows Accept the work.

Technical plan​

Turn researched work into the smallest credible implementation and verification plan before coding starts.

Prepare:

  • The ticket has an expected outcome, scope, and research findings.
  • Decision candidates for data, additions, changes, and upstream or downstream impact are visible.
  • Acceptance criteria a tester can later pass or fail.

Outcome:

  • Approach, accepted decisions, rejected alternatives, and dangers are recorded.
  • The verification method is agreed.
  • The plan is ready to meet the Definition of Ready, or the missing decision has a named owner. Continue in Plan a technical ticket.

Technical review​

Critique a written design, RFC, or plan before the team commits to it. Do not use this meeting to invent the plan from a blank page.

Prepare:

  • The proposal is written and shared early enough to read.
  • The question the review must answer: feasibility, risk, contract, reuse, or go/no-go.
  • Relevant constraints: data, callers, consumers, Builder, operations, and delivery risk tier.

Outcome:

  • Accept, change, or reject, with named issues.
  • Required follow-up owners and unblock conditions are recorded.
  • The review evidence needed for Definition of Ready is visible. For product-level feasibility, see How We Build.

Help​

Unblock someone who cannot reasonably continue the current work without another person's judgment, access, or explanation.

Prepare:

  • The specific blocker, what you already tried, and the decision or access you need.
  • A link to the ticket, code, error, or document.
  • The smallest question that would let you continue.

Outcome:

  • The blocker is resolved, or a next action and owner are named.
  • The answer is recorded where the next person will look.
  • The requester can continue without reconstructing the conversation.

Brainstorm​

Generate and compare concepts before converging. This is not a commitment meeting.

Prepare:

  • The problem, desired outcome, and constraints that are already known.
  • What is in and out of scope for this session.
  • Existing research, customer evidence, or alternatives worth reacting to.

Outcome:

  • A set of options with their important tradeoffs.
  • Named assumptions to test.
  • What will not be decided here, and the next step: research, an RFC, or a later decision. Product discovery context is in How We Build.

Tutorial​

Teach a practice or system so another person can do the work without the teacher in the room.

Prepare:

  • The skill or system being taught, and the task the learner should complete afterward.
  • A realistic example and the shortest safe path.
  • The learner's current questions and required access.

Outcome:

  • The learner can repeat the task, or remaining gaps are named.
  • Durable notes or a documentation update exist when the knowledge will be needed again.
  • Follow-up practice or mentorship, if needed, has an owner. See Learning and mentorship.

If the meeting does not produce the outcome​

Name what is still missing, the owner, and the next action. Record that where affected people will look. Schedule a follow-up only if a meeting is still the lightest way to finish.

Do not relabel the session after the fact. If you needed a technical plan and held a brainstorm, the options may be useful; the plan is not done.