Skip to content
Discovery WaypointDecision-ready discovery
Start WorkspaceSign in
Start Workspace
Sign in
Atlassian

Atlassian Team Playbook

Run tomorrow · Primary + examples

Atlassian Project Kickoff

A bounded kickoff play for aligning purpose, roles, and success signals before a project starts pretending clarity it does not have.

Best opened when

Open it before a project, initiative, or cross-functional push starts creating commitments it cannot yet support.

What to steal first

Borrow the alignment-plus-risk sequence before importing any project-specific worksheet or ceremony.

What not to copy

It is not a roadmap review.

Closest move

Define the problem / scope / success measures

Core operating sequence

Play anatomy

The Project Kickoff gives a team a single compressed session to align on why the work exists, who is responsible for which part, what the boundaries are, and what could derail it. It is not a project plan. It is a shared starting picture — the minimum everyone needs before commitments start accumulating.

The transferable sequence is: outcome and scope first, then roles and dependencies, then visible risks with owners. That order matters. Teams that jump to roles before anyone has agreed on the outcome end up assigning accountability for unclear work. Teams that skip the risk conversation discover those risks in week three.

What does not transfer: the specific Atlassian worksheet format, the exact timing, and the expectation that a kickoff replaces ongoing alignment. The output is a starting picture, not a finished operating model. If the project evolves materially, the kickoff record should be revisited.

Run it in the room

A clean first pass you can run

Participants
Project lead, key contributors, one executive sponsor if available. 4–12 people. Anyone who will make commitments on behalf of the project needs to be in the room.
Timing
90–120 minutes. Shorter kickoffs produce false clarity.
Prep
Write a one-paragraph project brief before the session. The brief will surface what is already unclear — that is its purpose, not to arrive polished.
  1. 1State the project goal in one sentence and get genuine agreement. If the room produces multiple versions of the goal, resolve the disagreement before continuing.
  2. 2Define what success looks like at the end of the project. Not 'we delivered X' but 'we will know we succeeded when Y is true.' Be specific enough that two people in the room can independently judge whether it was achieved.
  3. 3Map the roles explicitly. Who drives decisions? Who approves them? Who needs to be consulted? Who just needs to be kept informed? Use DACI language if it exists in the team's vocabulary.
  4. 4Name the constraints: timeline, budget, team capacity, and external dependencies. Hidden constraints derail more projects than bad plans. Surface them now.
  5. 5Name the first moment where this project is most likely to go wrong. Make it visible before it happens and assign an owner for monitoring it.

You leave with

A one-page kickoff record — goal, success definition, roles, constraints, and first risk — shared with everyone in the room before 24 hours pass.

First failure point: The session ends with enthusiasm but no written record. By next week, the goal and the role assignments are already being interpreted differently by different people.

What good looks like

If this is working, these are the signals you should be able to point to

  • The problem is written in one sentence and the team agrees it is the right problem.
  • Success measures are stated specifically enough that two people could independently judge whether they are met.
  • Each person in the room can say what they own and who they need to coordinate with.
  • There is at least one open question the kickoff explicitly did not resolve, with a name attached to closing it.

How it worked there

The conditions that made it hold

Atlassian built the Project Kickoff for product and service projects with multiple owners and contributors who needed to start from the same picture. In distributed, cross-functional teams, the cost of implicit assumptions at project start is high — different people build different mental models of what success looks like and who is responsible for what.

The play works when a decision-maker with real sponsor authority is in the room. A kickoff that produces outcome clarity but has no one present who can ratify it, allocate resources to it, or remove blockers from it is still misaligned — just more politely. The kickoff's value depends on the room having the people who can close ambiguity, not just discuss it.

What not to copy · Failure modes

What goes wrong when this is copied

The kickoff is treated as an announcement, not a working session. Someone walks the team through the goals and timeline, the room nods, and the project launches with the same vague clarity it had before. A kickoff that does not force the team to name the open questions, the first risks, and who owns the next decision has just created a false impression of alignment.

The risks stay unnamed because naming them feels negative. Kickoffs run toward enthusiasm. The facilitator wants the team to feel energized, not apprehensive. So the risk conversation gets abbreviated, softened, or deferred to a later review. The risks that are already visible before the project begins are exactly the ones that should be named with owners before momentum builds.

The kickoff output is never reused. The clarity produced in the session — the outcome framing, the role assignments, the named risks — disappears into a shared doc that nobody opens again. The next planning cycle or sprint review starts from scratch. A kickoff that does not feed the first planning checkpoint has produced alignment on paper only.

Weak signals to watch for

  • It is not a roadmap review.
  • It is not a substitute for problem framing when the work is still too ambiguous.
  • Do not make the kickoff a slide walk-through with no real working decisions.
  • Do not close the session without named risks and what will happen next.

Closest Waypoint move

What to open next

Primary route

Define the problem / scope / success measures

Use the situation route if the kickoff reveals that the work still lacks a stable problem frame.

Use this when you need shared project clarity and can accept doing more upfront framing than the team may initially want.

Sources and confidence

Primary + examples

Reviewed by Discovery Waypoint Editorial Team · 2026-04-04