Emendare
  • Agile Unternehmensberatung
    • Methode
    • Prinzipien
  • Agile Coaching
  • Agile Workshops
  • Agile Training
    • Agile – Grundlagen Training
    • Agile Führung – Grundlagen
    • Agile Führung – Advanced
    • Scrum Master – CSM
    • Scrum Master – A-CSM
    • Scrum Master – CSP-SM
    • Scrum Master Mikro Trainings
    • Agiles Produkt Management – CSPO | A-CSPO | CSP-PO
  • Agiles Arbeiten
    • Was ist Scrum?
    • Was macht ein Scrum Master?
    • Was macht ein Product Owner?
    • Agile Führung – Was macht eine Agile Führungskraft?
    • Dialogische Unternehmenskultur
  • Unser Team
  • Suche
  • Menü Menü

Der Weg zu einer guten Priorisierung ist weit. Manchmal führt er über MoSCoW

Agile Brainfood, Allgemein, Methoden, Produkt
gutes Priorisieren

Fragt man Anforderer nach „Was genau brauchst du? Welche Inhalte müssen gebaut werden?“, dann kann die Antwort schnell mit einem „Alles“ abgetan werden.
Bei einem größeren Featurewunsch „Alles“ liefern zu wollen, kann schnell zu einem langwierigen Prozess werden. Gelingt es einem Team zudem nicht, iterative Zwischenschritte zu liefern, verkommt die Entwicklung schnell zu einem Wasserfallprozess ohne Feedbackschleifen.
Henrik Kniberg bringt es in seinem Video „Agile Product Ownership in a Nutshell“ schön auf den Punkt. Frei zitiert: „Entweder wir liefern dir alle Featurewünsche, die du hast bis Zeitpunkt X, oder die wichtigen Features in der Hälfte der Zeit. Die anderen Features können wir dann immer noch liefern, wenn sie dann noch wichtig sind.“

Es gilt also gemeinsam mit dem Kunden oder Anforderungssteller herauszufinden, welche Teile einer Anforderung entscheidend sind und welche „nur“ die Kirsche auf der Sahnetorte darstellen.

Priorisierung mit MoSCoW

Ein einfaches Werkzeug, hierfür ist MoSCoW. Das Acronym hilft, sich 4 Ebenen der Anforderungswichtigkeit zu merken:

M (Must Criteria) –

Die Muss-Kriterien, welche den entscheidenden Mehrwert der Anforderung enthalten. Ein großer Fokus auf MVP (Minimal Viable Product) oder das Pareto Prinzip (20% der Anforderungen erzeugen 80% des Nutzermehrwertes) kann hier helfen die Aufwände zu minimieren, die auf dieses Prioritätslevel anfallen.

o

S (Should Criteria) –

Sollte-Kriterien beschreiben all die Wünsche, die schon da sein sollten. Es darf gern auch schmerzhaft sein, Kriterien hier einzuordnen. Sei es, dass der Nutzer einzelne Dinge weiterhin manuell machen muss oder Fremdsysteme eingebunden werden müssen. Sobald der Fokus nicht mehr auf den Muss-Kriterien liegt (etwa weil diese bereits erledigt sind), kann sich ein Entwicklungsteam immer noch an die Sollte Kriterien machen.

C (Could Criteria) –

Hier finden sich all die Aufwände, welche optional sind, also umgesetzt werden „könnten“. Optionale Anforderungen sollten nicht prinzipiell abgetan werden nach dem Motto „Dafür haben wir eh keine Zeit“, sondern genug Beachtung und wirtschaftliche Betrachtung erfahren, um den Kunden zu begeistern. Ich empfehle hierfür sich etwas mit dem „Kano-Modell“ auseinander zu setzen.

o

W (Won’t Criteria) –

Kann man schon zu Beginn aus technisch, fachlich oder wirtschaftlicher Sicht ausschließen Dinge zu entwickeln, kann man sich eine nähere Betrachtung oder Product Backlog Refinement dieser Anforderungen direkt sparen und die gewonnene Zeit direkt in die nächsten Kundenwünsche stecken.

Das zehnte Prinzip hinter dem Agilen Manifest (Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell) perfekt zu leben ist wohl die Königdisziplin eines jeden Product Owners.

Hat euer Team auch Herausforderungen, nicht getane Arbeit zu maximieren? Sicher hilft ein kurzes Telefonat mit einem Emendator hier weiter!

Weitere spannende Beiträge findet ihr hier!

5. Oktober 2021/von Veit Richter
Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf Twitter
  • Teilen auf WhatsApp
  • Teilen auf LinkedIn
  • Per E-Mail teilen
Das könnte Dich auch interessieren
Burnup Charts Magische Burnup Charts und wo sie zu finden sind
Carpaccio Den Elefanten in dünne Scheiben schneiden?
Array
Veit Richter
Veit Richter
Agile Coach

Gerne begleite ich Ihre Teams sowohl beim Lernen agiler Praktiken, als auch auf ihrem Weg zur High-Performance. Dabei unterstütze ich sie mit pragmatischen Lösungsstrategien und biete neben meiner Skalierungserfahrung auch Impulse zum Entfesseln positiver Kräfte.

veit.richter@emendare.de

Alle Beiträge von Veit Richter

Letzte Beiträge des Autors

Array
  • Haben „Technische User Stories“ eine Existenzberechtigung?
  • Die Hamburger Methode – technischen Umfang beschränken
  • Was, wenn einmal der Scrum Master krank ist?
  • 1,2 oder 4 Wochen? Wie lang sollte ein Sprint eigentlich sein?
  • Magische Burnup Charts und wo sie zu finden sind

Kontakt

Emendare GmbH & Co. KG
Karlstraße 87
76137 Karlsruhe

Tel.: +49 (0)721 170 280 08
Email: info@emendare.de

Service

Trainingsbuchung

Impressum

Datenschutzerklärung

Allgemeine Geschäftsbedingungen

Mehr von Emendare

Nachhaltigkeit bei Emendare

Die „FrischerBlick“-Roadmap – eine Retrospektivenmethode für...FrischerBlick Roadmap Fibonacci Folge auf Emendare Schätzkarten Magic Estimation – To complexity and beyond!
Nach oben scrollen