Tipps für ScrumMaster: Schätzen Sie User Stories außerhalb von Sprint Planning Meetings

Eine der größten Stärken von Scrum ist, dass es sich um ein Rahmenwerk handelt und nicht um eine detaillierte Methodik wie RUP. In Scrum werden Konzepte beschrieben, die wesentliche Aspekte von Projekten auf eine sehr leistungsfähige Art und Weise in Einklang bringen. Man braucht keinen Prozessingenieur, um Scrum maßzuschneidern, damit es erfolgreich angewendet werden kann. Da es jedoch viele Dinge gibt, die in Scrum nicht im Detail beschrieben werden, bleibt viel Raum, um die Dinge durcheinander zu bringen :-) In diesem Blog erörtere ich, wie man die Schätzung von Product Backlog-Elementen erleichtern kann, damit der Product Owner die Release-Planung durchführen kann.

Wie Mike Cohn in seinem hervorragenden Buch Agile Estimating and Planning dargelegt hat, erfolgt die Planung in agilen Projekten auf drei Ebenen:

• Tägliche Planung;
• Iterationsplanung;
• Planung der Veröffentlichung.

In den meisten Scrum-Projekten erhalten die ersten beiden dieser Ebenen die Aufmerksamkeit, die sie verdienen: Die tägliche Planung findet im Daily Scrum statt, die Iterationsplanung im Sprint Planning Meeting. Auf der dritten Planungsebene wird es oft unübersichtlicher. Bei den meisten Projekten ist ein Planungshorizont erforderlich, der weiter entfernt ist als ein Sprint. Zum Beispiel ist eine Marketingkampagne in drei Monaten geplant und der Product Owner möchte wissen, welche Funktionen bis dahin voraussichtlich fertiggestellt sein werden. Wenn das Projekt User Stories mit Story Point-Schätzungen verwendet, werden die folgenden Informationen benötigt:

• Die Geschwindigkeit des/der Teams: Wie viele Story Points werden pro Sprint bearbeitet?
• Schätzungen in Story Points für mindestens alle User Stories, die eine Chance haben, vor dem Veröffentlichungsdatum fertig zu werden.

Ich habe festgestellt, dass viele Leute damit Probleme haben, weil in Scrum traditionell nicht explizit festgelegt ist, wann und wie Schätzungen für User Stories erstellt werden sollen. In vielen Scrum-Projekten findet die Schätzung nur im Sprint Planning Meeting statt. Manchmal werden User Stories in Story Points geschätzt, aber diese Schätzungen werden nur für dieselbe Gruppe von User Stories abgegeben, für die anschließend Aufgaben identifiziert und geschätzt werden. Das widerspricht eigentlich dem Zweck von Story Point-Schätzungen. Das Team könnte die Story-Point-Schätzungen genauso gut ganz weglassen, denn die Aufgabenschätzungen sollten ausreichen, um zu prüfen, ob die geplante Arbeit in einem Sprint erledigt werden kann. Ich empfehle, die User Stories in Backlog Refinement Meetings getrennt von den Planning Meetings zu schätzen. In diesen Meetings können größere Gruppen von User Stories geschätzt werden als in einem Planning Meeting, da nur gerade genug Details besprochen werden müssen, um die User Stories im Verhältnis zueinander zu schätzen. Zumindest der Product Owner und die Teamvertreter aller Disziplinen, die am Product Backlog arbeiten, müssen anwesend sein. Vor allem, wenn mehrere Teams an einem Product Backlog arbeiten, ist es nicht immer möglich, alle an jeder Sitzung teilnehmen zu lassen. Backlog Refinement Meetings sind auch ein guter Ort, um zu besprechen, wie größere User Stories in kleinere aufgeteilt werden können und User Stories zu identifizieren, die einer weiteren Klärung bedürfen. Das ist der Grund, warum ich den Begriff Backlog Refinement Meeting dem Begriff Estimation Meeting vorziehe. In Sprint Planning Meetings werden nur die geschätzten User Stories besprochen, die als BEREIT für die Arbeit des Teams identifiziert wurden.Die beste und am weitesten verbreitete Technik zur Schätzung von Product Backlog-Elementen ist die Schätzung in Story Points mit Hilfe eines Planungspokers. Wenn viele Elemente in kurzer Zeit geschätzt werden müssen, können Sie auch einen alternativen Ansatz in Betracht ziehen, den ich in einem früheren Blog beschrieben habe: Lassen Sie das Team alle Elemente auf einmal auf einer horizontalen Skala ordnen und weisen Sie dann Story Points zu. Nachdem wir nun das Backlog Refinement Meeting besprochen haben, sollten Sie beachten, dass es starke Analogien zwischen der Iterationsplanung und der Release-Planung gibt, die in der folgenden Tabelle detailliert aufgeführt sind:

Ich hoffe, dass ich mit diesem Blog einigen ScrumMastern bei der Anwendung von Scrum zur erfolgreichen Durchführung von Projekten ein wenig weitergeholfen habe. Ich werde jetzt anfangen, über den nächsten Tipp für ScrumMaster nachzudenken ...