Anforderungen priorisieren: MoSCoW, Kano und das Nein

· 8 Min. Lesezeit
Anforderungen priorisieren: MoSCoW, Kano und das Nein

Eine Anforderung sagt, was zu bauen ist. Eine Priorität sagt, was zuerst zu bauen ist — und, genauso wichtig, was gar nicht zu bauen ist. Eine Spezifikation mit Anforderungen, aber ohne Prioritäten, ist kein Plan, sondern eine Wunschliste — und das Team baut am Ende das Lauteste statt das Wichtigste.

Zwei Werkzeuge erledigen den Großteil der Arbeit: MoSCoW für die Verbindlichkeit und Kano für die Wertentscheidung.

Warum überhaupt priorisieren

Ressourcen sind endlich und Termine sind real. Eine nicht priorisierte Liste versteckt den Zielkonflikt, statt ihn sichtbar zu machen. Wenn der Zeitplan rutscht, muss irgendjemand entscheiden, was gestrichen wird — und wurde die Entscheidung nie getroffen, wird sie unter Druck getroffen, und zwar schlecht.

Priorisierung ist keine Bürokratie. Sie ist die Anforderungsentscheidung, die Sie treffen, damit der spätere Schnitt bewusst statt zufällig fällt.

MoSCoW: die Verbindlichkeit

Die Disziplin steckt im vierten Eimer. Etwas als „Won’t have“ zu notieren ist das, was Scope-Creep verhindert — denn eine Funktion, die nie ausgeschlossen wurde, wird stillschweigend erwartet.

  • Must have (muss) — nicht verhandelbar. Ohne sie scheitert das Release; ist sie gefährdet, verschiebt sich der Zeitplan.
  • Should have (sollte) — wichtig, aber nicht lebenswichtig. Es schmerzt, sie wegzulassen, aber das Release überlebt es.
  • Could have (könnte) — nett zu haben. Geringer Wert; nur einplanen, wenn alles andere erledigt ist.
  • Won’t have (wird nicht, diesmal) — ausdrücklich außerhalb des Umfangs. Nicht „nie“, nur „jetzt nicht“.

Kano: die Wertentscheidung

Das Kano-Modell sortiert Funktionen danach, wie sie die Zufriedenheit beeinflussen — ein besserer Wegweiser für Wert als „wir glauben, die Nutzer wollen das“.

  • Basisfaktoren (must-be) — erwartet. Ihr Fehlen verursacht starke Unzufriedenheit; ihre Anwesenheit stiftet keine Begeisterung. Man muss sie liefern, aber sie gewinnen keine Kunden.
  • Leistungsfaktoren — je mehr, desto besser. Die Zufriedenheit steigt proportional zur Erfüllung. Hier leben Geschwindigkeit, Kapazität und Feinschliff.
  • Begeisterungsfaktoren (Delighter) — unerwartet. Ihre Anwesenheit begeistert; ihr Fehlen verursacht keine Unzufriedenheit. Davon erzählen Menschen ihren Freunden.
  • Indifferente — niemandem fällt es in irgendeine Richtung auf. Kandidaten für die Streichliste.
  • Reverse — ihre Anwesenheit verursacht sogar Unzufriedenheit. Man muss sie kennen, um sie nicht zu bauen.

Die „Won’t do“-Liste ist auch eine Entscheidung

Das am meisten unterschätzte Ergebnis der Priorisierung ist die Liste der Dinge, die Sie bewusst nicht bauen. Sie setzt Erwartungen, schützt den Zeitplan und gibt dem Team die Erlaubnis, mit dem Vergolden aufzuhören. Ein Anforderungsdokument ohne Ausschlüsse ist ein Dokument, das ewig wächst.

„Jetzt nicht“ zu sagen ist kein Planungsversagen — es ist der Plan.

Beides zusammen

Nutzen Sie zuerst Kano, um Wert zu verstehen: Trennen Sie die Basisfaktoren (müssen geliefert werden) von den Leistungsfaktoren (die wertvollsten zuerst) von den Begeisterungsfaktoren (einen liefern — günstig und einprägsam). Dann nutzen Sie MoSCoW für die Verbindlichkeit: Basisfaktoren sind Must-haves, wertvolle Leistungsfaktoren Should-haves, geringwertige Could-haves, alles andere Won’t-haves — dokumentiert, nicht vergessen.

Das Ergebnis ist eine Spezifikation, die nicht nur sagt, was das System ist, sondern was das Team tatsächlich tun wird, in welcher Reihenfolge und was es bewusst weggelassen hat.

Eine priorisierte Spezifikation beantwortet die Frage, die am Anfang niemand gestellt hat: Wenn der Zeitplan rutscht, was streichen wir? Können Sie das nicht aus dem Dokument beantworten, ist das Dokument nicht fertig.
    Anforderungen priorisieren: MoSCoW, Kano und das Nein