Facebook
Twitter
Google+
Kommentare
5

Scrum: Story Points – Das Problem mit der Komplexität

Agile Softwareentwicklung mit Scrum habe ich ja schon in ein paar Artikel angesprochen. Dort habe ich auch erzählt, wie toll es ist und das einem die Sonne aus dem Hintern strahlt. Aber da wo Sonne ist, ist auch Schatten. Naja kein Schatten. aber es gibt in Scrum Dinge, die nicht so leicht zu verstehen sind. Nehmen wir zum Beispiel Story Points.

In Scrum schätzt man keine Personenstunden, wenn man ein Feature implementiert, sondern Story Points. Das sind abstrakte Werte, die die Komplexität eines Tasks (für die Scrummies Story) darstellen. Klingt erstmal super. Keine Stunden, dass heißt am Ende kann dir keiner an den Karren fahren, weil es länger gedauert hat. Wunderbar. Um in das Schätzen reinzukommen, einigt man sich im Team auf einen Tasks, den man gut abschätzen kann und nimmt ihn als Referenz. Danach sagt man das ein anderer Task ähnlich komplex ist oder ein anderer doppelt.

Wenn ich das eine Weile so mache, dann weiß ich, wie viele Story Points in einer gewissen Zeiteinheit schaffe (Sprint) und kann damit die Teamgeschwindigkeit (Velocity) berechnen. Wenn alle meine zukünftigen Aufgaben durchgeschätzt sind, kann ich sogar sagen, wann mein Projekt zu Ende ist, auch wenn man keine Aufwände geschätzt hat.

Klingt jetzt alles ein wenig „abgefahren“, aber es funktioniert und nach einer Weile wird das Team auch wirklich sehr ähnliche Schätzungen abgeben. Bis jetzt also nur Sonne.

Jetzt gibt es ein häufiges Problem, wenn man sich in einem Schätzmeeting befindet. Man hat einen Task, der ist aufwendig, aber nicht komplex. Was sagt uns das über die Story Points? Eigentlich sollten sie sehr niedrig angesetzt werden. Das ist aber doof, denn wenn ich nur solche Tasks in meinem Sprint hätte, dann würde meine Teamgeschwindigkeit in diesem Sprint ja unheimlich niedrig sein, denn viel Komplexität habe ich nicht gemeistert. Also kann das mit der Komplexität nicht so ganz korrekt sein, wenn man sich das ganze im Zusammenspiel anschaut.

Story Points müssen also doch so etwas wie den Aufwand wiederspiegeln. Ich war so frei und habe mal in der Xing-Gruppe zum Thema Scrum meine Fragegestellt und leider waren die meisten Antworten esoterisch oder einfach nicht hilfreich. Leider. Bis jetzt habe ich noch keinen wirklich guten Artikel gefunden, der alle meine „Fragen“ beantwortet hat, aber ich bin weiter dran. Wer schon mal eine weitere Meinung lesen will, dem empfehle ich Mike Cohn’s Blog. Er hat ein nettes Beispiel angebracht.

„Suppose a team consists of a little kid and a brain surgeon. Their product backlog includes two items: lick 1,000 stamps and perform a simple brain surgery–snip and done. These items are chosen to presumably take the same amount of time. If you disagree, simply adjust the number of stamps in the example. Despite their vastly different complexities, the two items should be given the same number of story points–each is expected to take the same amount of time. „

Da ich weiß, dass viele von euch agil arbeiten, hoffe ich auf eine Diskussion, wie ihr Story Points schätzt. Gerne auch im Xing-Forum.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

5 Comments

  1. Tom DeMarco nennt das in „The Deadline“ synchronisierte Bauchgefühle. Dein Bauchgefühl wird durch eine virtuelle Einheit (in deinem Fall Story Points) messbar gemacht. Über die Zeit synchronisiert sich damit das Bauchgefühl der einzelnen Teammitglieder miteinander und die Zahlen werden realistisch. Demnach solltest du Story Points letztlich _intuitiv_ korrigieren, wenn ein gemeinsames Bauchgefühl euch sagt, das die Buchlösung so nicht hinhaut.

    Reply
  2. Bei uns wird nicht Komplexität geschätzt, sondern der Aufwand – wenn auch in abstrakten Werten.
    Eine simple Aufgabe die einen Entwickler aufgrund des zeitlichen Aufwands die ganze Timebox beschäftigt ist genauso hoch geschätzt, wie eine komplexe Aufgabe, die einen Entwicker die ganze Timebox aufgrund der Komplexität beschäftigt. (ist wohl auch die Aussage von Mike Cohn).

    Somit bleibt bei verschiedenen Komplexitäten, aber gleichem Aufwand, die Velocity auch auf gleicher Höhe. Und das erwartet man ja auch?!

    Reply
  3. Cohn behauptet, das beide Tätigkeiten eine unterschiedliche Komplexität haben, aber diese Sicht ist meiner Ansicht nach falsch. Angenommen der professionelle Briefmarken-Lecker kann 10000 Briefmarken in der gleichen Zeitspanne lecken, in der ein Chirurg einen chirurgischen Eingriff durchführen kann. Sagt dies tatsächlich etwas über die Komplexität der beiden Tätigkeiten aus? Nein, absolut nicht.
    Wie verhält es sich beispielsweise, wenn man die Rollen vertauscht und der Chirurg nun Briefmarken lecken und der Profi-Briefmarkenlecker den gleichen chirurgischen Eingriff vornehmen soll?
    Beide werde vermutlich Schwierigkeiten haben, den die gleiche Aufgabe in gleichem Masse zu lösen. Und bei einem Metzger und einem Chirurgen bin ich mir nicht gar nicht so sicher, wer bei einem Rollentausch grössere Schwierigkeiten haben würde, die Aufgabe zu lösen.
    Der springende Punkt ist, dass sie alle Fachexperten einer spezifischen Domäne sind. Die Komplexität einer Tätigkeit muss daher immer relativ zur Expertise des Durchführenden und nicht absolut betrachtet werden.

    Reply
  4. Aus meiner Sicht ist es eine Fehleinschätzung, dass es nicht sehr komplex ist 1000 Briefmarken zu lecken, weil man nicht zwischen dem Fall unterscheidet eine Briefmarke zu lecken oder eben 1000. Eine Briefmarke zu lecken ist ganz bestimmt nicht komplex. Die Komplexität entsteht aber durch die 1000malige Wiederholung

    Reply
  5. Was spricht eigentlich gegen die Schätzung anhand idealer Stunden/Tage? Außer dem Versuch, dem Kunden sagen zu wollen „das ist alles gar nicht abschätzbar, Aufwand, Kosten, Termine – mach dir gar nicht erst die Mühe“ sehe ich keine Vorteile. Wenn ich aber irgendjemand frage, wie lange sie für die Umsetzung einer ihr bekannten Aufgabe braucht, kommt fast immer eine sinnvolle erste Abschätzung. Wenn ich meine 7jährige frage, wie lange es dauert einen Kuchen zu backen, sagt sie irgendwas zwischen einer halben und einer Stunde. Dann kann man das ganze noch mit einem eventuellen Multitaskingaufschlag und einem Sicherheitsbuffer versehen. Aber Storypoints? Für relative Komplexität? Das macht alles sehr den Eindruck von möglichst unverständlich machen damit die Nichtinsider nichts checken. Hier in der Schweiz werden ärztliche Leistungen auf Basis so genannter Taxpunkte verrechnet. Das System hinterlässt genau den selben Eindruck der gewollten Intransparenz.

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen