Checklisten für Scrum-Master

Checkliste eines Scrum-Masters - Titelbild

Ein Scrum-Master hat viel zu tun, um für einen reibungslosen Ablauf der Sprints zu sorgen und alle Mitglieder des Scrum Teams so zu betreuen, dass sie ihre Verantwortlichkeiten kennen und wissen, wie sie diese gewissenhaft wahrnehmen können.

Um dem Scrum-Master seine Arbeit zu erleichtern, stellen wir Checklisten zur Verfügung, anhand derer er ermitteln kann, was bereits gut läuft und woran sein Scrum-Team noch arbeiten sollte.

Vollzeit-Master?

Ein Scrum-Master kann unter gewissen Bedingungen nicht nur ein, sondern auch mehrere (max. 3) Teams parallel betreuen.

Das bedeutet jedoch, sich in der Rolle des Scrum-Masters damit zu begnügen

  • Meetings zu organisieren
  • die Einhaltung der Zeitrahmen (Timeboxes) zu überwachen
  • auf Hindernisse zu reagieren, die vom Team explizit aus Eigeninitiative heraus gemeldet werden, anstatt sie selbst zu identifizieren und proaktiv tätig zu werden.

Wenn das Team gut ist und eingespielt in den bisherigen Abläufen der Organisation, so kann das insofern zum Erfolg führen, als die nicht allzu hohen Erwartungen der Organisation aus der Zeit vor der Einführung von Scrum erfüllt werden können und das Projekt im Hinblick auf seine Produktivität wie zuvor bereits gewohnt läuft.

Wenn der Einsatz von Scrum jedoch signifikante Verbesserungen bringen soll, so muss ein Scrum-Master sich voll und ganz auf ein einzelnes Team konzentrieren und es mit allen Kräften unterstützen. Das gilt besonders, wenn die Organisation gerade erst damit beginnt, Scrum einzusetzen.

Wer als Scrum-Master auch bei der Betreuung mehrerer Scrum-Teams sicherstellen will, dass Arbeiten im erforderlichen Maße erledigt werden und agiles Denken und Handeln Einzug hält, der kann die folgenden Checklisten zu Rate ziehen und mit ihrer Hilfe leichter und schneller den Stand der Dinge ermitteln und Verbesserungen einleiten.

Nutzung der Checklisten

In den folgenden Checklisten vermerkt der Scrum-Master bei der Bestandsaufnahme, wie es in einem Scrum-Team und in der Organisation aussieht im Hinblick auf die Umsetzung agiler Prinzipien mit Scrum.

Dafür geht er die Punkte der Checklisten (in der Spalte „Beschreibung“) durch und verwendet in der Spalte „Aktueller Stand“ die Markierung G (Gut – hier muss momentan nichts getan werden), T (Todo – hier besteht Handlungsbedarf und ich weiß auch schon was wir machen können), ? (Todo – hier besteht Handlungsbedarf, aber ich habe noch keine klare Vorstellung davon, wie wir es machen können) und I (Ignorieren – Hier könnten wir zwar etwas machen, doch die Vorteile durch Veränderungen in diesem Punkt sind zu gering, so dass wir unsere Energie zunächst auf andere Dinge konzentrieren). Je nach Tool und Vorlieben kann der Scrum-Master auch den bekannten Ampel-Farbcode benutzen: G wird grün hinterlegt, T und ? werden rot hinterlegt und I wird orange oder gelb hinterlegt.

In der Spalte „Kommentar“ kann der Scrum-Master notieren, welche konkreten Verbesserungen er anstrebt und wie er diese erreichen will.

Was macht der Product Owner?

Die wichtigste Unterstützungsleistung des Scrum-Masters für den Product Owner ist es, Wege aufzuzeigen, wie der Product-Owner das Product-Backlog und den Release-Plan pflegen  und aktuell halten kann.

Das ist für den Projekterfolg eminent wichtig, denn nur der Product-Owner darf das Product-Backlog priorisieren.

