Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben....

13
Agile Metrics Lassen wir die Zahlen sprechen

Transcript of Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben....

Page 1: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

Agile MetricsLassen wir die Zahlen sprechen

Page 2: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

Inhalt

Die wichtigste Frage, die bei der Scrum-Einführung zu beantworten ist 3

Wie zufrieden sind unser Scrum-Team und die Stakeholder? 6

Verbessern wir laufend unsere Teamreife? 7

Sind unsere Entwicklungsbemühungen abgestimmt mit dem Geschäftsbetrieb? 9

Erhöhen wir die Menge der abgelieferten Arbeit? 10

Entspricht die Qualität der Norm? 12

Zusammenfassung 13

Anhänge 14

Page 3: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

Einführung

Ob wir uns dessen bewusst sind oder nicht, wir alle messen täglich etwas. Wenn wir am Morgen ins Auto steigen, schauen wir auf den Tacho, um nicht zu schnell zu fahren; wir steigen ab und zu auf eine Waage, um unser Gewicht zu kontrollieren; Lehrer und Mitschüler haben unsere Fähigkeiten von früh an beurteilt; die Liste ließe sich beliebig fortsetzen. Warum messen wir also etwas? Wir messen, damit wir etwas unternehmen können für den Fall, dass das Gemessene nicht mit dem Erwarteten oder Gewünschten übereinstimmt. Das bringt uns zum Hauptthema dieses Artikels: Messergebnisse bzw. Kennzahlen sollten immer in Maßnahmen umgesetzt werden können. Es sollte klar sein, was die gemessenen Daten bedeuten und es sollte klar sein, welche Maßnahmen man aufgrund der Daten ergreift. Es gibt Hunderte von Maß- und Kennzahlen für Softwareentwicklung und Scrum und nicht alle sind sinnvoll.

Kennzahlen sollten ein Kernelement eines jeden (Software-)Entwicklungsprozesses sein. Dankenswerterweise macht Scrum mit seinen

iterativen Grundzügen das Sammeln dieser Kennzahlen und die entsprechende Reaktion darauf extrem einfach. In diesem Artikel möchten wir dem Leser Kennzahlen an die Hand geben, die wir aufgrund unserer langjährigen Erfahrung im Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team verwenden sollte, hängt vom jeweiligen Kontext ab. Hier möchten wir dem Leser einen Einblick für den Anfang geben.

Die wichtigste Frage, die bei der Scrum-Einführung zu beantworten ist

Wir brauchen ein strukturiertes Vorgehen, um aus der Liste aller von uns über die Jahre erstellten Kennzahlen eine Minimalgruppe zusammenzustellen. Es gibt verschiedene Modelle wie man die Auswahl von Kennzahlen trifft, um Softwareeigenschaften zu bewerten. Ein häufig genutzter Ansatz ist das „Goal QuestionMetric (GQM)“. Er entstammt der Forschung bei der Fehlerauswertung im NASA Goddard Space Flight Center im Jahr 19841. Er wurde angepasst und dient als Qualitätsverbesserungsmethode in der Softwareentwicklung.

Kurz gesagt bricht der GQM-Ansatz die qualitativen Kennzahlen von oben nach unten herunter; ein Unternehmen muß bestimmte Ziele erreichen, die Kennzahlen sollten zeigen, ob man diese Ziele erreicht hat oder nicht und sie sollten in der Lage sein, das Unternehmen anzuleiten wie man diese Ziele erreichen kann2.

Ein Ziel wird in ein bestimmtes Format ab geschichtet, sodass es einen Zweck, ein Thema, das Objekt bzw. der Prozess des Fokus und den Blickwinkel, wozu oder zu wem das Ziel in Beziehung steht, enthält. Bestimmte Fragen werden ausgewählt, die den Kontext des Ziels setzen. Wenn diese Fragen beantwortet wurden, sollten wir wissen, ob das Ziel erreicht worden ist. Die Kennzahlen geben die Antwort auf diese Fragen.

Nehmen wir als anschauliches Beispiel das Ziel einer Banking App für ein mobiles Endgerät: Verbessere die wahrgenommene Antwortbereitschaft der mobilen Banking App vom Standpunkt des Nutzers aus.

Figure 1, A breakdown of a GQM goal.

Page 4: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

Eine Frage, die wir mit diesem Ziel verbinden könnten, wäre: „Was ist die Beziehung zwischen der Hochfahrzeit und der wahrgenommenen Antwortbereitschaft?“. Die Kennzahl, die wir hier verwenden würden, wäre die Hochfahrzeit jeder Iteration des bisherigen Produkts und die Antwortbereitschaft wie sie von den Nutzern der App beurteilt wird. Eine andere Frage, die man mit dem Ziel verbinden könnte, wäre: „Wie schnell lassen sich die Apps des Wettbewerbs hochfahren?“. Möglicherweise ist das das Kriterium nach dem die Nutzer die App beurteilen.

Wir müssen also ein Ziel für die Benützung von Scrum-Kennzahlen stecken. Warum wollen wir unseren Scrum-Prozess messen? Warum lesen Sie diesen Artikel? Wir denken, dass dieses Ziel ungefähr so beschrieben werden kann: Um die Ergebnisse der Scrum-Implementierung aus Sicht des Business zu verbessern. Natürlich ist eine Scrum-Implementierung vielschichtig und wir müssen sicherstellen, dass unsere Auswahl an Kennzahlen alle Aspekte der Scrum-Implementierung abdeckt. Die Fragen, die wir mit unserem Ziel verbinden, müssen ebenfalls dieser Vielschichtigkeit Rechnung tragen.

Wir haben diese Aspekte, die Hauptbereiche einer Scrum-Implementierung, in die folgenden Fragen übersetzt: Zufriedenheit der Stakeholder (Wie zufrieden sind unsere Kunden? Wie zufrieden ist das Team?), die Reife des Teams (Verbessern wir

uns laufend?), der Abgleich mit dem Business (Liegt der Fokus auf der Wertsteigerung des Business?), und die Menge und Qualität der übergebenen Arbeit.

Diese fünf Hauptbereiche sind gegenseitig verknüpft: es ergibt keinen Sinn, auf eine Steigerung der Produktivität zu setzen (Quantität), wenn es einen Verlust an Qualität bedeutet. Ebenso, wenn man hochwertige Arbeit übergibt (Abgleich mit Business), sie aber nicht mit Wissenstransfer verbindet (Reife), dann ist es vielleicht auf kurze Sicht nützlich, wird einen aber auf längere Sicht schaden. Und Zufriedenheit ist natürlich generell eine Eigenschaft, die immer erreicht werden soll. Wir haben eine Liste an Fragen definiert, die unser Ziel mit dem GQM-Modell zusammenbringt:

• Wie zufrieden sind das Scrum-Team und die Stakeholder?• Verbessern wir uns laufend?• Ist unsere Entwicklungsarbeit gleichgerichtet mit dem Business?• Steigern wir die Menge an Arbeit, die wir übergeben?• Paßt die Qualität der Arbeit zu der Norm?

Die folgenden Absätze beschreiben die Kennzahlen, die wir vorschlagen, um obige Fragen zu beantworten. Es gibt selbstverständlich weitaus mehr Kennzahlen als diejenigen, die wir im folgenden vorstellen werden. Das Ziel ist, die

Figure 2, this paper’s goal and questions visualized.

Page 5: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

Anzahl überschaubar, aber abschließend zu halten im Hinblick auf die Hauptbereiche von Scrum. Es muß außerdem eine ursächliche Beziehung zwischen einer Kennzahl und der Leistung eines Teams oder eines Unternehmens bestehen. Die Auswertung der Antworten bei der Messung helfen eine Liste an Verbesserungen zu erstellen. Diese Verbesserungen wiederum sollten zu besseren Ergebnissen führen.

Wie zufrieden sind unser Scrum-Team und die Stakeholder?

Wir messen Zufriedenheit aus zwei Perspektiven, der Angebots- und Nachfrageseite. Das Scrum-Team ist in diesem Fall die Angebotsseite. Wir

