These 1: Die Verwendung von Story Points zur Abschätzung des Umfangs bzw. der Komplexität einer Anforderung kann nur dann funktionieren, wenn alle am Schätzprozess beteiligten das gleiche Verständnis / Gefühl über deren Wertigkeit haben.

These 2: Ein Planning Poker zur „gemeinsamen“ Abschätzung des Umfangs / der Komplexität einer Anforderung kann nur dann funktionieren, wenn alle am Schätzprozess beteiligten

Der Story Point an sich

Sofern ein Team zur Abschätzung des Umfangs / der Komplexität einer Anforderung diese mit einer Referenz – equal 1 Story Point – vergleicht, muss diese Referenz allem am Schätzprozess Beteiligten hinreichend bekannt sein. Nicht selten treffe ich bei Kunden auf Scrum Teams, die einer hohen Fluktuation unterliegen. Ich stelle in Frage, ob alle Teammitglieder auch immer die (jeweilige) Referenz hinreichend gut kennen, mit der die umzusetzenden Anforderungen verglichen werden.

Über eine häufige Durchführung von Schätzungen mag man ein Gefühl dafür bekommen, was die Wertigkeit des Story Points in dem Team ist, in dem man gerade sein täglich Brot verdient, doch wie viel Häufigkeit braucht es?

Wenn Sie heute mit einem Sack polnischer Zloty und ohne Umrechnungstabelle losgeschickt werden, wie lange und wie viele Einkäufe wird es wohl brauchen, bis Ihnen diese Fremdwährung genauso vertraut ist, wie der EURO, der US$ oder allgemein, die Währung in Ihrer Heimat?

Experiment: Stellt einem jedem Teammitglied die Frage danach, was die Wertigkeit eines Story Points ist. Glaubt Ihr Antworten zu bekommen, die ein Gefühl dafür vermitteln, dass die Kollegen und Kolleginnen alle das gleiche Verständnis über die Wertigkeit von Story Points haben?

Der Schätzprozess an sich

Ich bin Unternehmensberater und als ich gestern bei einem Spaziergang an einem Maisfeld vorbeikam, habe ich mich gefragt, welchen Umsatz und welchen Gewinn der Bauer daraus ziehen wird, wenn es zur Ernte geht und er diese verkauft.

Ganz ehrlich …

In diesem Themenbereich habe ich viel zu wenig Ahnung, um auch nur eine ungefähre Abschätzung in Bezug auf den Aufwand, die Kosten, den Umsatz und den Gewinn machen zu können. Weder kann ich die Maschinen bedienen, die es braucht, um den Mais zu pflanzen und ihn zu ernten, noch habe ich die erforderlichen Kenntnisse in Bezug auf das Pflanzgut. Hier bin ich blank.

Ob eine Floristin hier Auskunft geben kann? Schließlich sind Pflanzen Ihr Fachgebiet.

Was ich damit zum Ausdruck bringen möchte ist, dass es auch nicht ausreichend ist, irgendeine Programmiersprache zu beherrschen und weder die Architektur einer Anwendung noch das dahinter liegende Objektmodell zu kennen.

Von einem Experten der Frontend-Entwicklung mit Angular und JavaScript kann i. d. R. nicht erwartet werden, dass er / sie auch hinreichend gut die Programmiersprache ABAP kennt und sich in der Architektur des Monsters namens SAP auskennt.

Nachfolgend eine Auflistung verfügbarer SAP-Module, bei denen jedes für sich in Größe und Umfang ein Mammut darstellt. Ob wohl ein SAP ABAP-Entwickler, der die vergangenen Jahre im Themenbereich SAP MM tätig war, sich ausreichend gut in SAP FI auskennt, um eine halbwegs valide Aufwandsabschätzung für eine Anforderung des Finanzwesens abgeben zu können? Auch wenn für alle Module die gleiche Programmiersprache zum Einsatz kommt.

Anmerkung: ABAP, kurz für „Advanced Business Application Programming“, ist eine proprietäre, multiparadigmatische Programmiersprache, die an COBOL angelehnt ist.

Statement: Wer nicht über ein sinnvoll notwendiges Maß an Wissen verfügt, um eine Aufwandsschätzung abzugeben, sollte es auch nicht tun.

Der Planning Poker

Agile ist kein Projektmanagement. Agile dient der agilen Produktentwicklung. Ein Produkt, oder eine Solution, ist dabei oftmals ein komplexes Konstrukt verschiedener Anwendungen und Systeme.

Beispiel:
Für die Entwicklung eines eShops, über den industrielle Kabel verkauft werden, sind die nachfolgenden Systeme Bestandteil der Solution eShop:

• SAP CRM (Customer-Relationship-Management)
• SAP PP (Produktionsplanung)
• SAP SD (Vertrieb)
• SAP FI (Finanzwesen)
• ein Product Information System, kurz PIM, aus dem heraus die Produktbeschreibungen in Text und Bild an ein Web-Frontend geliefert wird
• AEM – Adobe Experience Manager -, ein Content Management System
• Angular und Javascript
• eine Middleware, über die die Kommunikation zwischen den einzelnen Backend-Systeme abläuft
  Etc.

Wenn ein Agile Release Train (ART) aus mehreren Scrum Teams besteht, in denen jeweils Experten unterschiedlichen Systeme (siehe Beispiel) ihr Werk verrichten, dann ist es ausgesprochen unwahrscheinlich, dass ein Angular-Experte über das notwendige Wissen verfügt, um auch den Teil einer Kundenanforderung abschätzen zu können, der Bestandteile von SAP FI beinhaltet. Siehe dazu auch noch einmal meine Anmerkungen zum Schätzprozess.

Wenn wir noch einmal These 2 betrachten, dann stellt sich schon die Frage, wer in einem Feature Team die darin beschriebenen Kenntnisse hat, um sinnvoll eine valide Aufwandsschätzung abgeben zu können.

Wenn schon ein Planning Poker stattfinden soll, dann aber nur im Kreise derer, die dazu auch befähigt sind. Bitte kein „erzwungenes“ Abgeben von Schätzungen, die so gar keine gesunde Basis in Bezug auf das dafür erforderliche Wissen haben.

Conclusio

Noch wichtiger als die detailgetreue Anwendung einer Methode ist der Einsatz des gesunden Menschenverstandes. Auch wenn vielleicht eine Mehrheit gewisse Methoden zur Anwendung bringt, sollte man den Sinn und Zweck für den eigenen Einsatz im eigenen Kontext immer kritisch hinterfragen.

Am Ende zählen Ergebnisse. Wenn der Zielerreichungsgrad, also der Quotient zwischen Plan und tatsächlicher Umsetzung, zwischen Commitment und Completed, in der Regel (weit) unter 50 % liegt, funktioniert es wohl nicht.