Checkliste des Scrum-Masters für den Product-Owner

Die folgende Checkliste dient zur Ideenfindung, in welchen Bereichen der Scrum-Master den Product-Owner noch unterstützen sollte.

Beschreibung Aktueller Stand Kommentar
Hat der Product-Owner das Product-Backlog anhand seiner aktuellsten Erkenntnisse und Anforderungen priorisiert?
Sind die Anforderungen und Wünsche aller Stakeholder im Product-Backlog erfasst worden?
Hat das Product-Backlog eine angemessene Größe und kann es gut verwaltet werden?Dafür ist es wichtig, dass nicht zu früh für zu viele Product-Backlog-Items eine detaillierte Analyse durchgeführt wird. Die Anforderungen werden sich im Zeitverlauf noch ändern und es reicht aus, wenn die höher priorisierten Product-Backlog-Items detailliert betrachtet wurden.
Sind die Anforderungen klar formuliert oder besteht bei den hoch priorisierten Product-Backlog-Items noch Handlungsbedarf im Hinblick auf ihre INVEST-Eigenschaften?(INVEST=Independent, Negotiable, Valuable, Estimable, Small, Testable)
Ist dem Product-Owner das Prinzip der sog. „technischen Schuld“ bewusst und weiß er, wie er sie vermeiden kann? Wenn das Entwicklungsteam dies nicht bereits von sich aus macht, so könnte der Product-Owner z.B. die Erstellung automatisierter Unittests und die Durchführung von Refactoring als Akzeptanzkriterium in jedes Product-Backlog-Item aufnehmen.
Erfüllt das Product-Backlog seine Funktion der Informationsverteilung und ist zu jedem Zeitpunkt im aktuellen Stand auf einfache Weise allen Stakeholdern zugänglich?
Wenn anstelle manueller Verfahren ein Tool zum Einsatz kommt für das Product Backlog:Weiß jedes Mitglied des Scum-Teams und jeder Stakeholder, wie er damit umgeht? Ist jeder bereit und in der Lage, sich regelmäßig den aktuellen Stand des Projekts mit Hilfe dieses Tools anzusehen?
Falls die Akzeptanz des Tools nicht bei allen Stakeholdern gegeben ist: Was kann der Scrum-Master tun, um alle Stakeholder mit den erforderlichen Informationen zu versorgen?Z.B. durch Ausdrucke, Exporte in gängigen Formaten etc.
Wenn sich nicht jeder ins Reporting mit generierten Charts einarbeiten kann oder will:Welche Charts sollen zu welchen Zeitpunkten erstellt und über welche Kanäle verfügbar gemacht werden?
Weiß der Product-Owner, wie er die Product-Backlog-Items zusammenstellt für Releases oder nach Prioritäten zu Gruppen?

 Wie läuft’s mit dem Entwicklungsteam?

Der Scrum-Master kann das Entwicklungsteam auch informell führen und inspirieren, indem er mit Teammitgliedern zusammen an ihren Aufgaben arbeitet. Das sollte jedoch die Ausnahme sein, denn das Entwicklungsteam sollte in sich cross-funktional sein und alle Fähigkeiten besitzen, die für die Erstellung eines Produktinkrementes erforderlich sind.

Der Scrum-Master sollte sich nicht in technischen Details verzettelt und seine wichtigsten Aufgaben in Bezug auf das Entwicklungsteam im Auge behalten.

In Sondersituationen mag eine Mitarbeit sinnvoll sein zu Beginn. Z.B. wenn der Scrum-Master aus einem bereits bestehenden Team stammt und noch wichtige Funktionen in der Entwicklung hat. Ziel sollte jedoch sein, das Wissen auf die anderen Mitglieder des Entwicklungsteams zu verteilen und sich sobald wie möglich voll auf die Rolle als Scrum-Master zu konzentrieren.

Checkliste des Scrum-Masters für das Entwicklungsteam

Die folgende Checkliste dient zur Ideenfindung, in welchen Bereichen der Scrum-Master das Entwicklungsteam noch unterstützen sollte.

Beschreibung Aktueller Stand Kommentar
Ist das Entwicklungsteam im Flow?Erkennbar ist Flow daran, dass die Selbstwahrnehmung verloren geht und die Wahrnehmung sich vorrangig auf die gerade durchgeführte Aktion richtet.In den Flow gelangen zu können setzt voraus:Die Ziele sind klar und erreichbar.Es herrscht weder Unterforderung noch Überforderung.Konzentrierte Fokussierung auf einen eingegrenzten Themenbereich ist möglich.Es gibt direktes unmittelbares Feedback für einen Erfolg oder die Notwendigkeit zur Verbesserung.Die Teammitglieder haben das Gefühl der persönlichen Kontrolle über das, was geschieht.

Aktivitäten sind intrinsisch motivierend, woraus eine gewisse Mühelosigkeit resultiert.

Verstehen sich die Teammitglieder gut und genießen die gemeinsame Arbeit und die gemeinsam errungenen Erfolge?
Feuern sich die Teammitglieder gegenseitig an, hohe Produktivitäts- und Qualitätsstandards zu erreichen und unterstützen sich dabei gegenseitig?
Gibt es Themen, die das Team nur ungern bespricht? Was sind die Ursachen?
Welche Formate und Veranstaltungsorte haben sich als besonders gut erwiesen für die Sprint Retrospektive? Was könnte alternativ ausprobiert werden?
Hat das Entwicklungsteam den Fokus behalten auf die Sprintziele?Falls nicht: Könnte ein kurzes Checkup-Meeting helfen, in dem die Akzeptanzkriterien für die für den Sprint ausgewählten Product Backlog Items durchgegangen werden?
Spiegelt das Taskboard wider, woran das Entwicklungsteam momentan arbeitet? Man achte auf nicht notierte Tasks und auf Tasks, die länger als einen Tag dauern.Sofern an Tasks gearbeitet wird, die nichts zur Erfüllung der Sprintziele beitragen, so ist das als Hindernis einzustufen.
Besteht das Entwicklungsteam aus ausreichend vielen Teammitgliedern, damit alle erforderlichen Skills für die Erstellung des Produktinkrementes vorhanden sind?
Ist das Taskboard aktuell?
Sind alle erforderlichen Artefakte (Taskboard, Sprint-Burndown-Chart, Liste der Hindernisse etc.) für das Team sichtbar und einfach zu benutzen?
Sind die Artefakte geschützt gegenüber Außenstehenden, die nicht zu den Stakeholdern zählen?Wenn Außenstehende sich zu oft und/oder kritisch einmischen, kann das die Transparenz und damit die Fähigkeit des Entwicklungsteams zum Selbstmanagement beeinträchtigen.
Übernehmen Teammitglieder freiwillig Tasks zur Bearbeitung?
Spiegelt sich der Bedarf zur Beseitigung technischer Schuld in den Product-Backlog-Items wider, so dass der Code immer besser wird und die Arbeit daran immer mehr Spaß macht?
Haben die Teammitglieder akzeptiert, dass sie keine formalen Rangabzeichen mehr tragen während der Arbeit mit Team? D.h. dass sie kein Datenbankadministrator, Tester, technischer Redakteur etc. mehr sind, sondern alle gemeinsam für die Ergebnisse des Entwicklungsteams verantwortlich.

 Wie gut sind wir im Software Engineering?

Es gibt viele Best-Practices für sauberes Software Engineering im Allgemeinen und für agile Projekte im Besonderen.

Typischerweise laufen Projekte erheblich besser, wenn diese Praktiken bekannt sind und aktiv gelebt werden.

Mithin ist es eine gute Idee des Scrum-Masters, zu ermitteln, wie es darum bestellt ist. Und eventuelle Lücken zu schließen, indem er entweder selbst das entsprechende Knowhow vermittelt oder für Trainingseinheiten durch andere Personen sorgt.