verwenden die Kennzahl „Teammitglieder-Zufriedenheit“ für die Angebotsseite und „Net Promoter Score“ (NPS) für das Business, die Nachfrageseite in diesem Fall. (Siehe Anhang A mit einer Zusammenfassung dieser Kennzahlen.)

„Teammitglieder-Zufriedenheit“ ist für uns eine wichtige Kennzahl, weil Dinge die während der Entwicklung gut oder schief laufen sich fast immer auf die Zufriedenheit der damit Befassten auswirken. „Teammitglieder-Zufriedenheit“ wird üblicherweise am Ende eines Sprints erhoben. Fünf Post-it werden an einer Wand befestigt. Jedes Teammitglied wird gebeten, einen Sticker neben ein numeriertes Post-it zu heften, das der gegenwärtigen Zufriedenheit entspricht, wobei 1 = sehr unzufrieden und 5 = sehr zufrieden bedeutet. Jedes Teammitglied wird außerdem gebeten, vorzutragen, was zur Steigerung der Zufriedenheit beim nächsten Sprint getan werden müßte. Dieser

Aspekt macht die Zufriedenheitskennzahl besonders tatkräftig und trotzdem leichtgängig. Üblicherweise braucht man nicht besonders viel Zeit, um die latenten Schwierigkeiten bzw. funktionierende Dinge in den Blickpunkt zu rücken.

Abbildung 3 zeigt Messwerte der Zufriedenheitskennzahl, die von einem Scrum-Coach im Verlauf von 15 Sprints gesammelt wurden. Beachten Sie die Tiefpunkte bei Sprint 1 und 12 und die kleineren Dellen bei Sprint 5 und 9. Ohne weitere Informationen kann man diese Messwerte nicht aufklären. Bei Sprint 1 lag es daran, dass Scrum gerade losging, was beim Team Anlaß zu große Befürchtungen und Stress auslöste. Der Tiefpunkt bei Sprint 12 lag daran, dass etliche Teammitglieder krank gemeldet waren und das Team daher nicht in der Lage war, den Sprint erfolgreich abzuschließen. Die Sprints 5 und 9 markieren die Fertigstellung eines Release. Sobald der Release näher rückt, fangen die Teammitglieder an, Stress zu empfinden. Die Auswertung dieser Daten erfordert dieses Hintergrundwissen, ansonsten kann man die Zahlen der Abbildung nicht verstehen.

NPS ist eine Kennzahl, die von vielen Unternehmen in unterschiedlichen Bereichen angewendet wird. Während „Teammitglieder-Zufriedenheit“ sich auf das Scrum-Team bezieht, fokussiert NPS auf den

Kunden. Es wird verwendet, um auszumachen wie wahrscheinlich der Kunde ein Produkt weiterempfehlen würde. Dies wird als Hauptindikator für Kundenzufriedenheit gesehen. Die Kunden bzw. Stakeholder benoten die Teamleistung auf

Figure 3, a Happiness metric spanning 15 sprints.

Figure 4, The Net Promotor Score of a team

Page 6: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

einer Skala von 1 bis 10. Bewertungen von 8 und höher werden gewöhnlich erwartet. In Abbildung 4 kann man sehen, dass der NPS am Anfang relativ niedrig ist. Dies ist nicht überraschend, da die ersten Sprints eines Teams chaotisch können und meist mit Stress und Unzufriedenheit verbunden sind. Wir erkennen, dass der NPS rasch ansteigt bis es einen plötzlichen Abfall gibt, der durch einen Quantitätsverlust bedingt sein könnte aber auch durch einen neu ernannten Stakeholder, dem Scrum nicht vertraut war. Wir brauchen wiederum den Kontext, um die Daten zu interpretieren.

Verbessern wir laufend unsere Teamreife?

Der Zweiklang „Inspizieren – adaptieren“ gilt nicht allein für die Softwareprodukte. Das Scrum-Team selbst muß fortlaufend seine eigenen Prozesse und Fähigkeiten inspizieren und adaptieren, und nach beständiger Verbesserung streben. Teams, die

