Die MoSCoW-Methode ist eine Priorisierungstechnik, die in der Projektplanung, Softwareentwicklung und Geschäftsanalyse eingesetzt wird. Sie hilft dabei, Anforderungen anhand ihrer Bedeutung und Dringlichkeit zu priorisieren und ermöglicht Projektmanagern, Ressourcen und Budget entsprechend zuzuweisen. In diesem Artikel werden wir die MoSCoW-Methode untersuchen und ein Beispiel für ihre Umsetzung bereitstellen.
Was ist die MoSCoW-Methode?
Die MoSCoW-Methode ist eine Priorisierungstechnik, die Anforderungen in vier Kategorien einteilt: Muss-haben, Soll-haben, Könnte-haben und Werden-nicht-haben. Das Akronym MoSCoW steht für:
- Muss haben:kritische Anforderungen, die für den Erfolg des Projekts unerlässlich sind. Diese Anforderungen sind obligatorisch und müssen in den Projektumfang aufgenommen werden.
- Soll haben:wichtige Anforderungen, die für den Erfolg des Projekts notwendig sind, aber bei Bedarf verschoben werden können. Diese Anforderungen sind wichtig, aber nicht kritisch, und können auf eine spätere Phase des Projekts verschoben werden.
- Könnte haben:wünschenswerte Anforderungen, die für den Erfolg des Projekts nicht unbedingt erforderlich sind, aber den Wert des Projekts steigern können. Diese Anforderungen sind optional und können bei ausreichender Zeit und Budgetzusage eingeschlossen werden.
- Werden nicht haben:Anforderungen, die für den Erfolg des Projekts nicht erforderlich sind und nicht in den Projektumfang aufgenommen werden.
Die MoSCoW-Methode hilft Projektmanagern, Anforderungen anhand ihrer Bedeutung und Dringlichkeit zu priorisieren. Sie ermöglicht es ihnen, sich auf die kritischen Anforderungen zu konzentrieren und Ressourcen und Budget entsprechend zuzuweisen.
Beispiel für die MoSCoW-Methode
Betrachten wir ein Beispiel für ein Softwareentwicklungsprojekt, um zu verstehen, wie die MoSCoW-Methode funktioniert.
Angenommen, ein Unternehmen möchte eine neue Mobile-App für seine Kunden entwickeln. Die App soll Kunden ermöglichen, Produkte zu bestellen, ihre Bestellungen zu verfolgen und Benachrichtigungen zu erhalten. Das Unternehmen möchte außerdem einige zusätzliche Funktionen hinzufügen, um die App für Kunden attraktiver zu gestalten.
Das Projektteam identifiziert die folgenden Anforderungen:
- Muss haben: Die App muss Kunden ermöglichen, Produkte zu bestellen, ihre Bestellungen zu verfolgen und Benachrichtigungen zu erhalten.
- Soll haben: Die App sollte eine Suchfunktion haben, die Kunden ermöglicht, nach Produkten zu suchen, und eine Zahlungsfunktion, die Kunden erlaubt, ihre Bestellungen mit verschiedenen Zahlungsmethoden zu bezahlen.
- Könnte haben: Die App könnte eine Treueprogrammfunktion haben, die Kunden für ihre Käufe belohnt, und eine Empfehlungsprogrammfunktion, die Kunden motiviert, die App ihren Freunden und Familie zu empfehlen.
- Werden nicht haben: Die App wird keine Funktion zur Integration mit sozialen Medien haben, die Kunden ermöglicht, ihre Käufe auf sozialen Medienplattformen zu teilen.
Mit der MoSCoW-Methode hat das Projektteam die Anforderungen anhand ihrer Bedeutung und Dringlichkeit priorisiert. Die Muss-haben-Anforderungen sind für den Erfolg des Projekts entscheidend und müssen in der App enthalten sein. Die Soll-haben-Anforderungen sind wichtig, können aber bei Bedarf auf eine spätere Phase des Projekts verschoben werden. Die Könnte-haben-Anforderungen sind optional und können bei ausreichender Zeit und Budgetzusage eingeschlossen werden. Die Werden-nicht-haben-Anforderungen sind für den Erfolg des Projekts nicht erforderlich und werden nicht in den Projektumfang aufgenommen.
Realitätsnahes Beispiel – CRM-System
Projektbeschreibung: Entwicklung eines Customer Relationship Management (CRM)-Systems
Das Ziel dieses agilen Projekts ist die Entwicklung eines CRM-Systems für ein kleines Unternehmen, das sich auf die Bereitstellung maßgeschneiderter Lösungen für seine Kunden spezialisiert. Das CRM-System soll den Verkaufsprozess optimieren und die Kundeninteraktionen verbessern, um die Kundenzufriedenheit und -treue zu steigern.
Das Projekt wird die agile Methodik verfolgen, die eine iterative und inkrementelle Entwicklung beinhaltet. Das agile Team wird eng mit dem Kunden zusammenarbeiten, um Anforderungen zu sammeln, Prototypen zu entwickeln und funktionale Software-Updates in kurzen Iterationen, typischerweise zwei Wochen, zu liefern.
Erstellen einer Liste von Benutzerstories
Um die Liste der Benutzerstories zu erstellen, können Sie die verschiedenen Rollen berücksichtigen, die mit dem System interagieren werden, wie Vertriebsmitarbeiter, Manager und Kunden, und über die verschiedenen Aufgaben nachdenken, die sie ausführen müssen, um ihre Ziele zu erreichen. Sie können auch die verschiedenen Datentypen berücksichtigen, die im System gespeichert und verwaltet werden müssen, wie Kundendaten, Verkaufsdaten und Marketingkampagnen.
Aufgrund dieser Analyse können Sie dann eine Liste von Benutzerstories erstellen, die eine breite Palette an Funktionen abdeckt, von der Lead-Verfolgung und Kundenservice bis hin zu Verkaufsangeboten und Berichten. Die Liste der Benutzerstories soll als Ausgangspunkt für das Entwicklungsteam dienen, um die Priorisierung und Planung der Entwicklung des CRM-Systems vorzunehmen.
Hier ist eine Liste von Benutzerstories für das CRM-System-Entwicklungsprojekt:
- Als Vertriebsmitarbeiter möchte ich in der Lage sein, alle meine Leads an einem Ort zu verfolgen, damit ich meine Verkaufsschleife leicht verwalten kann.
- Als Verkaufsleiter möchte ich in der Lage sein, den Fortschritt meines Teams in Echtzeit zu sehen und zu überwachen, damit ich bei Bedarf Coaching und Unterstützung anbieten kann.
- Als Kundenservice-Mitarbeiter möchte ich in der Lage sein, alle Interaktionen eines Kunden mit unserem Unternehmen einzusehen, damit ich personalisierte Unterstützung anbieten kann.
- Als Marketingleiter möchte ich in der Lage sein, unsere Kunden anhand ihrer Vorlieben und ihres Verhaltens zu segmentieren, damit ich sie mit relevanten Kampagnen ansprechen kann.
- Als Kunde möchte ich in der Lage sein, meine Kaufhistorie und Kontoinformationen einzusehen, damit ich meine Beziehung zum Unternehmen leicht verwalten kann.
- Als Kundenservice-Mitarbeiter möchte ich in der Lage sein, Kundenbeschwerden und Anfragen zu protokollieren und zu verfolgen, damit ich sicherstellen kann, dass sie zeitnah bearbeitet werden.
- Als Vertriebsmitarbeiter möchte ich in der Lage sein, Angebote und Vorschläge schnell und einfach zu erstellen, damit ich Deals schneller abschließen kann.
- Als Administrator möchte ich in der Lage sein, Benutzerberechtigungen und Zugriffsebenen zu verwalten, damit ich steuern kann, wer auf vertrauliche Informationen zugreifen darf.
- Als Vertriebsmitarbeiter möchte ich in der Lage sein, Termine mit meinen Kunden zu planen und zu verwalten, damit ich organisiert bleibe und meinen Zeitplan im Blick behalte.
- Als Manager möchte ich in der Lage sein, Berichte über Verkaufsleistung, Kundenzufriedenheit und andere Kennzahlen zu erstellen, damit ich fundierte geschäftliche Entscheidungen treffen kann.
Diese Benutzerstories decken eine Vielzahl von Funktionen ab, die das CRM-System bereitstellen sollte. Das Entwicklerteam kann diese Benutzerstories nutzen, um die wichtigsten Funktionen für das System zu priorisieren und sicherzustellen, dass das System die Bedürfnisse aller Beteiligten erfüllt.
In Tabellenform präsentieren wir eine klare und präzise Zusammenfassung der 10 Benutzerstories im Zusammenhang mit einem Geschäftszenario, um einen Überblick über die Benutzerstories zu geben.
| Benutzerstory | Benutzerrolle | Ziel |
|---|---|---|
| 1 | Vertriebsmitarbeiter | Alle Leads an einem Ort verfolgen, um die Verkaufsschleife zu verwalten |
| 2 | Verkaufsleiter | Den Fortschritt des Teams in Echtzeit einsehen und überwachen, um Coaching und Unterstützung zu gewährleisten |
| 3 | Kundenservice-Mitarbeiter | Alle Kundeninteraktionen einsehen, um personalisierte Unterstützung zu gewährleisten |
| 4 | Marketingleiter | Kunden anhand von Vorlieben und Verhalten segmentieren, um gezielte Kampagnen durchzuführen |
| 5 | Kunde | Kaufhistorie und Kontoinformationen einsehen, um die Verwaltung zu erleichtern |
| 6 | Kundenservice-Mitarbeiter | Protokollieren und Verfolgen von Kundenbeschwerden und Anfragen zur zeitnahen Lösung |
| 7 | Verkaufsmitarbeiter | Angebote und Vorschläge schnell und einfach erstellen, um Geschäftsvorfälle schneller abzuschließen |
| 8 | Administrator | Benutzerberechtigungen und Zugriffsebenen für sensible Informationen verwalten |
| 9 | Verkaufsmitarbeiter | Termine mit Kunden planen und verwalten, um strukturiert zu arbeiten |
| 10 | Manager | Berichte über Verkaufsleistung, Kundenzufriedenheit und andere Kennzahlen erstellen, um fundierte geschäftliche Entscheidungen zu treffen |
Die Tabelle enthält Informationen zum Benutzerrollen, dem spezifischen Ziel, das sie erreichen möchten, und der Benutzerstory-Nummer, um jede Story leicht referenzieren zu können. Durch die Organisation der Benutzerstories in einer Tabelle ist es einfacher, die Funktionen zu verstehen und zu priorisieren, die entwickelt werden müssen, um die Bedürfnisse der am Projekt beteiligten Stakeholder zu erfüllen. Diese Tabelle kann als Referenz für das Entwicklungsteam dienen, um Funktionen zu entwerfen und umzusetzen, die den Bedürfnissen der Endbenutzer und Stakeholder entsprechen.
Priorisieren Sie die Benutzerstories
Es ist wichtig, die Benutzerstories anhand ihres geschäftlichen Wertes und ihres Einflusses auf die Projektziele zu priorisieren. Dadurch wird sichergestellt, dass sich die Entwicklungsarbeit auf die wichtigsten und wertvollsten Funktionen konzentriert, und dass das Projekt termingerecht und innerhalb des Budgets abgeschlossen werden kann.
Die Priorisierung kann mit verschiedenen Techniken erfolgen, wie beispielsweise der MoSCoW-Methode, die Benutzerstories als „Muss-haben“, „Soll-haben“, „Könnte-haben“ und „Wird-nicht-haben“ einteilt. Benutzerstories, die als „Muss-haben“ klassifiziert sind, sind am kritischsten und sollten zuerst entwickelt werden, während „Soll-haben“ und „Könnte-haben“ später in nachfolgenden Iterationen oder Releases entwickelt werden können.
Hier ist eine Tabelle mit den zehn zuvor genannten Benutzerstories, inklusive der relevanten Informationen und der Priorisierung nach der MoSCoW-Methode:
Es ist wichtig, die Benutzerstories anhand ihres geschäftlichen Wertes und ihres Einflusses auf die Projektziele zu priorisieren. Dadurch wird sichergestellt, dass sich die Entwicklungsarbeit auf die wichtigsten und wertvollsten Funktionen konzentriert, und dass das Projekt termingerecht und innerhalb des Budgets abgeschlossen werden kann.
Die Priorisierung kann mit verschiedenen Techniken erfolgen, wie beispielsweise der MoSCoW-Methode, die Benutzerstories als „Muss-haben“, „Soll-haben“, „Könnte-haben“ und „Wird-nicht-haben“ einteilt. Benutzerstories, die als „Muss-haben“ klassifiziert sind, sind am kritischsten und sollten zuerst entwickelt werden, während „Soll-haben“ und „Könnte-haben“ später in nachfolgenden Iterationen oder Releases entwickelt werden können.
Hier ist eine Tabelle mit den zehn zuvor genannten Benutzerstories, inklusive der relevanten Informationen und der Priorisierung nach der MoSCoW-Methode:
| Benutzerstory | Beschreibung | Priorität |
|---|---|---|
| 1 | Als Verkaufsmitarbeiter möchte ich in der Lage sein, alle meine Leads an einem Ort zu verfolgen, damit ich meine Verkaufsschleife einfach verwalten kann. | Muss-haben |
| 2 | Als Verkaufsleiter möchte ich in der Lage sein, den Fortschritt meines Teams in Echtzeit zu sehen und zu überwachen, damit ich bei Bedarf Coaching und Unterstützung anbieten kann. | Muss-Haben |
| 3 | Als Kundenservice-Mitarbeiter möchte ich in der Lage sein, alle Interaktionen eines Kunden mit unserem Unternehmen einzusehen, damit ich maßgeschneiderte Unterstützung anbieten kann. | Muss-Haben |
| 4 | Als Marketingleiter möchte ich in der Lage sein, unsere Kunden anhand ihrer Vorlieben und ihres Verhaltens zu segmentieren, damit ich sie mit relevanten Kampagnen ansprechen kann. | Sollte-Haben |
| 5 | Als Kunde möchte ich in der Lage sein, meine Kaufhistorie und Kontoinformationen einzusehen, damit ich meine Beziehung zum Unternehmen einfach verwalten kann. | Sollte-Haben |
| 6 | Als Kundenservice-Mitarbeiter möchte ich in der Lage sein, Kundenbeschwerden und Anfragen zu protokollieren und zu verfolgen, damit ich sicherstellen kann, dass sie zeitnah bearbeitet werden. | Sollte-Haben |
| 7 | Als Verkaufsmitarbeiter möchte ich in der Lage sein, Angebote und Vorschläge schnell und einfach zu erstellen, damit ich Deals schneller abschließen kann. | Könnte-Haben |
| 8 | Als Administrator möchte ich in der Lage sein, Benutzerberechtigungen und Zugriffsebenen zu verwalten, damit ich steuern kann, wer auf vertrauliche Informationen zugreifen darf. | Könnte-Haben |
| 9 | Als Verkaufsmitarbeiter möchte ich in der Lage sein, Termine mit meinen Kunden zu planen und zu verwalten, damit ich organisiert bleibe und meinen Zeitplan im Blick behalte. | Könnte-Haben |
| 10 | Als Manager möchte ich in der Lage sein, Berichte über Verkaufsleistung, Kundenzufriedenheit und andere Kennzahlen zu erstellen, damit ich fundierte geschäftliche Entscheidungen treffen kann. | Wird-Nicht-Haben |
In dieser Tabelle sind die Benutzerstories in der Reihenfolge der Priorität aufgelistet, wobei zuerst die „Muss-Haben“-Funktionen aufgeführt sind, gefolgt von den „Sollte-Haben“ und „Könnte-Haben“. Das Feature „Wird-Nicht-Haben“ ist für dieses Projekt nicht geplant, könnte aber für zukünftige Entwicklungen in Betracht gezogen werden.
Durch die Priorisierung der Benutzerstories kann das Entwicklungsteam sicherstellen, dass die wichtigsten Funktionen zuerst entwickelt werden, was Wert für die Stakeholder schafft und es dem Projekt ermöglicht, seine Ziele innerhalb der Zeit- und Budgetgrenzen zu erreichen.
Beispiel: Ein Scrum-Entwicklungsplan für das CRM
Hier ist ein grober Überblick über einen Scrum-Entwicklungsplan, um das agile Projekt zu starten. Die konkreten Details des Plans hängen jedoch von den Projektanforderungen, der Teamstruktur und anderen Faktoren ab. Hier ist ein Beispiel für einen Scrum-Entwicklungsplan:
- Produkt-Backlog definieren: Der erste Schritt besteht darin, den Produkt-Backlog zu definieren, der eine priorisierte Liste aller Funktionen, Funktionalitäten und Anforderungen darstellt, die im Projekt umgesetzt werden müssen. Dieser Backlog wird während des gesamten Projekts gepflegt und kontinuierlich verfeinert und aktualisiert, basierend auf den sich ändernden Bedürfnissen der Stakeholder.
- Sprint-Planung durchführen: Nach der Definition des Produkt-Backlogs wird das Team eine Sprint-Planungssitzung durchführen, um eine Reihe von Benutzerstories aus dem Backlog auszuwählen, die im kommenden Sprint entwickelt werden sollen. Das Team wird die für jede Benutzerstory erforderliche Aufwandabschätzung vornehmen und die Benutzerstories auswählen, die innerhalb des Sprint-Zeitraums abgeschlossen werden können.
- Tägliche Scrum-Meetings durchführen: Sobald der Sprint begonnen hat, wird das Team tägliche Scrum-Meetings durchführen, um den Fortschritt zu überprüfen, mögliche Hindernisse oder Herausforderungen zu identifizieren und den Plan bei Bedarf anzupassen. Die täglichen Scrum-Meetings sollten kurz und fokussiert sein, wobei jedes Teammitglied einen Statusbericht über seinen Fortschritt abgibt.
- Produkt-Increment entwickeln: Während des Sprints wird das Team an der Entwicklung der ausgewählten Benutzerstories arbeiten und sich darauf konzentrieren, bis zum Ende des Sprints ein funktionsfähiges Produkt-Increment zu liefern. Das Team wird eng zusammenarbeiten, wobei Entwickler, Tester und andere Teammitglieder gemeinsam am Erreichen des Produkt-Increments arbeiten.
- Sprint-Review durchführen: Am Ende des Sprints wird das Team ein Sprint-Review-Meeting durchführen, um den Produkt-Increment den Stakeholdern vorzustellen, Feedback einzuholen und den während des Sprints erzielten Fortschritt zu überprüfen.
- Sprint-Retrospektive durchführen: Nach dem Sprint-Review wird das Team eine Sprint-Retrospektive durchführen, um den Sprint-Prozess zu überprüfen, Verbesserungsmöglichkeiten zu identifizieren und die Planung für den nächsten Sprint vorzunehmen.
- Den Prozess wiederholen: Das Team wird diesen Prozess für jeden nachfolgenden Sprint wiederholen, den Produkt-Backlog weiter verfeinern und aktualisieren und sich darauf konzentrieren, am Ende jedes Sprints ein funktionsfähiges Produkt-Increment zu liefern.
Dieser Scrum-Entwicklungsplan bietet einen Rahmen für die Steuerung des agilen Projekts mit regelmäßigen Meetings und Reviews, um sicherzustellen, dass das Projekt auf Kurs bleibt und Wert für die Stakeholder schafft.
Fazit
Der Artikel behandelt die MoSCoW-Methode, eine Priorisierungstechnik, die im agilen Projektmanagement verwendet wird, um Projektanforderungen zu priorisieren. Die MoSCoW-Methode teilt Anforderungen in vier Kategorien ein: Muss-haben, Soll-haben, Könnte-haben und Wird-nicht-haben. Der Artikel liefert ein praktisches Beispiel für ein agiles Projekt und zeigt, wie Benutzerstories für das Projekt identifiziert werden können. Die Benutzerstories werden anschließend mit der MoSCoW-Methode priorisiert, wobei die Must-have-Anforderungen höchste Priorität erhalten.
Der Artikel skizziert außerdem einen Scrum-Entwicklungsplan, der die Definition des Produkt-Backlogs, die Sprint-Planung, tägliche Scrum-Meetings, die Entwicklung des Produkt-Increments, das Sprint-Review, die Sprint-Retrospektive und die Wiederholung des Prozesses umfasst. Der Scrum-Entwicklungsplan bietet einen Rahmen für die Steuerung des agilen Projekts, stellt sicher, dass das Projekt auf Kurs bleibt, und sorgt dafür, dass Wert für die Stakeholder geschaffen wird.