methodatlas
Session Builder

Plan my session

Plan a concrete work block with agenda, roles, preparation, and a copyable result artifact.

Async work run24 to 72 hasynchronousADR File

Session: Architecture Decision Record

The plan distributes preparation, review, and outcome work across an asynchronous work run. Your inputs flow directly into the session brief and work artifact.

Derived automatically

Async work run with 1-3. The plan uses the existing method logic and the runsheet.

Runsheet
Participation logic
Team round, shared work and alignment

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome logic
Finish artifact

The session works directly toward ADR File. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Prepare brief

    15-30 min

    Prepare the working question, input, target artifact, and review deadline for Architecture Decision Record. Link relevant data, sources, and existing artifacts.

    OwnerSession brief
  2. 2

    Work asynchronously

    24 to 72 h

    Participants work through the method along the template. Focus: add contributions directly to the artifact, mark assumptions, and link evidence.

    ParticipantsADR File
  3. 3

    Consolidate review

    20-30 min

    Cluster comments, contradictions, and open questions. Sort unclear points into decisions, risks, or follow-ups.

    FacilitatorReview notes
  4. 4

    Finalize artifact

    15-30 min

    Create the integrated version, set status, and schedule the next review or decision point.

    OwnerDecision Log
  5. 5

    Publish artifact

    10 min

    Check the artifact for completeness, define location, set version or status, and name review recipients.

    OwnerADR File
Usable artifact

Session Brief

For invitations, boards, tickets, PR descriptions, or workshop notes.

session-brief.md

Session Brief: Architecture Decision Record

Goal

Artifact: ADR File

Working Question

Which architecture decision needs to be recorded, and what context, options, decision, and consequences must a future reader understand?

Context

Problem statement, context, candidate options, constraints, and any non-negotiables.

Setup

  • Format: Async work run
  • Duration: 24 to 72 h
  • Mode: asynchronous
  • Participants: One decision owner and one reviewer or architect; optionally a subject-matter expert or engineer with system context.
  • Owner: One decision owner and one reviewer or architect
  • Participation mode: Team round, shared work and alignment
  • Outcome logic: Finish artifact

Participation Logic

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome Logic

The session works directly toward ADR File. After the session, the artifact should be shareable, reviewable, or reusable.

Input

ADR template or Markdown file; decision log; architecture sketch; links to relevant tickets, diagrams, and constraints; timer.

Preparation

Open the ADR in one file and add sections for status, context, decision, consequences, and links. Keep the decision visible as one sentence at the top.

Agenda

  1. Prepare brief (15-30 min) Owner: Owner Action: Prepare the working question, input, target artifact, and review deadline for Architecture Decision Record. Link relevant data, sources, and existing artifacts. Output: Session brief

  2. Work asynchronously (24 to 72 h) Owner: Participants Action: Participants work through the method along the template. Focus: add contributions directly to the artifact, mark assumptions, and link evidence. Output: ADR File

  3. Consolidate review (20-30 min) Owner: Facilitator Action: Cluster comments, contradictions, and open questions. Sort unclear points into decisions, risks, or follow-ups. Output: Review notes

  4. Finalize artifact (15-30 min) Owner: Owner Action: Create the integrated version, set status, and schedule the next review or decision point. Output: Decision Log

  5. Publish artifact (10 min) Owner: Owner Action: Check the artifact for completeness, define location, set version or status, and name review recipients. Output: ADR File

Closeout

  • Update result artifact: ADR File
  • Define location, version, and review recipients.
  • Define owner, next step, and review date.
Usable artifact

Work artifact

Pre-filled starting point based on the matching template.

work-artifact.md

ADR File: Architecture Decision Record

Working Question

Which architecture decision needs to be recorded, and what context, options, decision, and consequences must a future reader understand?

Context

Problem statement, context, candidate options, constraints, and any non-negotiables.

Participants

  • Owner: One decision owner and one reviewer or architect
  • Participants: One decision owner and one reviewer or architect; optionally a subject-matter expert or engineer with system context.

Input

ADR template or Markdown file; decision log; architecture sketch; links to relevant tickets, diagrams, and constraints; timer.

Template

ADR-0001: Decision Title

Status: proposed Date: YYYY-MM-DD Decider: First Last Trigger: Ticket, incident, or RFC

Context

What situation makes the decision necessary? Which constraints, quality attributes, or earlier decisions matter?

Options

Option 1: ...

  • Pros:
  • Cons:

Option 2: ...

  • Pros:
  • Cons:

Decision

We decide to ...

Consequences

Positive consequences:

  • ...

Negative consequences and risks:

  • ...

Follow-up ADRs or tickets:

  • ...

Completion Check

  • ADR File is complete enough for review:
  • Location:
  • Version / status:
  • Review by:
  • Next step:

Next Step

  • Review result
  • Mark open questions
  • Schedule review or decision
Template base

ADR Markdown Template

View templateCompact template for architecture decision records in a repository or wiki.
markdown

adr-markdown.md

Compact template for architecture decision records in a repository or wiki.

ADR-0001: Decision Title

Status: proposed Date: YYYY-MM-DD Decider: First Last Trigger: Ticket, incident, or RFC

Context

What situation makes the decision necessary? Which constraints, quality attributes, or earlier decisions matter?

Options

Option 1: ...

  • Pros:
  • Cons:

Option 2: ...

  • Pros:
  • Cons:

Decision

We decide to ...

Consequences

Positive consequences:

  • ...

Negative consequences and risks:

  • ...

Follow-up ADRs or tickets:

  • ...
Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits ADR File.
  • Store the ADR beside the code or in the team documentation home. Add date, status, and owner in the header. If the decision changes, create a new ADR or revision entry and keep the old version readable.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet