Die Frage gegenüber dieser und dieser .
Manchmal nehmen Scrum-Events viel weniger Zeit in Anspruch, als der Scrum Guide vorschreibt. Ist es ein Signal, dass wir etwas falsch gemacht haben?
Wie üblich meine Gedanken zu diesem Thema zur Klärung:
Tägliches Scrum. Ich denke, das ist in Ordnung, wenn dieses Ereignis weniger als 15 Minuten dauert. Es hängt von der Teamgröße ab. Kleineres Team – weniger Zeit.
Sprint-Planung. Wie ich in dieser Frage sagte, nahm dieses Ereignis zu Beginn von Projekten (wenn das Product Backlog noch nicht gut verfeinert ist) viel mehr Zeit für unser Team in Anspruch. Aber dann (insbesondere gegen Ende von Projekten) verbringen wir viel weniger Zeit mit der Planung, als der Scrum Guide vorschreibt. Sollte es ein Problem für uns sein?
Sprint-Review. Mein Team hat nie weniger Zeit für dieses Event aufgewendet, als Scrum Guide vorschreibt. Aber wenn es passieren wird, was kann es signalisieren?
Sprint-Retrospektive. Das gleiche wie Sprint Review. Wir haben immer was mit meinem Team zu besprechen. Aber wenn es passieren wird, was kann es signalisieren?
Über die Verfeinerung des Product Backlogs. Das gleiche wie Sprint-Planung. Es hat mehr als 10 Prozent der Teamkapazität (schätze ich, ich habe es nie genau berechnet) am Anfang von Projekten und weniger am Ende gekostet. Ist das ok?
Wichtig ist nicht wirklich, wie lange diese Ereignisse dauern, sondern ob Sie die gewünschten Ergebnisse erzielen.
Beispielsweise könnte das Daily Scrum nur fünf Minuten dauern, weil alle nur ein Taskboard-Update geben und sich gegenseitig weitgehend ignorieren, was natürlich schlecht wäre. Andererseits kann es 5 Minuten dauern, weil sowieso alle den ganzen Tag über reden und sich nur ein bisschen anstrengen müssen.
Wenn die Zeiten nicht wirklich extrem sind, ist es schwer, aus der Zeit etwas abzuleiten, das nicht einfacher ist, von einem anderen Indikator wegzukommen.
Was den Trend betrifft, den Sie beim Sprint-Planning und bei der Backlog-Verfeinerung sehen, ist dies bis zu einem gewissen Grad normal. Wenn der Unterschied zwischen Anfang und Ende erheblich ist, kann es andere Schwierigkeiten geben. Wenn Sie beispielsweise Ihre Teams um jedes neue Projekt herum reformieren (oder die Product Owner wechseln), durchlaufen sie möglicherweise jedes Mal die Tuckman-Phasen , was dazu führt, dass sie zu Beginn des Projekts weniger effektiv sind. Auch hier würden andere Metriken diese Art von Problemen viel besser aufdecken als die Zeit.
Solange das Ergebnis nicht unter Zeitmangel leidet, sind kürzere Veranstaltungen völlig normal. „Timeboxing“ bedeutet, dass Sie die Veranstaltung unterbrechen und mit Teilergebnissen fortfahren müssen, wenn die zugewiesene Zeit abgelaufen ist, es spricht nichts dafür, früher zu beenden.
Sie sollten die Ergebnisse jedoch sorgfältig überprüfen. Wenn das Team der Meinung ist, dass es einen inhärenten Wert hat, früher fertig zu werden (sie sehen sich beispielsweise als „effizienter“), können sie Qualität oder Gründlichkeit zugunsten von Geschwindigkeit aufgeben. in diesem Fall muss der Scrum Master sie zum richtigen Verhalten zurückführen.
Um Daniels Argument zu erweitern: Eine Timebox ist kein Rezept dafür, wie lange ein Ereignis dauern sollte. Vielmehr ist eine Timebox einfach die maximale Zeit, die ein Event dauern kann, bevor der Scrum Master das Team coacht, um das Event innerhalb seiner Timebox zu halten. Wenn das Ziel des Events vor Ablauf der Timebox erreicht wird, umso besser.