Scrum-Leitfaden | 11. Statistiken und Metriken, die der Scrum Master verfolgen sollte

Veröffentlicht: 2022-04-21

Warum braucht der Scrum Master Statistiken und Metriken? Erstens, um zu überprüfen, ob seine Methoden zur Arbeit an der Vorhersagbarkeit von Ergebnissen und zur Verbesserung der Effektivität des Teams effektiv sind. Aber auch, um zu verfolgen, wie sich ihre Aktionen auf das Entwicklungsteam auswirken. Das heißt, wie sie die User Experience (UX) der Mitarbeiter gestalten. Daher stellen wir in diesem Artikel Statistiken und Metriken vor, die der Scrum Master verfolgen sollte.

Wichtige Statistiken und Metriken für den Scrum Master – Inhaltsverzeichnis:

  1. Messung der Ergebnisse der Arbeit des Entwicklungsteams
  2. Überwachung der Benutzererfahrung der Mitarbeiter Entwickler
  3. Zusammenfassung

Messung der Ergebnisse der Arbeit des Entwicklungsteams

Die am häufigsten verwendeten Statistiken und Metriken, die der Scrum Master verfolgen sollte, sind diejenigen, die das Tempo und den Ablauf der Aufgabenausführung beschreiben. Dies sind das Burnup Chart, das Burnup Chart und das Cumulative Flow Chart. Diese messen sowohl die Produktentwicklung als auch die Teameffektivität. Jedes ermöglicht es Ihnen, diese Themen aus einem anderen Blickwinkel anzugehen, daher ist es eine gute Idee, sie zusammen zu zeigen. Sie sind praktische Werkzeuge, um den Fortschritt auf verschiedenen Ebenen zu bewerten, sowohl während eines Sprints als auch während des gesamten Produktentwicklungsprozesses.

Statistics and metrics

Burndown-Diagramm

Das Burndown-Diagramm zeigt dem Scrum Master und dem Entwicklungsteam, wie viel Arbeit geleistet wurde und wie viel noch zu tun ist. Die X-Achse zeigt die verbleibende Zeit, um die Arbeit abzuschließen. Die Y-Achse zeigt die noch zu erledigende Arbeit, die im Sprint Backlog oder Product Backlog geplant wurde.

Dieses Diagramm hilft auch dabei, die Geschwindigkeit des Entwicklungsteams zu bestimmen, der wir ebenfalls einen eigenen Artikel widmen werden. Hier erwähnen wir nur, dass es sich um eine durchschnittliche Menge an Arbeit handelt, die während eines Sprints geleistet wird.

Mit diesem einfachen Tool kann der Scrum Master nicht nur sehen, wie effizient das Team arbeitet. Es hilft auch bei der Beantwortung von Fragen:

  • Welcher Teil der Arbeit ist bereits abgeschlossen?
  • Wie viele Aufgaben sind noch zu erledigen?
  • Wie lange dauert die Entwicklung des Produkts?

Bei der Verwendung des Burndown-Diagramms muss der Scrum Master bedenken, dass es nicht das einzige Werkzeug ist, um den Fortschritt des Teams statistisch zu bewerten. Es funktioniert am besten für Projekte, bei denen der Arbeitsumfang festgelegt und bekannt ist. Es funktioniert nicht gut, wenn es darum geht, sehr innovative Lösungen mit einem neuen Kunden zu erstellen. Dann kann sich der Arbeitsumfang des gesamten Projekts – also der Inhalt des Product Backlogs – während des Projekts erheblich ändern, was die Nutzung des Burndown Charts erschwert.

Abbranddiagramm

Das Burnup-Chart ist die Umkehrung des oben besprochenen Burndown-Charts. Auch hier zeigt die Y-Achse die noch zu erledigende Arbeit. Die X-Achse hingegen zeigt die Fertigstellungszeit, ausgedrückt entweder in der Anzahl der Sprints oder in Daten.

Der Scrum Master verwendet Burnup Chart jedoch für einen etwas anderen Zweck. Dies liegt daran, dass es Ihnen nicht nur hilft, den Fortschritt des Produkts und den Fortschritt des Teams zu messen. Diese Kennzahl bewertet auch, wie sich der Arbeitsumfang in einem Projekt im Laufe der Zeit verändert. Daher eignet es sich gut für Projekte mit variablem Umfang.

Das Burnup Chart ist auch ein Planungsinstrument, das mit der Zeit immer effektiver wird. Es gibt Antworten auf die Frage, wie viel Arbeit das Entwicklungsteam voraussichtlich im nächsten Sprint leisten wird.

Kumulatives Flussdiagramm

Der dritte Diagrammtyp, der in der Arbeit des Scrum Masters mit dem Entwicklungsteam sehr fruchtbar ist, ist das kumulative Flussdiagramm. Es enthält die Analyse, wie stabil das Tempo und die Produktivität des Entwicklungsteams sind. Das Layout seiner Achsen ist das gleiche wie beim Burnup Chart, daher wird es oft als seine komplexere Version bezeichnet.

Das kumulative Flussdiagramm dient jedoch nicht nur dazu, die Anzahl der Aufgaben zu bestimmen, die in einem bestimmten Zeitraum erledigt wurden. Es berücksichtigt auch die Anzahl der Tasks, die in der Warteschlange auf die Ausführung warten. Dadurch ist es möglich, die sogenannten „Engpässe“ zu diagnostizieren – Momente des Prozesses, die die Entstehung eines Produkts verlangsamen.

