methodatlas
Session Builder

Plan my session

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

Method session30-90 minWorkshop or asyncPrioritized Backlog

Session: MoSCoW

The plan translates the method into a concrete facilitated work block. Your inputs flow directly into the session brief and work artifact.

Derived automatically

Method session with 3-12. 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 Prioritized Backlog. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Section 1: Define must

    10 min

    Define Must explicitly for this release ("without this item launch is impossible or non-compliant"). Use examples from previous releases. Hint: If Must is discussed as "important to me," the method collapses. Strong definition restores workshop quality.

    FacilitatorPrioritized Backlog
  2. 2

    Section 2: PO solo ranking

    10-15 min

    PO reviews the list once and assigns an initial category per item without discussion. Others note divergences. Hint: PO ranking as the starting point avoids endless group debate. Others contribute corrections visibly, not in a side conversation.

    FacilitatorRelease Scope
  3. 3

    Section 3: Discussion and convergence

    20-40 min

    Review items with disagreement. Per item: case for elevation, case for lowering, and PO decision. Capacity check: Musts must fit within less than 60% of team capacity. Hint: When musts exceed 60% of capacity, release risk rises. Rigorously test what can move to Should without breaking the release.

    FacilitatorTradeoff Notes
  4. 4

    Section 4: Clarify won’t this time

    10 min

    Move explicit out-items into Won't column and document rationale. Make clear: Won't is not never, only not now. Hint: Explicit won’t this time reduces stakeholder frustration. If an item does not appear, stakeholders assume it was forgotten.

    FacilitatorPrioritized Backlog
  5. 5

    Section 5: Capacity reality check

    10 min

    Aggregate estimated effort of Musts and Shoulds against available capacity. If Musts alone exceed 100%, the release is at risk and scope negotiation is required. Hint: A common trap is stacking Musts without effort checks. The method then looks structured, but release collapses on capacity.

    OwnerRelease Scope
  6. 6

    Publish artifact

    10 min

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

    OwnerPrioritized Backlog
Usable artifact

Session Brief

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

session-brief.md

Session Brief: MoSCoW

Goal

Artifact: Prioritized Backlog

Working Question

Which items must be included in the release, which are negotiable, and how much scope remains for stakeholder negotiation?

Context

Backlog with item descriptions; effort estimate per item (t-shirt or story points); known dependencies and risks; constraints (compliance, contracts, external milestones); definition of Must for this release.

Setup

  • Format: Method session
  • Duration: 30-90 min
  • Mode: Workshop or async
  • Participants: A product owner with final prioritization mandate; a facilitator (often Scrum Master or delivery lead); 2-5 stakeholders for item understanding and business context; team representative from engineering.
  • Owner: A product owner with final prioritization mandate
  • 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 Prioritized Backlog. After the session, the artifact should be shareable, reviewable, or reusable.

Input

Backlog tool (Linear, Jira, Notion) with status or label field for MoSCoW; whiteboard or digital board with four columns (Must, Should, Could, Won't this time); timer.

Preparation

Use four columns on the board. Explain categories up front: Must means release cannot proceed without it; Should is important but optional for release; Could is if time allows; Won't this time is intentionally not included now. Set timer at 60 min.

Agenda

  1. Section 1: Define must (10 min) Owner: Facilitator Action: Define Must explicitly for this release ("without this item launch is impossible or non-compliant"). Use examples from previous releases. Hint: If Must is discussed as "important to me," the method collapses. Strong definition restores workshop quality. Output: Prioritized Backlog

  2. Section 2: PO solo ranking (10-15 min) Owner: Facilitator Action: PO reviews the list once and assigns an initial category per item without discussion. Others note divergences. Hint: PO ranking as the starting point avoids endless group debate. Others contribute corrections visibly, not in a side conversation. Output: Release Scope

  3. Section 3: Discussion and convergence (20-40 min) Owner: Facilitator Action: Review items with disagreement. Per item: case for elevation, case for lowering, and PO decision. Capacity check: Musts must fit within less than 60% of team capacity. Hint: When musts exceed 60% of capacity, release risk rises. Rigorously test what can move to Should without breaking the release. Output: Tradeoff Notes

  4. Section 4: Clarify won’t this time (10 min) Owner: Facilitator Action: Move explicit out-items into Won't column and document rationale. Make clear: Won't is not never, only not now. Hint: Explicit won’t this time reduces stakeholder frustration. If an item does not appear, stakeholders assume it was forgotten. Output: Prioritized Backlog

  5. Section 5: Capacity reality check (10 min) Owner: Owner Action: Aggregate estimated effort of Musts and Shoulds against available capacity. If Musts alone exceed 100%, the release is at risk and scope negotiation is required. Hint: A common trap is stacking Musts without effort checks. The method then looks structured, but release collapses on capacity. Output: Release Scope

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

Closeout

  • Update result artifact: Prioritized Backlog
  • 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

Prioritized Backlog: MoSCoW

Working Question

Which items must be included in the release, which are negotiable, and how much scope remains for stakeholder negotiation?

Context

Backlog with item descriptions; effort estimate per item (t-shirt or story points); known dependencies and risks; constraints (compliance, contracts, external milestones); definition of Must for this release.

Participants

  • Owner: A product owner with final prioritization mandate
  • Participants: A product owner with final prioritization mandate; a facilitator (often Scrum Master or delivery lead); 2-5 stakeholders for item understanding and business context; team representative from engineering.

Input

Backlog tool (Linear, Jira, Notion) with status or label field for MoSCoW; whiteboard or digital board with four columns (Must, Should, Could, Won't this time); timer.

Template

MoSCoW Working Template

Goal

Prioritizes scope into Must, Should, Could, and Won't.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • Prioritized Backlog:
  • Release Scope:
  • Tradeoff Notes:

Assumptions and open questions

  • ...

Decision / Next step

Owner, date, and success signal.

Completion Check

  • Prioritized Backlog 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

MoSCoW Working Template

View templateCompact working template for MoSCoW with context, input, output artifacts, and next step.
markdown

moscow-working-template.md

Compact working template for MoSCoW with context, input, output artifacts, and next step.

MoSCoW Working Template

Goal

Prioritizes scope into Must, Should, Could, and Won't.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • Prioritized Backlog:
  • Release Scope:
  • Tradeoff Notes:

Assumptions and open questions

  • ...

Decision / Next step

Owner, date, and success signal.

Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits Prioritized Backlog.
  • Create a separate version per release cycle with date and release name. Document category movements during sprint (for example "Item X moved from Should to Must on 12.06., reason: compliance update").
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet