Alle Anforderungen sind wichtig, aber sie werden priorisiert, um den größten und unmittelbarsten Geschäftsnutzen frühzeitig zu liefern. Die Entwickler werden zunächst versuchen, alle „Muss“-, „Sollte“- und „Könnte“-Anforderungen zu liefern, aber die „Sollte“- und „Könnte“-Anforderungen werden als erste entfernt, wenn der Zeitplan für die Lieferung gefährdet scheint.
Die einfache englische Bedeutung der Priorisierungskategorien hat den Wert, dass Kunden die Auswirkung des Setzens einer Priorität besser verstehen, im Vergleich zu Alternativen wie Hoch, Mittel und Niedrig.
Die Kategorien werden typischerweise wie folgt verstanden:
Muss haben Anforderungen, die als Muss haben gekennzeichnet sind, sind kritisch für den aktuellen Lieferzeitrahmen, damit dieser ein Erfolg wird. Wenn auch nur eine „Must have“-Anforderung nicht enthalten ist, sollte die Projektlieferung als gescheitert betrachtet werden (Hinweis: Anforderungen können in Absprache mit allen relevanten Stakeholdern von „Must have“ herabgestuft werden, z. B. wenn neue Anforderungen als wichtiger erachtet werden). MUST kann auch als Akronym für Minimum Usable Subset betrachtet werden. Sollte haben Anforderungen, die als Sollte haben gekennzeichnet sind, sind wichtig, aber nicht notwendig für die Lieferung in der aktuellen Lieferfrist. Während „Should have“-Anforderungen genauso wichtig sein können wie „Must have“, sind sie oft nicht so zeitkritisch oder es gibt möglicherweise eine andere Möglichkeit, die Anforderung zu erfüllen, so dass sie bis zu einem zukünftigen Liefertermin zurückgestellt werden kann. Könnte haben Anforderungen, die als „Könnte haben“ gekennzeichnet sind, sind wünschenswert, aber nicht notwendig und könnten die Benutzerfreundlichkeit oder Kundenzufriedenheit für einen geringen Entwicklungsaufwand verbessern. Sie werden in der Regel aufgenommen, wenn Zeit und Ressourcen es erlauben. Won’t have (diesmal) Anforderungen, die als „Won’t have“ gekennzeichnet sind, wurden von den Stakeholdern als die am wenigsten kritischen, am wenigsten rentablen Elemente vereinbart oder sind zu diesem Zeitpunkt nicht sinnvoll. Infolgedessen werden Anforderungen mit der Kennzeichnung „Won’t have“ nicht in den Zeitplan für die nächste Timebox eingeplant. Won’t have-Anforderungen werden entweder fallen gelassen oder für die Aufnahme in eine spätere Timebox erneut in Betracht gezogen. (Hinweis: Gelegentlich wird der Begriff Would like to have verwendet; diese Verwendung ist jedoch nicht korrekt, da diese letzte Priorität eindeutig besagt, dass etwas außerhalb des Lieferumfangs liegt). (Das BCS in Ausgabe 3 & 4 des Business Analysis Book beschreibt ‚W‘ als ‚Want to have but not this time around‘)
VariantenBearbeiten
Gelegentlich wird W für Wish (oder Would) verwendet, d.h. immer noch möglich, aber unwahrscheinlich, dass es enthalten ist (und weniger wahrscheinlich als Could). Dies wird dann unterschieden von X für Excluded für Elemente, die explizit nicht enthalten sind.