Checkliste des Scrum-Masters für Best Practices des Software Engineering

Die folgende Checkliste dient zur Ideenfindung, in welchen Bereichen das Software Engineering noch verbessert werden kann.

Beschreibung Aktueller Stand Kommentar
Können wir jederzeit auf einfache Weise („auf Knopfdruck“) feststellen, ob durch die Entwicklung ein Regressionsfehler verursacht worden ist? D.h. können wir zügig und zuverlässig ermitteln, ob zuvor bereits lauffähige Funktionalität immer noch geht?Das erreicht man durch einen automatisierten skriptgesteuerten Standbau (Checkout aus dem Repository, Compilierung, Deployment auf einen Testserver) und die maschinelle Ausführung von Tests mit einer hohen Testabdeckung.Dabei werden für konkrete Tests häufig die xUnit-Frameworks eingesetzt (z.B. JUnit für Java, NUnit für .NET).
Besteht ein ausgewogener Mix aus maschinellen Ende-zu-Ende-Systemtests (Funktionstests, Integrationstests) und maschinellen Unittests?
Schreibt das Team sowohl die Systemtests als auch die Unittests in derselben Sprache, mit der auch das System entwickelt wird?Die Zusammenarbeit und Flexibilität des Teams ist erheblich höher, wenn keine speziellen Skriptsprachen und GUI-Playback-Tools eingesetzt werden. Denn diese führen häufig zu einer Spezialisierung im Team.
Haben wir einen CIS (Continuous Integration Server) im Einsatz, der einen Alarm auslöst, sobald ein Regressionsfehler auftritt?Wie lange dauert es, bis dem Entwicklungsteam dieser Alarm gemeldet wird?
Gehen alle Testergebnisse in das Ergebnis des Continuous Integration Server ein?
Empfinden die Teammitglieder das permanente Design und Refactoring im Gegensatz zum großen allumfassenden Design am Beginn eines Projektes als angenehm?
Wie oft führen die Teammitglieder Refactoring durch?Idealerweise geschieht das mehrmals pro Tag oder sogar mehrmals pro Stunde.Ansonsten erschweren redundanter Code, schlechte Namensgebung für Variablen, enge Kopplung von Objekten oder Komponenten und vieles mehr die Weiterentwicklung.Refactoring ist mit vertretbarem Aufwand nur möglich mit automatisierten Unittests, die die Rückwärtskompatibilität von Änderungen sicherstellen.
Umfasst die „Definition of Done“ für jedes Product Backlog Item eine automatisierte vollständige Testabdeckung und die Durchführung von Refactoring?
Arbeiten die Teammitglieder via Pair Programming zusammen?Pair Programming erhöht die Wartbarkeit des Codes dramatisch und verringert gleichzeitig die Fehlerrate.Die reine Erstellung des Codes mag in einigen Fällen länger dauern. Über die gesamte Lebensdauer des Produktes hinweg gesehen ergibt sich jedoch eine erhebliche Ersparnis. Auch ohne detaillierte Statistiken zu betrachten kann man dies schon daran erkennen, dass in vielen IT-Abteilungen großer Unternehmen ein großer Teil des Budgets in die Wartung fließt.

 Wie ist unsere Organisation aufgestellt?

Agiles Vorgehen in Projekten steht in vielen klassisch organisierten Unternehmen im Widerspruch zu den Planungsabläufen und Karrierepfaden. Denn die Planung ist häufig so ausgelegt, dass man bereits zum Start des Projektes oder nach deren erster Phase genau wissen will, was das Produkt alles leisten und wie viel es kosten wird. Und Karrierepfade basieren häufig mehr auf individuellen Leistungen als auf den Ergebnissen ganzer Teams.

Das lässt sich auch nicht von heute auf morgen umkrempeln. Dennoch ist es die Aufgabe des Scrum-Masters, sich um daraus resultierende Hindernisse zu kümmern und für das Anstoßen von Anpassungsprozessen und das Change Management zu sorgen.

