Merge pull request #116 from LLM-Coding/copilot/add-moscow-anchor-term

Add MoSCoW prioritization method as semantic anchor

Author: rdmueller

docs/all-anchors.adoc

@@ -91,6 +91,8 @@ include::anchors/rubber-duck-debugging.adoc[leveloffset=+2]
 
 include::anchors/ears-requirements.adoc[leveloffset=+2]
 
+include::anchors/moscow.adoc[leveloffset=+2]
+
 include::anchors/problem-space-nvc.adoc[leveloffset=+2]
 
 include::anchors/user-story-mapping.adoc[leveloffset=+2]

docs/anchors/moscow.adoc

@@ -0,0 +1,45 @@
+= MoSCoW
+:categories: requirements-engineering
+:roles: product-owner, business-analyst, team-lead, consultant
+:related: user-story-mapping, impact-mapping
+:proponents: Dai Clegg
+:tags: prioritization, requirements, agile, dsdm
+
+[%collapsible]
+====
+Full Name:: MoSCoW Prioritization Method
+
+Also known as:: MoSCoW Analysis, MoSCoW Method
+
+*Core Concepts*:
+
+Must have:: Non-negotiable requirements essential for the current delivery; without them the solution is unusable or unsafe
+
+Should have:: Important requirements that are not vital; painful to leave out but the solution is still viable without them
+
+Could have:: Desirable but not necessary requirements; included only if time and resources permit
+
+Won't have (this time):: Requirements explicitly agreed to be out of scope for the current iteration; may be reconsidered in future
+
+Timeboxed context:: Prioritization is always relative to a fixed timebox, not permanent
+
+Stakeholder alignment:: Prioritization is a collaborative activity that builds shared understanding
+
+Scope control:: Explicit "Won't have" category reduces scope creep by surfacing deferred items
+
+
+Key Proponent:: Dai Clegg (Dynamic Systems Development Method / DSDM, 1994)
+
+*When to Use*:
+
+* Sprint and release planning in agile teams
+* Scoping a Minimum Viable Product (MVP)
+* Negotiating scope with stakeholders under time or budget constraints
+* Prioritizing a backlog when resources are limited
+* Aligning cross-functional teams on delivery expectations
+
+*Related Anchors*:
+
+* <<user-story-mapping,User Story Mapping>>
+* <<impact-mapping,Impact Mapping>>
+====

docs/anchors/moscow.de.adoc

@@ -0,0 +1,45 @@
+= MoSCoW
+:categories: requirements-engineering
+:roles: product-owner, business-analyst, team-lead, consultant
+:related: user-story-mapping, impact-mapping
+:proponents: Dai Clegg
+:tags: prioritization, requirements, agile, dsdm
+
+[%collapsible]
+====
+Vollständiger Name:: MoSCoW-Priorisierungsmethode
+
+Auch bekannt als:: MoSCoW-Analyse, MoSCoW-Methode
+
+*Kernkonzepte*:
+
+Must have:: Nicht verhandelbare Anforderungen, die für die aktuelle Lieferung unerlässlich sind; ohne sie ist die Lösung nicht nutzbar oder nicht sicher
+
+Should have:: Wichtige Anforderungen, die nicht zwingend notwendig sind; ihr Fehlen ist schmerzhaft, aber die Lösung bleibt ohne sie funktionsfähig
+
+Could have:: Wünschenswerte, aber nicht notwendige Anforderungen; werden nur umgesetzt, wenn Zeit und Ressourcen es erlauben
+
+Won't have (diesmal):: Anforderungen, die ausdrücklich als außerhalb des aktuellen Lieferumfangs vereinbart sind; können in zukünftigen Iterationen erneut betrachtet werden
+
+Zeitboxbezug:: Die Priorisierung bezieht sich immer auf eine feste Zeitbox, nicht auf eine dauerhafte Entscheidung
+
+Stakeholder-Ausrichtung:: Priorisierung ist eine kollaborative Aktivität, die ein gemeinsames Verständnis fördert
+
+Scope-Kontrolle:: Die explizite Kategorie "Won't have" reduziert Scope Creep, indem zurückgestellte Anforderungen sichtbar gemacht werden
+
+
+Schlüsselvertreter:: Dai Clegg (Dynamic Systems Development Method / DSDM, 1994)
+
+*Wann zu verwenden*:
+
+* Sprint- und Release-Planung in agilen Teams
+* Bestimmung des Umfangs eines Minimum Viable Product (MVP)
+* Aushandlung des Umfangs mit Stakeholdern bei Zeit- oder Budgetbeschränkungen
+* Priorisierung eines Backlogs bei begrenzten Ressourcen
+* Ausrichtung funktionsübergreifender Teams auf Liefererwartungen
+
+*Verwandte Anker*:
+
+* <<user-story-mapping,User Story Mapping>>
+* <<impact-mapping,Impact Mapping>>
+====

website/package-lock.json

@@ -202,7 +202,7 @@
   },
   {
     "id": "devils-advocate",
-    "title": "Devil’s Advocate",
+    "title": "Devil\u2019s Advocate",
     "categories": [
       "problem-solving"
     ],
@@ -219,7 +219,7 @@
   },
   {
     "id": "diataxis-framework",
-    "title": "Diátaxis Framework",
+    "title": "Di\u00e1taxis Framework",
     "categories": [
       "documentation"
     ],
@@ -234,7 +234,7 @@
   },
   {
     "id": "docs-as-code",
-    "title": "Docs-as-Code according to Ralf D. Müller",
+    "title": "Docs-as-Code according to Ralf D. M\u00fcller",
     "categories": [
       "documentation"
     ],
@@ -267,7 +267,7 @@
   },
   {
     "id": "dry-principle",
-    "title": "DRY (Don’t Repeat Yourself)",
+    "title": "DRY (Don\u2019t Repeat Yourself)",
     "categories": [
       "design-principles"
     ],
@@ -556,6 +556,33 @@
     "tags": [],
     "filePath": "docs/anchors/nelson-rules.adoc"
   },
+  {
+    "id": "moscow",
+    "title": "MoSCoW",
+    "categories": [
+      "requirements-engineering"
+    ],
+    "roles": [
+      "product-owner",
+      "business-analyst",
+      "team-lead",
+      "consultant"
+    ],
+    "related": [
+      "user-story-mapping",
+      "impact-mapping"
+    ],
+    "proponents": [
+      "Dai Clegg"
+    ],
+    "tags": [
+      "prioritization",
+      "requirements",
+      "agile",
+      "dsdm"
+    ],
+    "filePath": "docs/anchors/moscow.adoc"
+  },
   {
     "id": "problem-space-nvc",
     "title": "Problem Space NVC",
@@ -892,4 +919,4 @@
     "tags": [],
     "filePath": "docs/anchors/what-qualifies-as-a-semantic-anchor.adoc"
   }
-]
+]