Kurzbeschreibung
Die Verwendung von Magic Estimation im agilen Umfeld erlaubt es uns, viele User Stories oder andere Product Backlog Items in relativ kurzer Zeit zu schätzen. Wie beim Planning Poker, geht es bei dieser Schätzung geht es darum, die Komplexität der betrachteten User Stories durch das Entwicklungsteam zu bewerten. Dieser Vorgang beinhaltet eine Vielzahl von Aspekten wie Risiken, Unsicherheiten, Abhängigkeiten und sowohl die Komplexität als auch das Arbeitsvolumen, die jedes Backlog Item mit sich bringt
Mit der Magic Estimation gewinnt Ihr Einblicke in Euer Produkt-Backlog, die Euch dabei helfen können:
- Ermittlung einer groben Schätzung des Verhältnisses zwischen einzelnen Backlog Items.
- Vergleich der geschätzten Kosten mit dem erwarteten Nutzen
- Den Product Owner in die Lage zu versetzen, effizienter und effektiver bei der Festlegung von Prioritäten und der Organisation des Product Backlogs zu werden
- Schätzung der Backlog Items und – falls erforderlich – Neudefinition oder Entfernung von Teilen davon
- Kalkulation von Festpreisaufträgen
- Erwartungsmanagement mit den Stakeholdern des Teams und damit Verbesserung der Kommunikation
- Transparenz in Bezug auf die Komplexität und die Unsicherheiten innerhalb des Rückstands einführen, um Maßnahmen zu ergreifen und Spitzen zu schaffen, Prioritäten anzupassen, neue Lösungen zu finden oder Backlog Items aufzulösen
Allgemeiner Aufbau
Magic Estimation ist eine Methode, die während einer Refinement Session stattfindet. Das Entwicklungsteam kommt in einem Raum zusammen, um sich entweder um einen großen Tisch oder vor einer großen Wand zu versammeln. Jedes Backlog Item wurde zuvor auf einen Zettel oder ein Stück Papier geschrieben, das dann dem Team als gemischter Stapel präsentiert wird. Die Teammitglieder betrachten jedes Backlog Item einzeln und platzieren schließlich jeden Zettel in einer Spalte auf der Grundlage der zugewiesenen Story Points (SP). Ein Teammitglied kann zum Beispiel eine User Story mit 3 SP in eine Spalte mit dem Titel “3 Story Points” setzen.
Nachdem die erste Runde abgeschlossen ist, muss ein Teammitglied in der zweiten Runde einzelne Backlog Items in alternative Spalten verschieben, wenn das Mitglied mit der ursprünglichen Positionierung nicht zufrieden ist. Der Scrum Master oder der Moderator, beobachtet in der Regel, welche Backlog Items besonders häufig zwischen den Spalten verschoben werden und legt den Schwerpunkt auf diese. Danach kann eine kleine Diskussion stattfinden, um sicherzustellen, dass jede Annahme zur Sprache gebracht wurde.
Wie Sie sich vorstellen können, ist das alles viel schwieriger, wenn man nicht zusammen im gleichen Raum ist, aber mit ein paar Anpassungen kann dieser Prozess auch aus der Ferne funktionieren!
Alternativ könnt Ihr auch ganz ohne Story-Punkte anfangen und diese anschließend hinzufügen. Ihr solltet jedoch bedenken, dass die magische Schätzung – genau wie Planning Poker – auf einer relativen Schätzung beruht. Es ist immer wichtig, eine Beziehung zwischen den User Stories herzustellen. Wenn diese Grundlage nicht gegeben ist, interpretiert jeder etwas anderes, und es wird schwierig die Schätzungen zueinander in Beziehung zu setzen.
Vor allem zu Beginn der Übung ist es schwierig, die Bandbreite der Story-Punkte zu definieren. In diesem Fall kann das Team zunächst eine Rangfolge der Backlog Items vom kleinsten bis zum größten erstellen. Falls die Spalten noch nicht beschriftet sind, wird die User Story , die als die kleinste angesehen wird, in die äußerste linke Spalte und die größte in die äußerste rechte Spalte gesetzt.