In großen Organisationen gibt es in der Regel eine Pilotphase, um neue Verfahren wie z.B. Scrum zu testen, bevor sie flächendecken eingesetzt werden. Nach erfolgreicher Pilotphase gibt es dann viele verschiedene Teams, die nach Scrum vorgehen. Dann wird es wichtig, die Kommunikation über Teamgrenzen hinweg zu fördern.

Checkliste des Scrum-Masters für die Organisation

Die folgende Checkliste dient zur Ideenfindung, was im Unternehmen organisatorisch noch verbessert werden kann.

Beschreibung Aktueller Stand Kommentar
Erfolgt eine ausreichende Kommunikation zwischen den Scrum-Teams, wenn es mehrere davon gibt?
Sind die Teams unabhängig voneinander in der Lage, ihre Features zu implementieren?Auch dann, wenn sie architekturelle Grenzen überschreiten?
Arbeiten die verschiedenen Scrum-Master gemeinsam daran, die organisatorischen Hindernisse zu beseitigen und führen eine gemeinsame Liste dieser Hindernisse?
Können die wichtigsten organisatorischen Hindernisse in Sichtweite des Leiters der Entwicklungsabteilung platziert werden?Am Besten mit Angaben dazu, was es kostet, wenn sie nicht beseitigt werden. Wie z.B. Produktivitätsverluste, längere Time-to-market, Qualitätsmängel, Zufriedenheit von Mitarbeitern und Kunden etc.
Sind die Bewertungsmaßstäbe für die Bewertung von Mitarbeitern darauf ausgelegt, den Teamgedanken zu fördern?Sind Anreize eliminiert, nur Architektur- oder Entwicklungsarbeiten durchzuführen, ohne sich um den Test und die Dokumentation der Ergebnisse zu kümmern?
Wie ist der Ruf des Unternehmens in den Medien, Jobportalen und sozialen Medien?Ist das Unternehmen bekannt dafür, ein tolles Arbeitsumfeld zu bieten, in dem es Spaß macht, an interessanten und vielseitigen Themen zu arbeiten?
Versteht das Unternehmen sich als lernende Organisation, die Fehler nicht gnadenlos abstraft, sondern als Gelegenheit zur Weiterentwicklung versteht?

Man beachte, dass organisatorische Veränderungen aufgrund der Vielzahl der beteiligten Personen nicht ganz einfach sind und Zeit erfordern. Sie sollten daher schrittweise erfolgen und durch die Unternehmens- oder Abteilungsleitung unterstützt werden.

Ken Schwaber sagte einmal recht treffend: „Ein toter Scrum-Master ist ein nutzloser Scrum-Master“. Damit spricht er das Risiko an, dass ein Scrum-Master auf gefährlichem Terrain wandelt. Auf der einen Seite muss er Hindernisse abbauen, zu denen auch organisatorische Hindernisse zählen. Auf der anderen Seite darf er aber auch nicht zu unbequem sein, denn sonst besteht die Gefahr, dass er seines Amtes enthoben wird. Und dann kann er auch nichts mehr ausrichten und hat seinen Auftrag verfehlt, für Verbesserungen der Arbeitsumgebung zu sorgen.

Allgemeine Ratschläge sind diesbezüglich schwer zu geben, weil vieles davon abhängt, welche Erfahrungen die Organisation bereit gemacht hat, wie innovativ sie ist, wie aufgeschlossen die beteiligten Personen sind etc.

Hier ist die soziale und kommunikative Kompetenz des Scrum-Masters gefragt, sich geschickt im Spannungsfeld zwischen zu viel und zu wenig Veränderung zu bewegen und die Beteiligten so einzubinden, dass Veränderungen im Konsens erfolgen.

Und was ist mit mir selbst?

Natürlich sollte der Scrum-Master nicht nur die anderen Mitglieder des Scrum Teams im Auge haben, sondern auch seine eigene Arbeit reflektieren.

Checkliste des Scrum-Masters für den Scrum-Master

