Warum Priorisierung im agilen Projekt entscheidend ist
In jedem Projekt gibt es mehr Anforderungen als Zeit. Agile Frameworks lösen dieses Problem nicht durch mehr Ressourcen — sondern durch konsequente Priorisierung. MoSCoW und das User-Story-Format sind die wichtigsten Werkzeuge dafür.
Das User-Story-Format
Eine User Story beschreibt eine Anforderung aus der Perspektive der nutzenden Person — nicht aus technischer Sicht.
Standardformat
Als [Rolle]
möchte ich [Funktion / Ziel]
damit [Nutzen / Wert]
Beispiel
Als Fahrerin einer Liefertour
möchte ich Lieferscheine per Kamera scannen können
damit ich keine Papierformulare mehr ausfüllen muss und Zeit pro Stopp spare.
Akzeptanzkriterien
Jede User Story braucht Akzeptanzkriterien — messbare Bedingungen, die definieren, wann die Story als „fertig“ gilt.
- Der Scan erkennt Barcodes und QR-Codes zuverlässig
- Das Ergebnis wird in unter 3 Sekunden gespeichert
- Bei einem Lesefehler erscheint eine klare Fehlermeldung
Qualitätskriterien: INVEST
| Buchstabe | Englisch | Bedeutung |
|---|---|---|
| I | Independent | Story kann unabhängig entwickelt werden |
| N | Negotiable | Details können noch diskutiert werden |
| V | Valuable | Liefert messbaren Mehrwert |
| E | Estimable | Aufwand kann grob geschätzt werden |
| S | Small | Passt in einen Sprint / eine Timebox |
| T | Testable | Hat klare Akzeptanzkriterien |
MoSCoW-Priorisierung
MoSCoW ist eine Priorisierungsmethode, die im AgilePM®-Framework verankert ist. Sie unterscheidet vier Kategorien:
| Kategorie | Bedeutung | Faustregel |
|---|---|---|
| Must have | Ohne diese Funktion ist das Release wertlos | ≤ 60 % des Gesamtaufwands |
| Should have | Wichtig, aber im Notfall verschiebbar | Puffer für Must-haves |
| Could have | Nice-to-have, wird geliefert wenn Zeit bleibt | Scope-Puffer |
| Won't have | Explizit ausgeklammert für dieses Release | Verwaltet Erwartungen |
Timeboxing und MoSCoW zusammen denken
MoSCoW funktioniert nur im Zusammenspiel mit Timeboxing: Die Timebox (Zeit und Budget) ist fix. Was innerhalb dieser Timebox geliefert wird, bestimmt MoSCoW. Wenn Zeit knapp wird, fallen zunächst Could-haves weg — dann Should-haves. Must-haves müssen immer geliefert werden, sonst sollte das Release verschoben werden.
Häufige Fehler bei MoSCoW
- Zu viele Must-haves: Wenn alles „muss“, gibt es keine Flexibilität. Faustregel: ≤ 60 % des Gesamtaufwands
- Won't have vergessen: Klare Ausschlüsse verhindern spätere Scope-Diskussionen
- Priorität ohne Kontext: MoSCoW-Kategorien müssen immer auf eine konkrete Timebox / ein Release bezogen sein
Im Backlog sind 80 Prozent der Anforderungen als Must have eingestuft. Warum ist das kein Zeichen von Klarheit?
Erst selbst beantworten — dann vergleichen.
Key Takeaways
- User Stories formulieren Anforderungen aus Nutzersicht — nicht aus technischer Perspektive
- INVEST-Kriterien sichern die Qualität jeder User Story
- MoSCoW macht den Scope explizit priorisierbar und Timeboxing erst möglich
- Must-haves sollten maximal 60 % des Gesamtaufwands belegen