Es gibt zahlreiche Priorisierungstechniken, die unterschiedliche Probleme lösen sollen. Wahrscheinlich hast du schon irgendeine Form der Wert-vs.-Aufwand-Priorisierung verwendet, zum Beispiel RICE. Vielleicht hast du sogar mal deine Zielgruppe mit einer gezielt konzipierten Umfrage befragt, etwa mit dem KANO-Modell. Jede Priorisierungstechnik hat ihre Anwendungsfälle und möglicherweise haben sie dir schon bei vielen nützlichen Entscheidungen geholfen.
Aber diese Strategien sind für eine übergeordnete Art der Priorisierung gedacht – also um zu entscheiden, ob du zuerst Feature A oder Feature B umsetzen solltest oder ob Feature C überhaupt in die nächste Version gehört. Sie skalieren aber nicht auf Aufgaben oder gar Unteraufgaben deiner Features herunter, sodass man bei einem bestimmten Feature durchaus zu viel tun kann. Außerdem helfen sie nicht bei der Frage, wann du das Feature in die Hände der Nutzer geben kannst, um frühes Feedback zu sammeln und nutzerzentrierte Ansätze wie die Lean-Startup-Methodik anzuwenden. Man könnte natürlich eine skalenunabhängige Methode wählen, wie die MoSCoW-Methode, aber deren Kategorien wären nicht einfach einzuordnen, weil sie so abstrakt sind, dass verschiedene Personen unterschiedliche Erwartungen an jede Kategorie hätten.
Das Ziel der Laser-Focus-Priorisierungsstrategie ist es, klare Bewertungskategorien bereitzustellen, beim Aufgabenumfang zu helfen und eine einfach anwendbare Interpretationsmethode zu bieten. Alle drei Aspekte zusammen helfen dir, den Fokus zu behalten.
Laser-Focus-Kategorien
Es gibt drei Ziele, die wir mit unseren Kategorien erreichen wollen:
Entscheiden, welche Aufgaben im Umfang des aktuell geplanten Releases liegen.
Aufgaben, die für eine Alpha- oder Beta-Version nötig sind, höher priorisieren als andere.
Die Kategorienamen sollen eine handlungsorientierte, eigenständige Bedeutung haben.
Wir schlagen folgende Kategorien vor, die alle Anforderungen erfüllen:
Vital
Absolutes Minimum, das für die erste Testrunde nötig ist. Darf hässlich sein.
Damit kann ein Produkt mit nur den „Vital”-Features oder -Aufgaben an eine kleine Gruppe von Testern ausgeliefert werden, um frühes Feedback zu bekommen. Natürlich sollte der Umfang dieses Alpha-Tests klar kommuniziert werden – also welche grundlegenden Features oder Aufgaben noch fehlen, damit sie nicht unnötig von den Testern gemeldet werden. Aber die vitalen Teile des Produkts oder Features können schon getestet werden und wir bekommen die erste Runde Feedback, die zeigt, ob wir in die richtige Richtung gehen.
Essential
Kernaspekte, die für die grundlegende Funktionalität nötig sind. Darf raue Kanten haben.
Eine zweite, größere Testrunde kann gestartet werden, sobald alle „Essential”-Features oder -Aufgaben umgesetzt sind. Auf dieser Stufe muss kein konkreter Testumfang kommuniziert werden – es reicht, die Version als „Beta” zu bezeichnen, bei der die Grundfunktionen verfügbar sind, aber noch vieles fehlt oder unvollständig ist.
Completing
Raue Kanten glätten und Funktionalitäten vervollständigen.
Die „Completing”-Stufe definiert den Umfang, bei dem das finale Produkt bereit für das Release ist. In manchen Situationen, z. B. wenn eine neue Version für ein bestimmtes Datum angekündigt wurde, kann das Produkt auch veröffentlicht werden, während noch einige „Completing”-Aufgaben offen sind – dann sollte es aber öffentlich als „Beta” gekennzeichnet werden. Typischerweise umfasst diese Stufe alle Features oder Aufgaben, die für eine größere Nutzerbasis wichtig sind, aber für die Bewertung des Kerns des Produkts nicht relevant sind.
Optional
Nice-to-haves, die auf spätere Versionen verschoben oder ganz weggelassen werden können.
Die „Optional”-Stufe drückt aus, dass die so bewerteten Features oder Aufgaben zwar gewünscht sind, aber in keiner Weise nötig, um eine fertige Version eines Produkts zu veröffentlichen – auch langfristig nicht. Daher können sie bei Bedarf je nach Ressourcen des Teams einfach verschoben oder gestrichen werden.
Retracting
Nice-to-haves (auf den ersten Blick), die (potenziell) mehr schaden als nützen können.
Anders als „Optional” sollten Features oder Aufgaben, die als „Retracting” bewertet werden, aktiv vermieden werden. Das heißt, es kann sinnvoll sein, sie inklusive der Begründung, warum sie vermieden werden sollten, für langfristige Entscheidungsfindung zu dokumentieren. Das spart Zeit, wenn dieselbe Idee irgendwann in der Zukunft wieder aufkommt. Außerdem kann es bei der Bewertung durch mehrere Personen helfen, die Aufgaben zu identifizieren, bei denen eine Diskussion nötig ist, um die Auswirkung einer Aufgabe auf das Produkt zu klären.
Laser-Focus-Matrix
Die zweite Säule der Laser-Focus-Strategie ist ihre mehrdimensionale Skalierbarkeit. Um zu erklären, was das bedeutet und warum es wichtig ist, wenden wir die bisherigen Kategorien an einem Beispiel an: Lass uns eine Stoppuhr-App entwickeln, die die Zeit für verschiedene Tätigkeiten über den Tag hinweg erfasst. Das ist die anfängliche Liste der Feature-Ideen, bewertet mit den Laser-Focus-Kategorien:
Projekte erstellen → Essential (essentiell für die App, aber vorgefüllte Projekte reichen für den ersten Test)
Projekte bearbeiten → Completing (für Testzwecke nicht nötig, aber für das finale Release)
Projekte löschen → Completing (Aufräumaufgabe, für Tests nicht nötig, aber für das finale Release)
Timer starten/stoppen → Vital (Kernidee der App, vitaler Teil)
Ein Projekt für den Timer auswählen → Vital (ohne Projektauswahl ist die App-Idee nicht erfüllt)
Vergangene erfasste Zeiten bearbeiten → Retracting (V2 mit Wettbewerbs-Feature geplant, Risiko von Manipulation)
Vergangene erfasste Zeiten löschen → Optional (nice to have, kein Manipulationsrisiko, da keine Zeit hinzugefügt wird)
Historische erfasste Zeit für ein ausgewähltes Projekt anzeigen → Essential (Kernanwendungsfall der App)
Projekte mit der meisten erfassten Zeit anzeigen → Essential (Kernanwendungsfall der App)
Dank der Kategorisierung können wir schon zwei Features aus dem ersten Release ausschließen und haben sogar ein Feature erkannt, das wir wahrscheinlich nie umsetzen sollten (6) und das dauerhaft dokumentiert werden sollte. Aber noch wichtiger: Wir wissen jetzt, dass 4 und 5 die „Vital”-Features sind, die zuerst umgesetzt werden müssen.
Fangen wir an, an ihren Unteraufgaben zu arbeiten:
4. Timer starten/stoppen: (Vital)
a. Start/Stop-Button-Layout designen (Low Fidelity) b. Start/Stop-Button-Farben & Icons designen (High Fidelity) c. Start/Stop-Button pulsierenden Schatteneffekt designen (Animationen) d. Start/Stop-Button-Layout implementieren (Low Fidelity) e. Start/Stop-Button-Farben & Icons implementieren (High Fidelity) f. Start/Stop-Button pulsierenden Schatteneffekt implementieren (Animationen) g. Grundlegende Datenbankmodelle für erfasste Zeiten aufsetzen h. Start/Stop-Aktionen in der Datenbank persistieren
5. Ein Projekt für den Timer auswählen: (Vital)
a. Projektauswahl-Navigation & Layout designen (Low Fidelity) b. Projektauswahl-Formen, Farben & Icons designen (High Fidelity) c. Projektauswahl-Navigation & Layout implementieren (Low Fidelity) d. Projektauswahl-Formen, Farben & Icons implementieren (High Fidelity) e. Ausgewähltes Projekt im Datenbankmodell für erfasste Zeiten persistieren
Alles klar, legen wir los, oder? Oder?
Nein. Du hast es sicher schon beim Lesen bemerkt. Es gibt ein Problem. Wir haben die Features priorisiert und darüber nachgedacht, was wirklich nötig ist, um testbar zu sein, um die App in die Hände der Nutzer zu geben. Aber jetzt haben wir dasselbe Problem wieder, nur auf einer anderen Ebene. Diese Aufgaben (und potenziell auch ihre Unteraufgaben) sind nicht alle „Vital” für unsere allererste Version, die wir in die Hände der Nutzer geben wollen. Wie können wir das lösen? Sollten wir eine weitere Bewertung für die Aufgaben durchführen?
Ja, unbedingt! Das ist sogar eine Anforderung der Laser-Focus-Strategie: Wende die Bewertung auf allen Ebenen nach unten hin an! Nicht unbedingt auf höheren Ebenen, wo du jede beliebige alternative Priorisierungstechnik verwenden darfst. Aber die tieferen Ebenen ab dem Punkt, an dem du anfangen willst, sollten alle so bewertet werden.
Weisen wir den Aufgaben also auch die Laser-Focus-Kategorien zu und schauen dann, was das für die Gesamtpriorität bedeutet:
4. Timer starten/stoppen: (Vital)
a. Start/Stop-Button-Layout designen (Low Fidelity) → Vital b. Start/Stop-Button-Farben & Icons designen (High Fidelity) → Completing c. Start/Stop-Button pulsierenden Schatteneffekt designen (Animationen) → Optional d. Start/Stop-Button-Layout implementieren (Low Fidelity) → Vital e. Start/Stop-Button-Farben & Icons implementieren (High Fidelity) → Completing f. Start/Stop-Button pulsierenden Schatteneffekt implementieren (Animationen) → Optional g. Grundlegende Datenbankmodelle für erfasste Zeiten aufsetzen → Essential h. Start/Stop-Aktionen in der Datenbank persistieren → Essential
5. Ein Projekt für den Timer auswählen: (Vital)
a. Projektauswahl-Navigation & Layout designen (Low Fidelity) → Vital b. Projektauswahl-Formen, Farben & Icons designen (High Fidelity) → Completing c. Projektauswahl-Navigation & Layout implementieren (Low Fidelity) → Vital d. Projektauswahl-Formen, Farben & Icons implementieren (High Fidelity) → Completing e. Ausgewähltes Projekt im Datenbankmodell für erfasste Zeiten persistieren → Essential
Wichtig: Der Bezugswert für die Bewertung der Aufgaben war das Feature, weil es das direkte Elternelement ist. Das heißt, ich habe mir die Frage gestellt: „Ist das Persistieren von Start/Stop-Aktionen in der Datenbank vital oder essential für das Feature Timer starten/stoppen?” – und nicht für die App oder irgendetwas anderes. Das macht die Beantwortung der Fragen deutlich einfacher.
Visualisieren wir diese zwei verschiedenen Bewertungsebenen mit einer einfachen Matrix. Auf der X-Achse sind die Bewertungen der Features. Auf der Y-Achse die Bewertungen der Aufgaben. Die Kreise stellen die Aufgaben dar:
Wie du sehen kannst, befinden sich die Aufgaben 4a, 4d, 5a und 5c im Feld unten links, dem „Vital-Vital”-Feld, kurz „VV”. Der Hintergrund des Feldes ist rot eingefärbt. Es enthält alle Aufgaben, auf die man sich zuerst konzentrieren sollte. Sobald sie alle umgesetzt sind, kann die allererste Testrunde beginnen und die Alpha-Phase startet.
Die Aufgaben 4g, 4h und 5e im gelb eingefärbten Feld „Vital-Essential” oder kurz „VE” sollten als Nächstes angegangen werden. Sobald alle Aufgaben in allen drei gelb eingefärbten Feldern (VV, VE, EV) abgeschlossen sind, beginnt die Beta-Phase.
Das „VC”-Feld mit seinen „Completing”-Aufgaben für die „Vital”-Features sollte unter den bisher definierten Aufgaben zuletzt angegangen werden. Sobald alle Aufgaben in allen grün eingefärbten Feldern (VC, CV, EC, CE, CC) erledigt sind, ist es Release-Zeit.
Im obigen Beispiel haben wir die Aufgaben für alle nicht-vitalen Features übersprungen. Hätten wir sie auch bewertet, hätte die vollständige Matrix etwa so aussehen können, einschließlich der „Retracting”-Bewertung:
Wir können sehen, wie die Alpha-, Beta- und Release-Aufgaben kreisförmig um den Ursprungspunkt (unten links) geschichtet sind und uns visuell eine Priorität für jede Aufgabe basierend auf ihrem Abstand zum Ursprung geben. Das skaliert problemlos auf eine dritte Achse, wenn zum Beispiel Unteraufgaben zu jeder Aufgabe hinzukommen. Formal gesprochen skaliert das auf beliebig viele Dimensionen. Um die Gesamtkategorie eines bestimmten Elements zu berechnen, schau dir einfach alle Vorfahren an und wähle die niedrigste Priorität als Gesamtkategorie des „atomaren” (untersten) Elements. Stell dir zum Beispiel eine Unteraufgabe mit der Kategoriebewertung „Essential” vor, einer übergeordneten Aufgabe mit „Vital” und deren übergeordnetem Feature mit „Completing”. Insgesamt ist die niedrigste Priorität „Completing”, also ist das die Gesamtkategorie der Unteraufgabe.
Die Berechnung der Gesamtkategorie allein kann dazu führen, dass viele Aufgaben auf derselben Stufe landen, besonders bei „Completing”, wo wir 5 verschiedene Felder haben. Eine Möglichkeit, Features oder Aufgaben innerhalb derselben Kategorie zu priorisieren, ist die Berechnung des Durchschnitts aus der eigenen Kategorie und der aller Vorfahren-Kategorien. Dazu weisen wir jeder Kategorie eine Zahl zu (von 1 „Vital” bis 5 „Retracting”), die unterste Ebene (z. B. eine Unteraufgabe) kann dann als Tupel dargestellt werden, z. B. (2, 1, 3) im obigen Beispiel. Der Durchschnitt dieser Zahlen wird einfach berechnet: (2 + 1 + 3) / 3 = 2.0. Eine andere Aufgabe mit mehr Vorfahren und derselben Gesamtkategorie „Completing” könnte als (3, 2, 3, 1) bewertet sein und hätte daher einen Durchschnitt von (3 + 2 + 3 + 1) / 4 = 2.25, sollte also niedriger priorisiert werden. Je höher der Gesamtdurchschnitt, desto niedriger die Priorität – das ergibt viel Sinn, da die Durchschnittszahl in etwa den Abstand zum Ursprung widerspiegelt – der höchstmöglichen Priorität.
Aber keine Sorge, du musst diese Durchschnitte nicht tatsächlich berechnen. Es gibt einen einfacheren Weg basierend auf der Matrix, die wir oben gesehen haben, mit ausreichender Genauigkeit:
Das obige Diagramm zeigt, in welcher Reihenfolge die Felder bearbeitet werden sollten, basierend auf dem Abstand zum Ursprung. Beachte, dass es jeweils zwei Felder auf Platz 2, 4 und 5 gibt. Für diese Felder muss je nach Situation eine Entscheidung getroffen werden: Sollten wir uns mehr darauf konzentrieren, weitere Features hinzuzufügen? Oder sollten wir uns mehr darauf konzentrieren, die bereits begonnenen Features zu verbessern? Für eine Feature-Erweiterung zuerst solltest du in Richtung der „Feature-Kategorie” weitermachen, z. B. „EV” vor „VE”. Für die Verbesserung bestehender Features zuerst sollte es andersherum sein.
Laser-Focus-Aufschlüsselung
Im obigen Abschnitt haben wir gelernt, dass die Kategorisierung auf mehreren Ebenen der Schlüssel zum Laser-Focus-Konzept ist. Wenn du das direkt auf dein Projekt anwenden willst, wirst du vielleicht feststellen, dass viele oder sogar alle deine Features oder Aufgaben für dich eigentlich „Vital” oder „Essential” sind. Wenn das der Fall ist, dann ist es ein Zeichen dafür, dass du deine Aufgaben wahrscheinlich noch nicht effizient aufgeteilt hast.
Deshalb ist es wichtig, deine Aufgaben richtig herunterzubrechen, bevor du sie kategorisierst. Die Leitfrage, die du dir beim Aufteilen von Features in Aufgaben oder Aufgaben in Unteraufgaben stellen solltest, sollte nicht nur sein: „Welche Schritte muss ich machen, um es fertigzustellen?” Du solltest auch den Aufwand für jeden Schritt bedenken, und wenn der Aufwand nicht vernachlässigbar klein ist, solltest du in Betracht ziehen, ihn abzutrennen. Manchmal mag das schwierig erscheinen, aber meistens ist es eine gute Idee, dem Ansatz „erst zum Laufen bringen, dann verbessern” beim Aufteilen der Aufgaben zu folgen.
Beim obigen Feature „Timer starten/stoppen” hätten wir zum Beispiel in 3 Aufgaben aufteilen können: „Start/Stop-Buttons designen”, „Start/Stop-Buttons implementieren” und „Daten persistieren”. Das Problem dabei ist, dass es keine verschiedenen Fertigstellungsstufen gibt. Es ist besser, noch weiter herunterzubrechen. Natürlich könnten wir das als Unteraufgaben unter diesen Aufgaben tun, aber um die Prioritätsberechnung einfacher zu machen, empfiehlt es sich, es auf weniger Ebenen zu tun. Also haben wir uns stattdessen für „Start/Stop-Button-Layout designen”, „Start/Stop-Button-Layout implementieren” entschieden und dieselben zwei Aufgaben auch für „… Farben & Icons” und „… pulsierender Schatteneffekt”.
Frag dich, welche Teile ihren eigenen Aufwand haben, und teile sie so auf, dass jede Aufgabe es wert ist, basierend auf dem nötigen Aufwand priorisiert zu werden. Trenne keine Mikroaufgaben ab – es lohnt sich nicht, so kleine Aufgaben zu priorisieren; behalte sie einfach als Teil einer anderen Aufgabe.
Eine ordentliche Aufschlüsselung ist sehr wichtig, damit die Laser-Focus-Strategie effektiv ist.
Zusammenfassung
Fassen wir die Laser-Focus-Priorisierungsstrategie in der richtigen Reihenfolge zusammen:
Brich deine Features und Aufgaben in kleinere Schritte mit verschiedenen Fertigstellungsstufen herunter
Bewerte sie auf jeder Ebene mit „Vital”, „Essential”, „Completing”, „Optional” oder „Retracting”
Visualisiere oder berechne die Gesamtpriorität für die unterste Ebene unter Berücksichtigung aller Vorfahren
Wende diese Schritte zu jedem beliebigen Zeitpunkt in deinem Projekt an und sie werden dir helfen, dich auf die wichtigen Dinge zu konzentrieren und deine In-Arbeit-Versionen so früh wie sinnvoll in die Hände der Nutzer zu geben.