Im Sinne der Überprüfung seiner eigenen Arbeitsweise und deren Verbesserung kann der Scrum-Master sich selbst von Zeit zu Zeit in einer ruhigen Minute Fragen stellen. Einige Fragen sind zwar als geschlossene Fragen formuliert. Sofern der Scrum-Master sie mit Nein beantwortet, stellt sich jedoch gleichzeitig die Frage nach dem „wie“. Denn dann sollte er als Kommentar gleich eintragen, wie er es zukünftig handhaben will, um besser zu werden.

Wenn in einer größeren Organisation mehrere Scrum-Master tätig sind, so ist es sehr hilfreich, einen anderen Scrum-Master um ein gemeinsames Brainstorming zu bitten. Denn wenn man über sein Projekt und seine eigene Arbeit mit Außenstehenden diskutierten kann, so werden einem Dinge leichter klar, bei denen ansonsten die Gefahr besteht, dass man sie übersehen könnte.

Beschreibung Aktueller Stand Kommentar
(Wie) Schirme ich das Team ab gegen Ablenkungen, Unterbrechungen und neue Anforderungen während des Sprints?
(Wie) Erkenne und beseitige ich Hindernisse (optimalerweise binnen 1-2 Tagen)?
Unterstütze ich bei der Produktivitätssteigerung des Entwicklungsteams?
(Wie) Stelle ich die Einhaltung der Prinzipien und Regeln von Scrum sicher?
(Wie) Sorge ich dafür, dass in den Meetings produktive Ergebnisse erzielt werden?
(Wie) Binde ich alle Teammitglieder ein?
(Wie) Sorge ich dafür, dass Workshops nicht länger dauern als wirklich notwendig?
Welche Meetings und Workshops moderiere ich selbst und für welche Meetings delegiere ich diese Aufgabe?
(Wie) Sorge ich für die Einhaltung des Timeboxing-Prinzips?
(Wie) Stelle ich sicher, dass die Scrum-Meetings stattfinden?
Im Sprint Planning Meeting 1:

  • Konzentriert sich das Entwicklungsteam auf das „Was“?
  • Nehmen alle Teammitglieder an dem Meeting teil?
  • Stellt das Entwicklungsteam dem Product-Owner Verständnisfragen, um die fachlichen Inhalte zu durchdringen?
  • Notiert das Entwicklungsteam die Antworten des Product-Owners auf einem Flipchart, Whiteboard oder anderen physischen Medien?
  • Werden alle Informationen lesbar und verständlich aufgeschrieben?
  • Findet das Entwicklungsteam für alle funktionalen Anforderungen Benutzerakzeptanztests?
  • Geht das Entwicklungsteam motiviert und engagiert aus dem Meeting?
Im Sprint-Planning-Meeting 2:

  • Welche Experten muss ich besorgen, um mein Team in ihrer Arbeit zu unterstützen?
  • Arbeitet das Team aktiv an den Lösungen für alle ausgewählten User-Storys und skizziert Architekturideen und denkbare Implementierungsvarianten?
  • (Wie) forciere ich lebhafte Diskussionen und den Austausch von Wissen und Ideen zwischen den Teammitgliedern?
  • Hat das Team am Ende des Meetings die Aufgaben so geschnitten, dass sie an einem Arbeitstag erledigt werden können?
Daily-Scrum-Meeting:

  • (Wie) Stelle ich sicher, dass alle Teammitglieder pünktlich zum Meeting erscheinen?
  • Jedes Teammitglied beantwortet von sich aus die 3 Scrum-Fragen des Daily-Scrum-Meetings und die Zusatzfrage nach Unterstützung:
    • Was habe ich seit dem letzten Daily-Scrum-Meeting getan?
    • Was werde ich bis zum nächsten Daily-Scrum-Meeting tun?
    • Was behindert mich in meiner Arbeit?
    • Wen kann ich heute unterstützen?
    • Aktualisiert das Team täglich die für die Burn-Down-Charts erforderlichen Daten?
    • (Wie) Erreiche ich, dass das Team die Daily-Scrum-Meetings auch ohne mich durchführt?
    • Passen die Aufgaben, die das Team als „in Arbeit“ gekennzeichnet hat, zu dem, woran tatsächlich gearbeitet wird?
    • Ist für jedermann klar ersichtlich, wer an welchen Aufgaben arbeitet? Sowohl für das Entwicklungsteam selbst als auch für Außenstehende?
    • Berichtet das Team wirklich nicht an den Product-Owner oder an den Scrum-Master, sondern informiert sich im Rahmen seiner Selbstorganisation wechselseitig über den aktuellen Stand?
    • Ist klar erkennbar, wie lange eine Aufgabe bereits „in Arbeit“ ist?
    • (Wann) Frage ich, welche Aufgaben, an denen bereits länger als ein Tag gearbeitet worden ist, in kleinere Aufgaben zerlegt werden kann?
    • (Wie) Prüfe ich, dass das gesamte Team eine User-Story nach der anderen sequentiell abarbeitet und nicht mehrere parallel?
    • Sind erledigte Aufgaben wirklich abgeschlossen und nicht nur (z.B. wegen Zeitmangel) als erledigt deklariert worden?
    • Beseitige ich Hindernisse binnen 1-2 Tagen?
Sprint-Review-Meeting:

  • Wird nur potentiell einsetzbare Software präsentiert?
  • Sind Vertreter des Kunden oder der Anwender anwesend?
  • (Wie) Halte ich Anmerkungen und Wünsche des Kunden und der Anwender fest?
Sprint-Retrospektive-Meeting:

  • (Wie) Erzeuge ich eine vertrauliche Atmosphäre im Scrum-Team?
  • (Wie) Werden alle Hindernisse und Probleme klar und verständlich kommuniziert?
  • (Wie) Schaffe ich eine sichere Umgebung, in der sich das Team entspannt und locker fühlt?
Estimation-Meeting:

  • Versteht das Entwicklungsteam, dass wir die Aufwandsschätzung aus der fachlichen Sicht machen und nicht aus der technischen?

 Was bringt uns das alles?

Natürlich wollen wir wissen, was Scrum uns bringt.

Sowohl „uns“ im Sinne des Scrum-Teams als auch „uns“ im Sinne der Organisation und dessen Management.

Checkliste für den Erfolg

Die folgende Checkliste prüft, welche der Versprechungen von Scrum wir bereits eingelöst haben und welche Steigerungsmöglichkeiten es noch gibt.

Für die Beantwortung ist es wichtig, dass der Scrum-Master mit dem Product-Owner zusammenarbeitet.

Zudem sollte diese Checkliste frühzeitig bekannt gemacht werden. Damit der Stand des Teams und der Organisation sowohl vor als auch während und nach der Einführung von Scrum ermittelt werden kann und damit ausreichend Daten für einen Vergleich vorliegen.

Beschreibung Aktueller Stand Kommentar
Liefern wir jetzt frühzeitiger und öfter Releases aus?
Wie hat sich die Time-to-market verändert durch Scrum?
Liefern wir Funktionalität mit einem höheren geschäftlichen Nutzen aus als vorher?
Wie hat sich der ROI verändert durch Scrum?
Haben wir weniger Defects und können daraus auf eine höhere Qualität schließen?
Sind unsere Kunden zufriedener?
Haben wir eine messbare Entwicklungsgeschwindigkeit (Velocity) und sind auf ihrer Basis verlässliche Vorhersagen möglich?
Haben wir weniger Silos (deutlich abgegrenzte Funktionsbereiche) und Hand-Offs (Stopp der Entwicklung für Standbau, Test, Release) und vermeiden die damit zusammenhängende Verschwendung?
Haben wir mehr Spaß bei der Arbeit und arbeiten gerne mit anderen Teammitgliedern zusammen?
Welche Maßnahmen haben am meisten beigetragen zu einer besseren Teammoral?