Was ist die Muss Sollte Könnte Wird Nicht Priorisierungsmethode?
Unsere Handlungen sollten unsere Prioritäten ausdrücken, und Muss Sollte Könnte Wird Nicht ist eine hervorragende Sprint-Retrospektive-Vorlage, die Teams dabei hilft, diese Prioritäten zu identifizieren, um sicherzustellen, dass sie weiterhin dort Wert liefern, wo er am dringendsten benötigt wird. In diesem Sinne ist es ein Ansatz, der gut zu agilen Prozessen und Frameworks passt, da der Fokus auf der Bereitstellung wertvoller Dinge an erster Stelle liegt. Es ist auch eine großartige Scrum-Sprint-Retrospektive-Idee, da sie dem Product Owner einen Mechanismus bietet, sich in die Lage des Kunden zu versetzen und das Produkt aus deren Perspektive zu betrachten. Die in den 1990er Jahren von Dai Clegg entwickelte MSCW-Methode gewann im agilen Projektmanagement und in der Business-Analyse an Bedeutung. Sie bietet eine strukturierte Möglichkeit, Aufgaben in vier verschiedene Kategorien zu organisieren: Muss haben (kritisch), Sollte haben (wichtig), Könnte haben (erwünscht) und Wird nicht haben (keine Priorität).
Muss Sollte Könnte Wird Nicht Format
Muss
Dinge, die wir unbedingt tun müssen.
Dies sind nicht verhandelbare Anforderungen, die für den Erfolg entscheidend sind. Ermutigen Sie die Teilnehmer bei der Diskussion von 'Muss'-Elementen, echte Blocker oder wesentliche Elemente zu berücksichtigen, ohne die das Projekt scheitern würde.
Sollte
Dinge, die wir tun sollten.
Dies sind wichtige Funktionen oder Anforderungen, die einen erheblichen Mehrwert bieten, aber nicht kritisch für den Start sind. Leiten Sie das Team an, Elemente zu berücksichtigen, die schmerzhaft wären wegzulassen, aber das Projekt nicht am Funktionieren hindern würden.
Könnte
Dinge, die wir tun könnten.
Dies sind wünschenswerte Funktionen, die schön zu haben wären, wenn Ressourcen es zulassen. Helfen Sie dem Team, Verbesserungen zu identifizieren, die die Lösung verbessern würden, aber nicht essentiell sind.
Wird Nicht
Dinge, die wir nicht tun werden.
Dies sind Elemente, die für diese Iteration oder dieses Projekt ausdrücklich abgelehnt wurden. Fördern Sie eine ehrliche Diskussion über Funktionen, die zwar potenziell wertvoll sind, aber nicht mit den aktuellen Zielen oder Einschränkungen übereinstimmen.
Wann Sie diese Retrospektive verwenden sollten
- Bei der Planung eines neuen Projekts oder einer Initiative und der Notwendigkeit, klare Prioritäten festzulegen
- Während Backlog-Refinement-Sitzungen zur Organisation und Priorisierung von Feature-Anfragen
- Bei Ressourcenbeschränkungen und der Notwendigkeit, schwierige Entscheidungen über den Umfang zu treffen
Vorgeschlagene Fragen für den Icebreaker
- Was war die schwierigste Prioritätsentscheidung, die Sie in einem Projekt treffen mussten?
- Wenn Sie in Ihrem aktuellen Projekt nur drei Funktionen umsetzen könnten, welche wären das und warum?
Ideen und Tipps für Ihr Retrospektive-Meeting
- Beschränken Sie 'Muss'-Elemente auf höchstens 60% der Gesamtanforderungen, um einen realistischen Umfang zu behalten
- Überprüfen und überarbeiten Sie Kategorisierungen regelmäßig, wenn sich geschäftliche Anforderungen und Einschränkungen ändern
- Verwenden Sie Timeboxing während Diskussionen, um effiziente Entscheidungsfindung sicherzustellen
- Dokumentieren Sie die Begründung hinter Kategorisierungen für Klarheit und Konsistenz
Neu bei Retrospektiven? Lesen Sie unseren Leitfaden für die Durchführung einer Retrospektive →.
Verwandte Vorlagen
Sammeln Sie praktisches Feedback zu Ihrem Sprint Review-Prozess.
Rose Bud Thorn Retrospektive
Ein naturinspiriertes Reflexionsframework zur Identifizierung von Erfolgen, Chancen und Herausforderungen.
Was? Na und? Was nun? Retrospektive
Ein strukturierter Reflexionsrahmen für systematische Problemanalyse und Aktionsplanung
FLAP Retrospektive
Ein strukturierter Reflexionsrahmen mit Fokus auf Zukunftsplanung und Lernen aus der Vergangenheit