es versäumen hinzuzulernen, werden stagnieren und am Ende nicht zurechtkommen. Daher muß neues Wissen erarbeitet werden und zwischen den Teams ausgetauscht werden sowie Abhängigkeiten von einzelnen Personen minimiert werden, um Kontinuität zu gewährleisten. In manchen Unternehmen gehört das zum Standard und diese Art von Prozesse geschehen auf „natürliche“ Weise. In anderen Fällen ist es ggf. nötig bei jedem Sprint Zeit für einen Wissenstransfer einzuplanen. Wir schlagen ein Quartett an Kennzahlen vor, um diesen Transparenzprozess wirklich transparent zu machen. (Siehe Anhang B mit einer Zusammenfassung dieser Kennzahlen.)

Der „Anteil erfolgreicher Sprints“ zeigt wie viele Sprints erfolgreich beendet wurden im Verhältnis zur Gesamtzahl an Sprints. Mit der zunehmenden Reife von Scrum-Prozess und Scrum-Team sollte dieser Anteil im Laufe der Zeit steigen. Der „Anteil erfolgreicher Sprints“ ist nur dann aussagekräftig, wenn das Scrum-Team eine bestimmte Anzahl an Sprints absolviert hat. Der „Focus Factor“ zeigt den prozentualen Anteil an Zeit, den das Team für zugesagte Arbeiten aufwendet. Diese Zahl sollte ebenfalls im Laufe der Zeit ansteigen, da die Teammitglieder weniger Zeit auf andere Aktivitäten verwenden, wenn sie mit der Scrum-Arbeitsweise vertraut sind. Im formalen Sinn zeigt dieser Anteil wie viel Zeit auf verlangte, fertig gestellte und abgenommene Software verwendet wurde. Der „Focus Factor“ wird berechnet indem man die Arbeitskapazität durch die ursprüngliche Summe der geschätzten „Story Points“ (die Geschwindigkeit) eines Teams teilt. Die Arbeitskapazität ist einfach die Summe der gemeldeten Arbeitszeit. Da wir Prozentanteile und relative Werte hier verwenden, können wir mit dem „Focus Factor“ Teams vergleichen. Genau wie beim „Anteil erfolgreicher Sprints“ erwarten wir, dass der „Focus Factor“ im Laufe der Zeit ansteigt und sich stabilisiert (siehe Abbildung 6). Ein „Focus Factor“ von 0,8 wird als akzeptabel betrachtet.Die Fähigkeit des Teams, exakt den erforderlichen Aufwand für das Sprint Backlog abzuschätzen, ist eine weitere Kennzahl für Reife. Die

„Schätzgenauigkeit“ steigt ebenfalls über die Zeit an. Die „Schätzgenauigkeit“ wird berechnet indem man die tatsächlich für die Erledigung der zugesagten User Stories benötigte Zeit durch die

Figure 5, the Ratio of Successful Sprints

Figure 6, The Focus Factor slowly progressing to the preferred 0,8-1,0 bandwith

Page 7: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

ursprünglich geschätzte Zeit teilt. Das heißt, die Schätzung kann über oder unter dem tatsächlichen Ergebnis liegen (siehe Abbildung 7). Die letzte Kennzahl ist die „Zuverlässigkeit“, welche das Verhältnis von verdienten „Story Points“ zu den zugesagten „Story Points“ ausdrückt. Wenn man bis auf eine Aufgabe alles erledigt hat, bleibt die „User Story“ dennoch auf „not done“, obwohl man viel Aufwand verwendet hat. Die Fähigkeit eines Teams die versprochenen Aufgaben zu erledigen, wird durch diese Kennzahl ausgedrückt. Sie wird berechnet indem man die Anzahl geschätzter „Story Points“ für die erledigten Stories durch die Gesamtzahl geschätzter „Story Points“ des Backlog teilt.

Wir weisen zudem darauf hin, dass „Teammitglieder-Zufriedenheit“ auch die Reife eines Teams anzeigt. Besonders zu Anfang wird es bei jedem Team gewisse Konflikte geben, da man sich aneinander gewöhnen muß. Ist unsere Entwicklungsarbeit gleichgerichtet und abgestimmt mit dem Business?

