User Stories der Größe 1

Nach der Agile World hatte ich mit einem Artikel über Schätzereien begonnen, eine Diskussion auf der diesjährigen Agile World auszuwerten. Heute möchte ich den angekündigten zweiten Artikel präsentieren, der sich mit der Frage beschäftigt: Wie praktikabel sind absolute Aussagen?

Im Zusammenhang mit dem Verzicht auf Schätzen hat mich die Aussage, dass User Stories, die größer als 1 sind, generell nicht funktionieren, am meisten erstaunt. Ich halte solche pauschalen Aussagen für zu kurz gedacht. Unabhängig davon, in welchem System man sich bewegt. Eine absolute Größe ohne Bezugssystem ist für eine Schätzung nicht zu gebrauchen.

Abgesehen davon widerspicht eine solche Aussage massiv dem agilen Manifest. Dort heißt es nämlich: Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans. Und das Festlegen darauf, dass alle User Stories die Größe 1 haben sollen ist nichts anderes als Befolgen eines Plan. Pläne haben aber einen massiven Nachteil, wenn sie mit der Realität konfrontiert werden: Es kann sein, dass die Realität anders funktioniert, als der Plan vorsieht. Gerade bei Softwareentwicklung machen wir diese Erfahrung immer wieder. Was macht man dann mit einer Story die doppelt so groß ist? Ablehnen? Zerschneiden, auch wenn die einzelnen Stories dann keinen Business Value mehr beinhalten? Als Pragmatiker nehme ich in so einem Fall einfach eine Story der Größe 2 ins Backlog. Das klappte bisher immer hervorragend 😉

Ein weiterer Grund für meine Ablehnung solcher Aussagen ist, dass sie auf dem Confirmation Bias beruhen. Jemand, der so eine absolute Aussage trifft, hat in der Regel in einem bestimmten fachlichen Kontext die Erfahrung gemacht, dass sein Ansatz funktioniert. Daraus schließt er, dass dieser Ansatz valide ist – was für diesen Kontext auch zutrifft – und läuft los, um Bestätigung zu suchen. Und hier schlägt der Confirmation Bias zu. Menschen neigen dazu, nur bestätigende Informationen aufzunehmen, wenn sie von etwas überzeugt sind. Ein korrektes Vorgehen wäre es, nach Beispielen zu suchen, die eine solche Aussage widerlegen, denn sie ist von Natur aus nicht beweisbar.

Natürlich bin ich ein Verfechter möglichst kleiner User Stories. Kleine User Stories reduzierten das Risiko für eine Fehlentwicklung, sind leichter zu schätzen und ermöglichen einen höheren Fluss bei kleinerem Work In Progress. Nichtsdestotrotz sollten User Stories so beschaffen sein, dass sie Business Value in die Software bringen und keinen toten Code hinterlassen. Ich habe die Erfahrung gemacht, dass folgende Daumenregel sehr gut funktioniert: User Stories sollten kleiner sein, als die Hälfte der Velocity. Aber auch dafür gibt es Ausnahmen, so ist das Leben.

Im ditten Teil meiner Nachbrenner zur Agile World geht es dann um die Frage zur Einheit von Schätzgrößen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.