Skandal! Scrum Master gibt keine Story Points für (fast) fertige Story

Was passiert mit den Story Points einer User Story, die im Sprint angefangen, aber nicht fertig wurde?

Die User Story geht zurück ins Backlog und der noch zu erledigende Teil wird neu mit Story Points geschätzt (so handhabe ich Scrum, wenn ich als Scrum Master in einem Team arbeite). Dann kann es passieren, dass eine 5er Story zu einer 3er Story wird. Wird die Story im nächsten Sprint ebenfalls nicht fertig, könnten sich die verbleibenden Story Points zu 1 SP reduzieren. Ich habe erlebt, dass Dev-Team und P.O. mit dieser restriktiven Vorgehensweise nicht einverstanden waren. Das Dev-Team beklagt sich, dass die bislang geleistete Arbeit keine Story Points eingebracht hat, der P.O. beklagt sich, dass die Velocity verringert wird und dies Auswirkungen auf die Release-Planung hat.

Ist es also ungerecht, die geleistete Arbeit hinsichtlich Story Points zu ignorieren, weil die Arbeit nicht fertig wurde?
Wenn wir Input-getrieben arbeiten würden, also allein schon die investierten Aufwände honorieren würden, wäre es in der Tat ungerecht. Immerhin wurde ja Arbeit erbracht. Da wir in Scrum aber Output-getrieben arbeiten ist es unerheblich, ob viel oder wenig Arbeit investiert wurde, allein das Ergebnis zählt. Dies mag von manchen als hart erachtet werden und ungewohnt sein.
Das Scrum Team sollte sich jedoch dieser Situation stellen und überlegen, warum diese Story nicht fertig wurde. Ein restriktiver Umgang mit Story Points kann das Team zur Verbesserung anspornen.

Was kann das Dev-Team daraus lernen? Reduziert das Risiko, dass Storys im Sprint nicht fertig werden.

Wie kann das Dev-Team diese Situation in Zukunft vermeiden?

• Macht im Refinement die Storys so klein es geht. Scheut euch nicht, vom P.O. eine Aufteilung in weitere kleinere Story zu fordern. Warum nicht einmal Storys mit 1 SP anstreben?
• Fokussiert euch auf die Story mit höchster Priorität und versucht, diese möglichst schnell (1-2 Tage) dem P.O. zur Abnahme vorzulegen.
• Optimiert die Arbeitsabläufe nicht auf persönlicher Basis („Ich habe meinen Arbeitstag gut mit Arbeit ausgefüllt“), sondern auf Team-Basis („Wir haben dies bei der wichtigsten Story erreicht“).
• Legt euch im Planning die Arbeit so zurecht, dass sie möglichst leicht und einfach von der Hand geht. Hier entwickelt ihr einen Plan, um durch den Sprint zu kommen. Arbeitet auch hier gemeinsam (d.h. alle, auch der/die da hinten). Das ist euer Meeting, nehmt euch die Zeit.
• Seid sensibilisiert, wenn im Daily Scrum klar wird, woran eure Kollegen und Kolleginnen gerade arbeiten. Seid selbst fokussiert und verlangt Fokussierung von den anderen.
• Überlegt im Daily Scrum, ob der Plan euch noch durch den Sprint tragen kann. Falls nicht, ändert ihn jetzt.
• Vermeidet „Story Overload“. Manche Auffälligkeiten sind keine Fehler, sondern Verbesserungen, die als neues Backlog-Item behandelt werden sollten.
• Ladet euch den Sprint nicht zu voll. Ihr wollt die DoD einhalten und ihr braucht auch Luft zum Atmen.
  
  

*

Bildnachweis: istockphoto.com/Sean Anthony Eddy