Tolle Teams können großartige Software liefern, aber wenn die Software keinen Stellenwert hat, wird das Business dennoch nicht zufrieden sein. Deshalb empfehlen wir, dass das Entwicklerteam in enger Abstimmung mit dem Business arbeiten muß. Wir messen diese Abstimmung mit zwei Kennzahlen, der „Return On Investment“ (ROI) und „Total Business Value Earned“. Wir empfehlen zudem eine „End-to-end“-Kennzahl, die zeigt, ob das Team alle Hauptbereiche des Produkts anpackt. (Siehe Anhang C mit einer Zusammenfassung dieser Kennzahlen.)

Um die Ergebnisse eines Teams zu verbessern, müssen wir den Wert ihrer Arbeit transparent machen. Bei linearen Softwareentwicklungsmethoden ist das eine komplexe Angelegenheit. Dank Scrum’s inkrementeller Methode der Softwareentwicklung ist diese Rechnung einfacher zu machen. Wir machen den Wert, den Agile-Teams liefern, sichtbar, indem wir den ROI der „Epics“ und „User Stories“ berechnen. Grob gesagt, kann der ROI auf zwei Wegen berechnet werden. Entweder in dem man den tatsächlichen monetären Wert der „User Stories“ nimmt oder mit einem relativen Wert. Beide Weg haben Vor- und Nachteile. Der Einfachheit halber ziehen wir es vor mit relativen Schätzwerten umzugehen, insbesondere in Unternehmen, für die Scrum neu ist.

Wir verwenden zur Abschätzung eine ähnliche Vorgehensweise wie bei der Aufwandsschätzung und verbinden eine Anzahl von „Value Points“ mit jedem Arbeitsschritt, zum Beispiel mit der Fibonacci-Reihe. Wir nehmen eine „User Story“ (oder eine kleine Gruppe von „User Stories“) und legen einen Basiswert für einen „Value Point“ fest. Es ist wichtig darauf hinzuwiesen, dass der „Business Value“ von Vertretern des Business geschätzt werden sollte, das heißt dem ProductOwner (PO) und den Business-Stakeholders, und nicht von dem Entwicklerteam. Am Ende eines Sprints können alle „Value Points“ der „User Stories“ und Fehler (Bugs) zusammengezählt werden und man erhält den „Total Business Value Earned“. Der ROI wird als Quotient aus „Total Value“ und Schätzwert für den Aufwand berechnet.

Ein guter ProductOwner wird immer mehrere Kennzahlen zu Rate ziehen, wenn er eine Situation beurteilt. Nehmen wir zum Beispiel die Abbildung 8. Sie zeigt nur die Geschwindigkeit des Scrum-Teams. Wir erkennen, dass die Geschwindigkeit nach Sprint 5 stark abnimmt, ein Grund zur Beunruhigung, richtig? Aber was passiert, wenn wir den „Business Value“ dagegen halten? Wie man sehen kann, stieg die Geschwindigkeit während das Team Arbeiten mit geringem „Business Value“ ablieferte. Vielleicht war die Geschwindigkeit künstlich hoch, weil nur kleinere Arbeitspakete

Figure 7, the Estimation Accuracy is slowly stabilizing

Page 8: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

angegangen wurden. Dank der Kombination von Geschwindigkeit und „Total Business Value“ kann man erkennen, dass es unklug wäre, allein auf die Geschwindigkeit zu zielen, wenn man dabei den

„Business Value“ vernachlässigt. Daher muß man den „Business Value“ miteinbeziehen, wenn man das Backlog priorisiert.

Wir schlagen eine „End-to-end“-Kennzahl vor, die zeigt, ob der Aufwand für die wichtigsten Aspekte des Softwareprodukts eingesetzt wurde. Das Softwareprodukt kann in eine Reihe von Komponenten zerlegt werden, zB die Log-in-Komponente, das Zahlungsportal, aber auch weniger fassbare Eigenschaften wie Benutzerfreundlichkeit. Jede „User Story“, zu der sich das Team verpflichtet und die sie abschließt, wird einer dieser Komponenten zugeordnet. Nach einer Reihe von Sprints zeigt diese Kennzahl, ob der Aufwand auf die richtigen Themen verwandt wird.

