Die Schätzung ist eines der umstrittensten Themen in der Produktentwicklung. Warum? Weil Teams befürchten, für Zahlen zur Rechenschaft gezogen zu werden, die naturgemäß unsicher sind. Manche bauen Puffer ein, um sich zu “schützen”; andere argumentieren, dass die Schätzung komplexer Aufgaben sinnlos sei.
Das Ziel der relativen Schätzung ist einfach: bessere Gespräche über das Problem. Die Aufgabe des Product Owner besteht darin, den ROI zu maximieren, indem er den geschäftlichen Nutzen gegen den Umfang und die Komplexität der Arbeit abwägt. Die Frage lautet: “Wie viel Wert kann ich mit dieser Investition erzielen?” Die relative Bewertung berücksichtigt beide Aspekte dieser Gleichung – Wert und Investition.
Poker planen ist die Moderationstechnik, die dies ermöglicht. Sie stellt sicher, dass die Meinung jedes Teammitglieds zählt, und gewährleistet gleichzeitig einen effektiven Ablauf. Die Teams verwenden physische Karten oder Smartphone-Apps mit einer Fibonacci-ähnlichen Zahlenfolge: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? – und ☕.
Planning Poker kann von Teams und ihren Product Owner genutzt werden, um eine Verständnis der Investition, und es kann vom Product Owner gemeinsam mit den Interessengruppen genutzt werden, um sich auf die erwarteter geschäftlicher Nutzen. Für beide Gruppen ist der Ablauf derselbe.
Warum relative Schätzungen sinnvoll sind
Teammitglieder zögern oft, Schätzungen abzugeben, weil ihre Zahlen als verbindliche Zusagen behandelt werden – unabhängig von den Annahmen oder Überraschungen, die später auftreten. Um sich selbst zu “schützen”, fügen sie Puffer hinzu oder multiplizieren ihre Schätzungen mit einem Faktor (manchmal mit π, damit es wissenschaftlich wirkt). Doch das Anhäufen von Puffern verringert die Transparenz und macht Schätzungen nutzlos.
Die Erstellung präziser Schätzungen nimmt Zeit in Anspruch, doch der zusätzliche Aufwand zahlt sich selten aus. Schätzungen werden niemals 100% genau sein, daher führt es oft zu besseren Ergebnissen, wenn man weniger Zeit mit dem Schätzen und mehr Zeit mit der Umsetzung verbringt. Die relative Schätzung trägt dem Rechnung: Es geht darum, Umfang und Komplexität, nicht Stunden. Wir nennen das Story-Punkte.
Bei der relativen Schätzung muss man nicht präzise sein, sondern lediglich einheitlich darin, wie ungenau die Schätzungen ausfallen. Gleichzeitig hilft die relative Schätzung den Teammitgliedern dabei, ihr Verständnis der zu erledigenden Aufgabe auszutauschen und sich darauf zu einigen, wie viel Arbeit damit verbunden ist.
Warum ist das so?
Die Sache ist die: Peter, Paul und Mary sind nicht alle gleichermaßen gut darin, bestimmte Aufgaben zu erledigen. Manche Aufgaben erledigt Peter schneller als Paul – weil er in diesem Bereich mehr Erfahrung hat. Bei anderen Aufgaben ist Paul schneller als Mary – und bei wieder anderen ist Mary die Schnellste. Gleichzeitig schwanken Marys Motivation und Energie – an manchen Tagen ist sie voller Tatendrang, an anderen Tagen läuft sie auf Reserve. Vielleicht hat sie letzte Nacht nicht gut geschlafen. An den Tagen, an denen sie voller Energie ist, schafft sie viel; an den Tagen, an denen das nicht der Fall ist, kommt die Arbeit kaum voran. Menschen sind keine Roboter. Unsere Arbeit verläuft nicht linear – Interaktionen und Leistung schwanken.
Um dies auszugleichen, verwenden wir Story-Punkte. Mit Story-Punkten können sich Peter, Paul und Mary darauf einigen, dass eine Aufgabe eine 5, eine andere eine 13 und eine dritte eine 8 ist – auch wenn Peter bei der ersten, Mary bei der zweiten und Paul bei der dritten am besten ist. Ist das eine exakte Wissenschaft? Nein. Aber mit der Zeit gleicht sich das aus. Es ist wie auf der Wippe – mal gewinnt man, mal verliert man. Die Einschätzung komplexer Arbeit war noch nie eine exakte Wissenschaft – und wird es auch nie sein.
Um Story-Punkte von der Zeitaufwandsschätzung zu trennen, muss das Team über Folgendes verfügen: eine Referenz auf der Grundlage bereits geleisteter Arbeit – wir bezeichnen diese normalerweise als „User Stories“. Das Team erstellt diese Referenz, indem es verschiedene Arbeitselemente miteinander vergleicht. Was entspricht einer 3, was einer 5 und was einer 8? Das Team sollte seine Referenz im Laufe der Zeit pflegen und verfeinern und dabei sicherstellen, dass sie nicht vom Kurs abweicht.
Eine Metapher zum Verständnis von Story Points
Stellen wir uns eine einfache Aufgabe vor: einen Haufen Sand zu bewegen. Die beiden Personen, die diese Aufgabe übernehmen wollen, können sich in etwa über das Volumen (die Größe) einigen – und sie können sich auch über die Komplexität des Transports einigen. Ehrlich gesagt ist das Bewegen von Sand nicht besonders komplex – es sei denn, der Sand ist verschmutzt, was die Aufgabe erschwert, da dann eine spezielle Handhabung und Ausrüstung erforderlich wären.
Die Aufgabe, den Sand zu bewegen, weist eine bestimmte Kombination aus Umfang und Komplexität auf – man könnte sagen, diese Aufgabe hat den Schwierigkeitsgrad 8. Wäre es verschmutzter Sand, hätte sie vielleicht den Schwierigkeitsgrad 13 oder 20. Das sagt jedoch noch nichts darüber aus, wie lange es dauern wird. Das hängt davon ab, wie die Aufgabe personell besetzt ist. Wenn eine Person den Sand bewegt, dauert es eine bestimmte Zeit; wenn zwei Personen es tun, wird die Zeit anders ausfallen (hoffentlich kürzer). Vielleicht sind die beiden Personen nicht gleich gut darin, Sand zu transportieren. Vielleicht hat eine von ihnen Rückenschmerzen – dann dauert es länger, wenn diese Person alleine arbeitet. Wenn die andere Person die Arbeit übernimmt, geht es schneller. Vielleicht variieren auch die Werkzeuge – an einem Tag werden Eimer verwendet, an einem anderen Tag Schubkarren und an einem dritten Tag ein Bagger. Die Zeit wird variieren, aber die Kombination aus Umfang und Komplexität bleibt gleich. Es ist immer noch eine 13, egal wie viele Personen die Arbeit erledigen oder welche Werkzeuge sie verwenden.
Das ist zwar keine exakte Wissenschaft, aber mit der Zeit gleicht sich das aus – vor allem, wenn man die Referenz und das Team konstant hält.
Spielanleitung
Zu Beginn des Planning Poker erhält jedes Teammitglied ein Kartenspiel. Für jede zu schätzende User Story oder jedes zu schätzende Thema:
- Ein Moderator – in der Regel der Product Owner, der Scrum Master oder ein Analyst – liest die Beschreibung vor. Der Der Moderator nimmt nicht an der Abstimmung teil..
- Jedes Teammitglied wählt insgeheim einen Kartenwert aus auf der Grundlage ihres Verständnisses der Geschichte, wenn sie diese mit dem Vergleichsbeispiel des Teams abgleichen.
- Wenn alle ihre Wahl getroffen haben, werden alle Karten gleichzeitig aufgedeckt.
- Die Teammitglieder mit dem Höchst- und Tiefstwerte ihre Überlegungen darlegen.
- Der Product Owner bzw. der Stakeholder beantwortet alle Fragen des Teams.
- Jedes Teammitglied Neubewertungen indem man im Verborgenen eine neue Karte auswählt.
- Alle Karten werden erneut angezeigt, damit jeder die aktualisierten Schätzungen sehen kann.
- Die Teammitglieder mit den höchsten und niedrigsten Werten ihre Argumentation erörtern noch einmal.
- Nach der Besprechung nimmt jedes Teammitglied eine abschließende Zeiteinschätzung vor.
- Wenn es nur ein Schritt Unterschied unter den verbleibenden Karten, die Der höchste Wert wird ausgewählt.
- Falls es Auch nach der dritten Runde noch kein Konsens, Die Der höchste Wert wird ausgewählt.
Einsatz von Planning Poker zur Ermittlung des Geschäftsnutzens
Was den Geschäftsnutzen angeht, ist der Ablauf derselbe. Hier führen das Product Owner-Team und die relevanten Stakeholder die relative Einschätzung durch. So wie das Team über einen Referenzrahmen für Story-Points verfügt, sollten auch das Product Owner-Team und die Stakeholder über einen Referenzrahmen für den Geschäftsnutzen verfügen – vorzugsweise in Form von Funktionen, die ihren Wert bereits auf dem Markt unter Beweis gestellt haben.
Während der Schätzung sollte sich ihr Dialog über den geschäftlichen Nutzen nicht nur auf finanzielle Aspekte beschränken. Sie könnten beispielsweise folgende Themen besprechen:
- Wird diese Funktion neue Möglichkeiten eröffnen? neue Märkte für uns?
- Kann es uns helfen? Upselling für bestehende Kunden?
- Ist das notwendig, um behalten Unsere Marktposition?
- Wird es besser werden? Effizienz?
- Wird dies vorgeschrieben durch Gesetzgebung?
- Wird es unsere Marke?
Keiner dieser Aspekte ist an sich besser als die anderen, aber entscheidend sind die Diskussion und die Abstimmung.
Verwendung der relativen Schätzung für Prognosen
Der Zweck von Schätzungen besteht darin, vorhersehbare Pläne zu erstellen. Bei komplexen Aufgaben ist das fast unmöglich – aber das sollte uns nicht davon abhalten, es zumindest zu versuchen. Egal, für wie „Agile“ wir uns halten – es besteht dennoch Bedarf an Synchronisationspunkten wie Meilensteinen oder Gates. Andere Abteilungen – wie beispielsweise die Produktion, der Vertrieb oder das Marketing – sind darauf angewiesen zu wissen, wann wir die Entwicklung einer Funktion oder eines Produkts abschließen werden. Auch wenn sich Pläne ändern werden, sollten wir dennoch unsere bestmögliche Einschätzung zu Was wird passieren? Und wenn wir fertig sind.
Durch die Verwendung einer relativen Schätzung anhand von Story-Points sowie durch die Erfassung der Anzahl der Story-Points, die das Team in jedem Sprint liefert (seine Velocity), kann das Product Owner etwas vorhersehbare Pläne. Da das Team bereit ist, die Aufgaben im Product Backlog zu bewerten – auch wenn diese nur kurz beschrieben sind –, fällt es dem Product Owner leicht, einen Entwurf zu erstellen, welche Aufgaben voraussichtlich in welche Sprints passen. Dies sorgt für Transparenz bei den Plänen und dem Fortschritt und hilft dem Product Owner, Prioritäten mit den Stakeholdern zu besprechen und die bestmöglichen Entscheidungen zu treffen.
Die größte Herausforderung bei der Verwendung der Geschwindigkeit besteht darin, dass sie sich im Laufe der Zeit ändert. Dies wird durch verschiedene Faktoren beeinflusst:
- Verfügbarkeit der Teammitglieder für die Teamarbeit
- Unterbrechungen im Arbeitsalltag
- Unterschiede hinsichtlich der Übereinstimmung der Kompetenzen des Teams mit den aktuellen Aufgaben
- Die Konzentration und das Engagement der Teammitglieder, das Sprint Goal-Ziel zu erreichen
Eine gute Möglichkeit, mit dieser Unsicherheit umzugehen, ist die Nutzung der 90% Konfidenzintervall der Geschwindigkeit. Zwar liegen dem statistische Formeln zugrunde, doch in der Praxis verwendet man die zweithöchste und zweitniedrigste Geschwindigkeit aus den letzten acht Sprints, um das Intervall für die angestrebte zukünftige Geschwindigkeit festzulegen.
Manche Teams planen im Sprint einen Puffer für ungeplante Arbeit ein. Wenn man jedoch relative Schätzungen mit Story-Points verwendet und das Commitment sowie die Prognosen auf die gemessene Velocity stützt, bedeutet dies Dieser Puffer ist bereits berücksichtigt.. Wenn ein Team Aufgaben entsprechend seiner aktuellen Velocity entnimmt, ist der erforderliche Puffer automatisch bereits enthalten.
Das ist zwar keine exakte Wissenschaft, aber mit der Zeit gleicht sich das aus – vor allem, wenn man die Referenz und das Team konstant hält.
Abschließende Überlegungen
Der Einsatz relativer Schätzungen bietet eine einfache Möglichkeit, sich in der Komplexität der Produktentwicklung in der heutigen Welt zurechtzufinden. Diese Fähigkeit entsteht jedoch nicht aus dem Nichts – es gibt eine lange Kette von Voraussetzungen, die erfüllt sein müssen, damit dies funktioniert. Dazu gehören:
- Ein klares Verständnis und ein Gefühl der Verantwortung für das Team Zweck und Ziele
- Team Stabilität und Zusammenhänge
- Die Einigung des Teams über Aufgaben und Zuständigkeiten
- Die Product Owner Auftrag und Disziplin im Rahmen der Backlog-Verfeinerung
- Die Fähigkeit des Scrum Master, das Team schützen durch ungeplante Arbeit
Wie Sie sehen, gibt es bei der Anwendung der relativen Schätzung zwar eine Struktur und einen Prozess, doch letztendlich kommt es auf die Unternehmenskultur an. Die relative Schätzung funktioniert nur, wenn Sie die Unsicherheit bei komplexen Aufgaben akzeptieren und dem Team die Freiheit geben, selbst zu entscheiden, wie die Arbeit erledigt werden soll. Wenn Sie die Zusammensetzung des Teams ständig ändern, wird dies niemals funktionieren.
