MoSCoW-Methode: Anforderungen nach einer Besprechung priorisieren

Priorität hängt von Ziel und Zeitraum ab

In der Besprechung hat jede Person ihre Funktion als unverzichtbar bezeichnet. So lässt sich kein Umfang festlegen. Einigen Sie sich zuerst darauf, was das nächste Release leisten muss und wann es unbrauchbar wäre. Für eine andere Phase können die Prioritäten ganz anders aussehen.

MoSCoW verwendet vier Kategorien: Must Have, Should Have, Could Have und Won’t Have this time. Die letzte Kategorie schließt eine Anforderung für den betrachteten Zeitraum bewusst aus. Sie enthält weder eine Zusage für später noch eine endgültige Ablehnung.

Besprechen Sie die Folgen des Weglassens

1. Das Release-Ziel beschreiben

   Halten Sie Nutzer, Aufgabe und Einsatzbedingungen fest. Klären Sie Einschränkungen und Planungshorizont. Solange das Ziel nur „Produkt verbessern“ lautet, bewerten die Beteiligten Anforderungen nach unterschiedlichen Kriterien und halten fast alles für unverzichtbar.

2. Kandidaten für Must prüfen

   Fragen Sie jeweils, ob auch ohne die Anforderung ein brauchbares Ergebnis möglich wäre. Berücksichtigen Sie akzeptable Übergangslösungen und Abhängigkeiten. Eine Einstufung als Must braucht eine konkrete Begründung. „Die Leitung hat darum gebeten“ nennt die Quelle, aber keine Folgen des Weglassens.

3. Wichtiges und Wünschenswertes unterscheiden

   Should bezeichnet einen wichtigen Bestandteil. Ohne ihn wird das Ergebnis deutlich schwächer, bleibt aber brauchbar. Could ist eine sinnvolle Ergänzung, die sich leichter weglassen lässt. Erläutern Sie den Unterschied anhand der Nutzung und der Folgen des Weglassens. „Sehr wichtig“ allein genügt nicht.

4. Ausschlüsse und erneute Prüfung vereinbaren

   Notieren Sie für ein Won’t den Grund und die Bedingung für eine erneute Diskussion. Prüfen Sie Abhängigkeiten und die Machbarkeit des gewählten Umfangs. Übersteigt das Pflichtprogramm die verfügbare Kapazität, passen Sie Umfang oder Plan an. Eine andere Einstufung löst kein Kapazitätsproblem.

Erstes Release eines Anmeldeformulars für eine Veranstaltung

Das folgende Übungsbeispiel ist fiktiv. Namen, Rahmenbedingungen und Ergebnisse dienen ausschließlich dazu, die Methode zu erklären.

In diesem Beispiel ist das Ziel, eine Person anzumelden und ihr eine verständliche Bestätigung zu geben. Die Anmeldung ist ein Must, weil sonst der Hauptablauf wegfällt. Eine Erinnerung kann ein Should sein, wenn das Team vorübergehend mit einer vereinbarten Alternative auskommt.

Die Farbe des Namensschilds kann ein Could sein und das persönliche Konto bleibt dieses Mal außen vor. Die Einordnung gilt für dieses Beispiel. Bei einer anderen Veranstaltung oder Zielgruppe wären die Folgen anders.

Karte zur Begründung der Priorität

Halten Sie Kategorie und Begründung fest. So können Sie die Entscheidung erneut prüfen, wenn sich die Bedingungen ändern.

Release / Zeitraum / Ziel:
Anforderung:
Nutzungsszenario:
Was ohne diese Anforderung passiert:
Akzeptable Übergangslösung:
Abhängigkeiten:
MoSCoW-Kategorie:
Begründung:
Wer die Entscheidung bestätigt hat:
Bedingung für die erneute Prüfung:
Ausschlüsse in diesem Zeitraum:

Prüfen Sie, ob die Liste Entscheidungen erleichtert

• Ziel und Zeitraum stehen bei den Kategorien.
• Für jedes Must sind die Folgen des Weglassens beschrieben.
• Eine mögliche Übergangslösung wurde ausdrücklich geprüft.
• Ein Won’t für diesen Zeitraum wird als aktueller Ausschluss verstanden.