Erhöhen wir die Menge der abgelieferten Arbeit?

Wir schlagen vier Kennzahlen vor, um zu ermitteln, ob das Team eine durchgängig steigende Menge an Arbeit liefert: Geschwindigkeit, Prozesseffizienz, Release Burndown und Release Burnup. (Siehe Anhang D mit einer Zusammenfassung dieser Kennzahlen.)

Scrum-Teams sollten immer versuchen, die höchstmögliche Geschwindigkeit zu erreichen ohne die Qualität der Arbeit zu opfern. Die Geschwindigkeit eines Teams basiert auf der Anzahl von Story Points, die ein Team während eines Sprints verdient hat. Wenn das Team drei User Stories erledigt die 2, 5 und 13 Punkte wert sind, dann ist die Gesamtgeschwindigkeit dieses Sprints 20 Punkte. Es muß berücksichtigt werden, dass Arbeitszeit für unvorhergesehene Aufgaben hier nicht erfasst wird. Genau wie bei den Value Points einigt sich das Team auf einen Basiswert für eine User Story (oder ein Paket von Stories), der als Norm für Aufwandsschätzung verwendet wird. Das heißt, Geschwindigkeit ist eine relative Kennzahl und kann nicht über Team hinweg verglichen werden. Der Trend der Geschwindigkeitsveränderung kann hingegen zwischen Teams verglichen werden.

Abbildung 10 zeigt die Geschwindigkeit eines

Teams verglichen mit der Vorhersage. Wie man erkennen kann, zeigt die Geschwindigkeit einen positiven Trend, ist aber vielen Änderungen unterworfen, die zu zwischenzeitlichen Einbrüchen führt. In dem Scrum-Team, von dem diese Daten stammen, waren Erkrankungen von Team-Mitgliedern die Ursache. In diesem speziellen Fall

Figure 8, a eam’s Velocity mapped against the earnedBusiness Value.

Figure 9, the End-to-End metric

Figure 10, The Forecasted Velocity versus the Actual Velocity

Page 9: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

kann man nicht viel tun, um das auszugleichen. Wenn jedoch diese Schwankungen durch User Stories verursacht wurden, die zu komplex waren und deshalb nicht innerhalb des Sprints fertiggestellt werden konnten, dann wäre das ein Zeichen an den ProductOwner, einzugreifen und das ProductBacklog zu kontrollieren.

Die Prozesseffizienz zeigt wie effizient die Teammitglieder an einer Aufgabe arbeiten, zu der sie sich verpflichtet haben. Zum Beispiel: wenn jemand an einer User Story mit geschätztem Aufwand von 4 Stunden um 9 Uhr zu arbeiten beginnt, würden wir erwarten, dass er ungefähr um 13 Uhr fertig ist. Wenn die User Story bis 14 Uhr verzögert wird, dann ist die Prozesseffizienz 80% (4/5 Stunden). Die Menschen arbeiten am effizientesten wenn sie sich auf eine einzige Aufgabe konzentrieren, wenngleich eine hohe Prozesseffizienz erwünscht ist, wenn die Menge an Arbeit gesteigert werden soll.

Eine weitere quantitative Kennzahl ist der Sprint Burndown. Der Sprint Burndown zeigt wieviel Arbeit (in Story Points oder Stunden) während eines Sprints (die als „done“ gekennzeichneten Stories) erledigt wurde, wie viel Arbeit übrig ist und wie viel Arbeit idealerweise noch übrig sein sollte. Abbildung 11 zeigt einen Sprint Burndown eines zweiwöchigen Sprints (10 Arbeitstage). Wir sehen, dass das Team mit zunehmender Zeit weiter von der Ideallinie

abweicht. Das wäre der richtige Zeitpunkt, um einzugreifen und sicherzustellen, dass das Team nicht mehr Arbeit annahm als es leisten kann. Auch im umgekehrten Fall ist es kein gutes Zeichen, da dies bedeuten würde, dass das Team die Arbeitsmenge, die es leisten kann, nicht genügend genau geschätzt hat.

