Scrum spricht davon, dass wir unser Backlog mit Anforderungen füllen, die spätestens zum Sprintbeginn geschätzt werden, wenn sie in das Sprint Backlog übernommen werden. Beim Schätzen herrscht jedoch immer wieder größte Verwirrung. In fast jedem Unternehmen sehe ich, dass die Entwickler sehr oft damit überfordert sind, eine konkrete Aussage zum Aufwand einer Anforderung zu machen, weil sie zum viel zu wenig über die zur Umsetzung der Anforderung nötigen Arbeiten wissen. Häufig fallen dann Sätze wie »das müssen wir uns erst einmal ansehen«. Und Planning Poker ist nicht immer die Krönung aller Weisheit.
Wenn das auch bei Ihnen häufiger der Fall ist, dann sollten Sie Ihr Vorgehen überdenken. Sie werden gelesen und gehört haben, dass der Product Owner die Anforderungen ins Backlog aufnimmt, und dass das Team diese Anforerungen während der Sprintplanung schätzt, um eine Aussage dazu machen zu können, welche Anforderungen im betreffenden Sprint umgesetzt werden können. Grundsätzlich ist das natürlich richtig, aber bedenken wir bitte, dass Softwareentwicklung meistens ein recht komplexes Gebiet ist, und dass unsere Kollegen auch nicht allwissend sind.
Ganz besonders dann, wenn wir an einer bestehenden Software arbeiten und diese weiterentwickeln, werden Sie sehr oft erleben, dass ein Entwickler nicht sofort eine konkrete Aussage machen kann. Solche Projekte sind »natürlich gewachsen« (das werden Sie immer wieder hören), was nichts anderes bedeutet, als dass sich hinter den Kulissen ein echtes Chaos verbirgt, das keiner wirklich überblicken kann. Sehr oft haben andere Entwickler, die das Unternehmen bereits verlassen haben, daran mitgewirkt; die Dinge sind nicht sauber dokumentiert (genau das ist der Grund, warum eine vernünftige Dokumentation auch bei jedem noch so Agilen Vorgehen wichtig ist); irgendwann wurden mit heißer Nadel schnelle Anpassungen gestrickt, die man irgendwann einmal überarbeiten wollte.
Jetzt sitzen Sie also als Product Owner mit Ihren Kollegen in der Sprintplanung, stellen Ihre Anforderungen vor, und niemand kann Ihnen sagen, wie aufwändig deren Umsetzung ist. Ein Entwickler gibt einer Sache einen Punkt, der nächste gibt derselben Sache acht, und keiner weiß was Genaueres. Unter solchen Umständen ist eine ernsthafte Sprintplanung kaum möglich. Am Ende haben Sie sich auf Irgendetwas geeinigt, und schon nach zwei Tagen stellen Sie fest, dass Ihre Planung nicht passen will.
Wenn Ihnen das bekannt vorkommt, dann seien Sie beruhigt: das ist nicht nur bei Ihnen so, und die Lösung ist einfach. Beziehen Sie Ihre Entwicklerkollegen stärker in Ihre Vorbereitungen ein. Gehen Sie schon vor der Sprintplanung einzelne Anforderungen mit Ihren Kollegen durch, damit diese die Möglichkeit bekommen, sich damit auseinanderzusetzen. Sie können auf diese Art sicher sein, dass die Anforderung verstanden wurde, weil Sie sich mit Ihrem Kollegen darüber unterhalten. Fragen werden dann bereits vor der Planungssitzung geklärt.
Vor allen Dingen aber hat der Entwickler Zeit, sich die Sache genauer anzusehen. Diese Zeit sollte ihm in jedem Fall auch gegeben werden. Argumentieren Sie jetzt bitte nicht, dass die Zeit eines Entwicklers komplett im Sprint verplant wird. Dann wird diese Zeit, die für die Recherche notwendig ist, eben herausgerechnet.
Sie nehmen sich ein paar Minuten, sprechen eine für den nächsten Sprint vorgesehene Anforderung mit ihrem Kollegen durch, und dieser macht sich Gedanken über deren Umsetzung. Er schaut auch einmal in die Sourcen, um herauszufinden, ob dort gemeine Überraschungen lauern, und ist damit sehr gut für die Planungssitzung vorbereitet.
Und die Sache mit dem Planning Poker?
Diese Technik wird unfassbar oft eingesetzt; leider auch dann, wenn sie überhaupt keinen Sinn macht. Nachdem eine Anforderung vorgestellt wurde, halten die Entwickler Karten mit den geschätzten Aufwänden hoch. Alles ist wunderbar, wenn sich eine klare Tendenz erkennen lässt, bei großen Differenzen wird diskutiert. Ich möchte es nicht im Einzelnen erklären. Zum einen finden Sie eine Beschreibung des Planning Pokers in fast jedem Scrum Buch, zum anderen bin ich kein großer Fan dieser Technik. Man nutzt es, um nicht bei jeder Anforderung länger diskutieren zu müssen, aber wenn Sie bei jeder Anforderung ohne diese Karten ins Diskutieren kommen, dann liegt das Problem tiefer.
Dann haben Sie entweder ein Team, das über stark unterschiedliche Vorkenntnisse verfügt, oder die Anforderungen sind nicht wirklich verstanden worden. Diese Probleme lösen Sie nicht mit dem Einsatz von Pokerkarten.
Haben Sie auch diese Karten gekauft? Überlegen Sie sich, ob der Einsatz in Ihrem Team wirklich sinnvoll ist. Planning Poker führt Sie nur dann zum Ziel, wenn Ihr Team sehr homogen ist. Ein sehr junioriger und ein sehr senioriger Entwickler werden immer zu unterschiedlichen Auffassungen kommen, was den Aufwand einer Sache betrifft. Einer in Ihrem Team kennt die Sourcen und weiß, dass es übel aussieht. Alle anderen gehen in ihrer grenzenlosen Naivität davon aus, dass es nicht so schlimm sein kann. Oder Sie haben in Ihrem Team Designer, Architekt, Frontender, Backender und Datenbankspezi. Wie will man bei einer solchen Konstellation (die eigentlich erstrebenswert ist) zu einer Schätzung kommen? Was kann Ihnen der Designer zum Programmieraufwand sagen?
Wenn sich Diskussionen oder Fragen zu den Aufwänden ergeben, dann sollte man keine Möglichkeiten suchen, keine Diskussionen aufkommen zu lassen. Fragen Sie sich einfach, warum das Team darüber diskutiert, und warum es unterschiedliche Ansichten hat.
ich habe sehr gute Erfahrungen damit gemacht, Anforderungen bereits vor der Planungssitzung mit Entwicklern durchzusprechen. Während der Sitzung selbst spielen wir dann nicht mehr mit Karten, sondern der Entwickler, der sich die Anforderung angesehen hat, sagt ein paar Worte dazu. Er erklärt seinen Kollegen kurz, was dafür zu tun ist, wie ggf. die alten Sourcen aussehen und wo vielleicht Schwierigkeiten liegen könnten. Damit bringt er alle Beteiligten auf den selben Wissensstand, und das Team kommt in aller Regel sehr schnell zu einer Einigung.