Dieses sehr diagnostische Merkmal macht es zu einer der nützlichsten Metriken in den Händen des Scrum Masters. Dies liegt daran, dass die Arbeit so neu organisiert werden kann, dass die Kräfte des Entwicklungsteams anders verteilt und Ausfallzeiten vermieden werden.

Statistics and metrics the Scrum Master should track

Überwachung der Benutzererfahrung der Mitarbeiter Entwickler

Die regelmäßige und sorgfältige Pflege und Analyse von Statistiken ist ein wesentlicher Bestandteil der Arbeit eines effektiven Scrum Masters. Allerdings muss er/sie zuerst die Employee User Experience der Entwickler im Auge behalten, also wie sie die Arbeit im Scrum Team wahrnehmen. Allerdings entscheidet nicht die Qualität der Metriken, sondern die Art und Weise, wie der Scrum Master sie einsetzt.

Wenn die Statistiken gemäß den Scrum-Prinzipien geführt werden – sie sind transparent, öffentlich und für die beteiligten Entwickler verständlich – können sie ein Weg sein, das Team zu effizienterer Arbeit zu motivieren oder es für großartige Ergebnisse zu belohnen. Statistiken können jedoch als Werkzeug dienen, um Druck auf das Entwicklungsteam auszuüben. Dann werden ihre Hinweise zu einem Generator von Anschuldigungen und Ressentiments. Sie können dazu beitragen, die Teammoral zu verschlechtern und Teamwork-Praktiken zu verderben.

Der zweite wichtige Faktor der Mitarbeitererfahrung von Entwicklern, um den sich der mit statistischen Tools arbeitende Scrum Master kümmern muss, ist die Art und Weise, wie er seine Zeit verwaltet. Denn der Scrum Master muss genügend Zeit haben, um sich um das Entwicklungsteam zu kümmern. Aus diesem Grund lohnt es sich, bei einem großen Projekt darüber nachzudenken, eine weitere Person in das Scrum-Team aufzunehmen. Er/sie fungiert als Projektmanager und kümmert sich um die Metriken. Dadurch entlastet es den Scrum Master – und teilweise auch den Product Owner – von den Aufgaben, die ihn von der Zusammenarbeit mit dem Entwicklungsteam ablenken.

Statistiken und Metriken – Zusammenfassung

Der Scrum Master sollte die grundlegenden Statistiken verfolgen, die die Arbeit des Entwicklungsteams beschreiben. Ihre geschickte Interpretation erhöht die Chance, Probleme in der Arbeit des Teams schnell zu erkennen und darauf zu reagieren. Wichtiger als das Führen der Charts ist jedoch, was der Scrum Master damit macht. Sie sollten die Metriken nicht als Instrument zur Bewertung des Teams betrachten, sondern als nützliche Hilfe bei der Motivation des Teams und der Diagnose ihrer eigenen Arbeitsweise. Dies liegt daran, dass Metriken nur dann nützliche Werkzeuge sind, wenn sie dazu beitragen , die Team- und Produktverbesserungsprozesse zu erleichtern.

Wenn Ihnen unsere Inhalte gefallen, treten Sie unserer fleißigen Bienen-Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube bei.

Scrum Guide | 11. Statistics and metrics the Scrum Master should track caroline becker avatar 1background

Autorin: Caroline Becker

Als Projektmanagerin ist Caroline Expertin darin, neue Methoden zu finden, um die besten Arbeitsabläufe zu gestalten und Prozesse zu optimieren. Ihre organisatorischen Fähigkeiten und ihre Fähigkeit, unter Zeitdruck zu arbeiten, machen sie zur besten Person, um komplizierte Projekte in die Realität umzusetzen.

Alle Beiträge anzeigen

Scrum-Leitfaden:

  1. Glossar der Grundbegriffe, Rollen und Begriffe
  2. Was ist Scrum?
  3. Scrum-Werte
  4. Wie implementieren Sie Scrum in Ihrem Unternehmen?
  5. Scrum Team – was ist das und wie funktioniert es?
  6. Wer ist ein Product Owner?
  7. Die häufigsten Fehler des Product Owners
  8. Wer ist der Scrum-Master?
  9. Eigenschaften eines guten Scrum Masters
  10. Die häufigsten Fehler des Scrum Masters
  11. Welche Statistiken und Metriken sollte der Scrum Master verfolgen?
  12. Zusammenarbeit zwischen Product Owner und Scrum Master
  13. Entwicklungsteam in Scrum
  14. Die häufigsten Fehler von Entwicklern
  15. Scrum-Artefakte
  16. Scrum skalieren
  17. Sprint-Rückstand
  18. Was ist das Product Backlog?
  19. Was sind User Stories?
  20. Erstellen Sie die beste User Story mit INVEST
  21. Die häufigsten Fehler in User Storys
  22. Akzeptanzkriterien für User Storys
  23. Schätzung und Story Points in Scrum
  24. Planungspoker
  25. Team-Schätzspiel
  26. Inkrement definieren
  27. Scrum-Ereignisse
  28. Was ist Sprint in Scrum?
  29. Verpflichtungen des Scrum-Teams – Produktziel, Sprintziel und Abschlussdefinition
  30. Was ist ein Burndown-Diagramm?
  31. Wie erstellt und interpretiert man ein Burndown-Diagramm?
  32. Vor- und Nachteile des Burndown-Charts
  33. Kanban-Boards in Scrum und Scrumban
  34. Velocity in Scrum - Schnelligkeit des Entwicklungsteams
  35. Tägliches Scrum
  36. Sprint-Planung
  37. Sprint-Review
  38. Was ist eine Sprint-Retrospektive?
  39. Häufige Fehler während einer Sprint-Retrospektive
  40. Pflege des Produkt-Backlogs