Eine andere Variante des Sprint Burndown ist der Release Burnup, dargestellt in Abbildung 12. Diese zeigt den Teamfortschritt in Bezug auf den Release Backlog, nicht den Sprint Backlog. Die Werte der X-Achse sind Sprints (nicht Tage), die Werte der Y-Achse sind Story Points.

Paßt die Qualität der Arbeit zu der Norm?

Die Qualität von einem Stück Software zu schätzen, ist eine schwierige Aufgabe, da Qualität sich oft auf weiche Eigenschaften bezieht, wie z.B Look-and-Feel. Um Softwarequalität greifbar zu machen, beziehen sich Qualitätskriterien gewöhnlich auf Unstimmigkeiten und Fehler, da diese allgemein als sichtbare Zeugnisse niedriger Qualität gelten.(Siehe Anhang E mit einer Zusammenfassung dieser Kennzahlen.)

Wir verwenden zwei Kennzahlen, um zu beurteilen, ob die Qualität der Software hoch ist: die Fehleranzahl und die Fehlergewichtigkeit. Die Fehleranzahl ist einfach die Summe aller

Figure 11, The Sprint Burndown

Figure 12, the Release Burnup

Page 10: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

bekannten Fehler der Software. Natürlich sollte hochwertige Software eine geringe Fehleranzahl haben. Zu berücksichtigen ist, dass die Anzahl der entdeckten Fehler weitgehend von der Stringenz der Testprozesse abhängt. Die Tatsache, dass keine Fehler gefunden wurden, garantiert nicht, dass es keine gibt. Daher sollte man vorsichtig sein, wenn man die Qualität der Arbeit in Bezug auf die Fehleranzahl beurteilt. Wie man in Abbildung 13 sehen kann, ist die

Fehleranzahl bei einem bestimmten Scrum-Team anfänglich niedrig. Das könnte daran liegen, dass in den ersten Sprints nicht viel Funktionalität übergeben wurde. Sobald die Geschwindigkeit zunimmt, nehmen auch die bekannten Fehler zu. Nach einer gewissen Zeit sehen wir, dass das Team kontrollierter arbeitet und vielleicht aufgrund einer besseren Definition von „done“ oder verbesserten Testprozessen die Fehleranzahl zu sinken beginnt.

Die Kennzahl Fehlergewichtigkeit wir verwendet, um die Schwere eines bekannten Fehlers zu beurteilen, da die Anzahl der Fehler allein keinen guten Einblick in die grundsätzliche Qualität der Arbeit gibt. Schließlich ist ein kritischer Fehler im abgebildeten Geschäftsablauf, der zwei Tage Fehlerbehebung benötigt,schmerzlicher als 5 CSS-Layout Fehler, die man innerhalb von wenigen Minuten reparieren kann. Wir stellen fest, je geringer die Softwarequalität ist, desto länger dauert es, einzelne Fehler zu beheben. Daher prüfen wir die Fehlergewichtigkeit und nennen dies Mangel. Wir unterscheiden kleine Mängel, große Mängel und kritische Mängel.Das Scrum-Team kann beurteilen, welches Prädikat

zu welchem Fehler gehört. Vorzugsweise ist die Anzahl der Mängel kritischer Natur geringer als diejenige, welche weniger schwerwiegend sind. In Abbildung 14 sehen wir, dass das Team langsam in diese Richtung arbeitet.

Zusammenfassung

In diesem Artikel haben wir eine handhabbare, verständliche Auswahl an Kennzahlen vorgestellt, die man zur Leistungsbewertung eines Scrum-Teams verwenden kann. Obwohl man in der Literatur viele weitere Kennzahlen finden kann, glauben wir, dass man mit dieser Auswahl gut anfangen kann. Was man aus diesem Artikel lernen sollte, ist, dass es drauf ankommt, die für die jeweilige Situation passenden Kennzahlen anzuwenden. Kennzahlen sind nur dann „richtig“, wenn sie zu Handlungsmöglichkeiten führen. Die Daten, die gesammelt werden, sollten natürlich zu Maßnahmen führen, die sich bei Bedarf auf das Gemessene beziehen. Eine weitere Botschaft ist, dass Kennzahlen auf unterschiedliche Weise interpretiert werden können. Daher ist es wichtig, Daten verschiedener Kennzahlen zusammenzuführen, um den genauesten Schluss daraus zu ziehen. Das „Goal QuestionMetric“-Modell, das hier vorgestellt wurde, kann dabei helfen, die richtigen Kennzahlen auszuwählen. Wir bekräftigen alle, die täglich mit Scrum zu tun haben, Kennzahlen für Scrum-Prozesse zu verwenden. Schlussendlich sprechen die Zahlen.

