Back to the Playbook
Define & DesignDD-05
How to prioritise with MoSCoW
Use the conversation to separate essential delivery from negotiable scope; Won’t means this time, not forever.
Product statusAvailable now
Input4 required inputsCandidate requirements · Core user journey and capacity constraints · Dependencies
SkillsFacilitate MoSCoW scope · Prepare task context · Review an artifact against agreed criteriaProduct Manager + Product Manager Agent
OutcomeMoSCoW scope: release boundary, Must/Should/Could/Won’t groups with rationale, dependencies and open decisions.Artifact: MoSCoW scope
Owner
Product Manager
Human + Agent
Participants · Agents
EngineerHead of ProductProduct Manager Agent
Trigger
Candidate requirements exceed one release or planning horizon.
Required context
JiraCandidate requirementsProduct BrainCore user journey and capacity constraintsCodeDependenciesProduct BrainInitiative focus and approved Product Brain guidance
Optional context
FilesStakeholder classifications
Skills
Facilitate MoSCoW scopePrepare task contextReview an artifact against agreed criteria
Suggested conversation arc
- 1Frame the release boundaryAgree the user journey that must work, the release horizon and constraints before sorting requirements.Skills: Prepare task context
- 2Propose MoSCoW bucketsCollect all candidates and propose Must, Should, Could and Won’t-this-time with rationale. Expose dependencies rather than hiding them in a bucket.Skills: Facilitate MoSCoW scope
- 3Challenge every MustAsk what fails if each Must is omitted. Compare stakeholder disagreements and retain negotiable value as Should or Could when the core journey still works.
- 4Confirm scope and exclusionsCheck feasibility and dependent requirements; explicitly confirm Won’t-this-time items and the conditions under which scope may be reconsidered.Skills: Review an artifact against agreed criteria
Output
MoSCoW scope: release boundary, Must/Should/Could/Won’t groups with rationale, dependencies and open decisions.
Artifacts
Creates: MoSCoW scope
What good looks like
- All candidates appear in an explicit group or an unresolved section.
- Every Must has a concrete necessity rationale.
- Feasible scope is not promised without dependency and capacity evidence.
Quality gate
The Product Manager confirms the scope, the exclusions and when they may be reconsidered.
Destination
JiraConfluence
Usually next
People and agents work from the same Product Brain. The owner stays accountable. Assigned agents prepare and check. A named person approves at the gate.
Deep dives from the AI PM Lab
Articles that explain the thinking behind this Activity.
Choose the path that matches your role.
Set the Product AI direction with us, or test the shared Product Brain on real work with Jira and code.