Eine alternative Festlegung von Sprint-Längen
Bild: Wikimedia Commons/Photobobil - CC BY 2.0 |
Für Unternehmen die mit Scrum arbeiten kann das ein Problem sein. In den Mai-Sprints stehen weniger Arbeitstage zur Verfügung, es wird weniger vervollständigt, die Velocity sinkt. Und an dieser Stelle tritt ein Verfälschungseffekt ein: das Sinken der Velocity liegt nicht an sinkender Leistungsfähigkeit sondern eben an den Feier- und Brückentagen. Das lässt sich allerdings aus den Zahlen nicht herauslesen - sowohl in der kurzfristigen als auch in der langfristigen Auswertung wirkt das Absinken wie ein Leistungsabfall. Wenn man jetzt basierend auf der Velocity eine Prognose der verbleibenden Arbeitszeit machen will wird diese unrealistisch niedrig sein.
Ein Unternehmen mit dem ich vor ein paar Jahren zu tun hatte, hatte einen interessanten Weg gefunden mit diesem Effekt umzugehen: Sprint-Längen wurden dort nicht in Wochen festgelegt sondern in Arbeitstagen, z.B. 10 Arbeitstage pro Sprint. Ein Sprint im letzten Mai hätte demnach nicht einfach die Kalenderwochen 20 und 21 umfasst sondern wäre wegen des Feiertages am Pfingstmontag erst am 17. losgegangen und 10 Werktage später am Montag dem 30. beendet worden.
Für jedes Unternehmen das auf diese Weise vorgeht hat die Velocity eine wesentlich höhere Aussagekraft und Brauchbarkeit als für diejenigen, die noch mit Kalenderwochen arbeiten. Auf der Negativseite ist es dafür aber auch so, dass der "gefühlte Rhytmus" aus dem Gleichgewicht kommen kann, schließlich können Planning, Review und Retrospektive jetzt nicht mehr alle zwei Wochen stattfinden sondern gegebenenfalls etwas später. Vor allem bei der Einbindung von Stakeholdern kann das zu Problemen führen.
Andererseits - irgendwelche Probleme gibt es ja immer. Für mich kommt diese alternative Festlegung von Sprint-Längen auf jeden Fall auf die Liste der Dinge die ich irgendwann mal ausprobieren muss.