Figure 13, the known defects in the Backlog

Figure 14, the Fault Severity changes in composition over time

Page 11: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

Anhänge

Anhang A, Scrum-Kennzahlen für Zufriedenheit

Kennzahl Teammitglieder-Zufriedenheit

Parameter Zufriedenheit der Scrum-Teammitglieder

EinheitZufriedenheit wird normalerweise linear von 1 bis 5 gemessen, wobei 1 = sehr unzufrieden und 5 = sehr zufrieden bedeutet

Kennzahl Net Promoter Score (NPS)

Parameter Wahrscheinlichkeit, anderen empfohlen zu werden

Einheit NPS wird auf einer 10-Punkte Skala gemessen

Anhang B, Scrum-Kennzahlen für Reife

Kennzahl Anteil erfolgreicher Sprints

Parameter Ausmaß, mit dem das Team die Zusagen einhält

EinheitProzentsatz: Anzahl erfolgreicher Sprints geteilt durch Gesamtzahl der Sprints

Kennzahl Focus Factor

Parameter Anteil der Teamarbeit, der zu fertiggestellten „Stories“ führt

Einheit Prozentsatz: Geschwindigkeit geteilt durch Teamkapazität

Kennzahl Schätzgenauigkeit

Parameter Die Fähigkeit des Teams, Aufwand genau zu schätzen

EinheitProzentsatz: geschätzter Aufwand geteilt durch tatsächlicher Aufwand

Kennzahl Zuverlässigkeit

ParameterFähigkeit eines Teams, die zugesagten Story Points eines Sprints einzuhalten

EinheitProzentsatz: zugesagte Story Points geteilt durch verdiente Story Points

Page 12: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

Anhang C, Scrum-Kennzahlen für Abgestimmtheit

Kennzahl Relativer Return On Investment

ParameterWert fertiggestellter Arbeit verglichen mit Investitionskosten, hier die Story Points

Einheit Ein Betrag an Value Points je Story Point

Kennzahl Total Business Value Earned

Parameter Summe des Business Value im Laufe eines Sprints

Einheit Anzahl an Value Points

Kennzahl „End-to-end“-Kennzahl

Parameter Aufwand für bestimmte Komponenten des Softwareprodukts

Einheit Anzahl an Value Points

Anhang D, Scrum-Kennzahlen für Menge

Kennzahl Geschwindigkeit

ParameterRelative Messung der fertiggestellten Arbeitsmenge während eines Sprints

Einheit Story Points

Kennzahl Prozesseffizienz

Parameter Effizienz des Aufwands in bezug auf zugesagte Stories

EinheitProzentsatz: tatsächlicher Aufwand geteilt durch zur Verfügung stehende Zeit

Kennzahl Sprint Burndown

Parameter Verbleibende Arbeit verglichen mit Ideallinie

EinheitStory Points (oder Stunden). Die verbleibende Zahl an Story Points wird täglich aktualisiert

Kennzahl Release Burnup

Parameter Verbleibende Arbeit für den Release verglichen mit Ideallinie

EinheitStory Points (oder Stunden). Release Burnup wird am Ende jeden Sprints aktualisiert

Page 13: Agile Metrics - Prowareness Gmbh€¦ · Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team

Anhang E, Scrum-Kennzahlen für Qualität

Kennzahl Fehleranzahl

Parameter Anzahl der Fehler in der Software

Einheit Bekannte Fehler im Backlog

Kennzahl Fehlergewichtigkeit

Parameter Messung der Schwere behobener Fehler

EinheitMängel werden in drei Kategorien eingeteilt: kleine Mängel, große Mängel und kritische Mängel. Das Scrum-Team nimmt diese Einteilung selbst vor