Scrum Best Practices

Die Erfahrung aus vielen Scrum Projekten zeigt, dass es sich lohnt, die Spielregeln des Scrum-Frameworks unbedingt einzuhalten. Folgende „Good (Best) Practices“ haben sich bewährt:

  • eine klare gemeinsame Vision für das Produkt oder Projekt definieren
  • Menschen stehen im Mittelpunkt, nicht Technik
  • ideale Development Team Mitglieder sind "T-Shaped" sprich,  Generalistentum fördern
  • nie mehr als ein Projekt gleichzeitig bearbeiten!
  • ein aktueller Product Backlog
  • ein definierter Releaseplan
  • ein nach Geschäftswert priorisierter Product Backlog
  • Backlog Refinement (auch als Backlog Grooming bekannt) in jedem Sprint
  • Backlog Items sind "Ready" bevor diese in den Sprint übernommen werden. (eine "Definition of Ready" kann hier helfen)
  • klare Sprint Ziele vereinbaren um zu fokusieren
  • während des Sprints bleibt das Sprint Backlog stabil
  • Team schätzt Größe der Backlog Items (User Stories) gemeinsam
  • relative anstatt absoluter Schätzungen (Story Points anstatt Zeit)
  • täglicher „Daily Scrum“ als Meeting zur Synchronisation und ggf. Replanung in Hinblick auf das Sprint Ziel
  • während des Sprints arbeitet das Team ungestört
  • die ausgelieferten Produkt Inkremente (häufig Software) sind „done“
  • Sprint Reviews werten den Produktstand aus
  • die "Definition of Done" wird gepfelgt und ggf. erweitert (Technische Schulden sind zu vermeiden)
  • in Sprint Reviews möglichst Stakeholder einladen
  • Sprint Retrospektiven optimieren den Prozess
  • projektbezogene Burndown-Charts und Metriken helfen

Backlog Refinement (Grooming)

Während des Sprints nimmt sich das Team Zeit für neue Anforderungen. Der PO bespricht mit dem Team die nächsten und neuen Anforderungen. Das Product Backlog ist zu jeder sortiert. Die wichtigsten Anforderungen stehen immer oben. Ganz neue Anforderungen werden abgeschätzt.
Das Refinement zeigt dem PO, wo er noch Informationen einholen muss und es verbessert die Qualität der Plannings.
Der Scrum Guide sieht 10% der Teamkapazität für das Refinement vor. Im Gegensatz zu den anderen Timeboxen gibt es beim Refinement keine vorgegebene Timebox. Das liegt daran, dass dafür keine eigene Besprechung vorgesehen ist, an der alle Teammitglieder teilnehmen. Jedes Scrum Team kann natürlich für sich entscheiden einen Regeltermin mit Timebox für das Refinement zu definieren. Dies ist sicherlich auch eine gute Praxis.

Im Anschluß an das Refinement gibt es „Hausaufgaben“, die die Teammitglieder bearbeiten.

Relative Schätzungen

Relative Schätzungen des Umfangs von Aufgaben werden gemeinsam im Team entschieden. Dazu wird häufig der Planungspoker verwendet.
Da Scrum nur einen Rahmen aufzeigt, verbessert das Team den Prozess im Detail ständig, um die Produktivität zu steigern.

Scrum / Kanban Board

Das Scrum-Board ist ein Hilfsmitte (meist eine Tabelle mit 3 Spalten) für alle Anforderungen des Sprints und alle resultierenden Aufgaben (Tasks):

  • Schafft Transparenz
  • Ist gut sichtbar für alle Teammitglieder
  • Wird im Sprint Planning befüllt
  • Wird nach dem Sprint Review abgeräumt.
  • Empfehlung: Mit physischem Board starten

Für den Umgang mit dem Scrum-Board gelten folgende Empfehlungen:

  • Teammitglieder wählen selbst die Tasks aus. Die Arbeit wird nie zugewiesen
  • Verbleibende, geschätzte Arbeit wird täglich aktualisiert
  • Jedes Teammitglied kann das Sprint Backlog erweitern oder ändern
  • Die Tasks entstehen bei Bedarf zusätzlich im Sprint
  • Das Task-Board ist zentral für das Team zugänglich

Burndown Chart

Das Sprint Burndown Chart zeigt die verbleibende Zeit die notwendig ist, um die geplanten Tasks bzw. “Story Points” zu beenden. Es dient den Development Teams als visuelle Fortschrittskontrolle.
Das Sprint Burndown Chart wird täglich aktualisiert. Dazu wird immer gezählt, wie viele Tasks oder Story Points noch offen sind. Es wird nicht gemessen, wie viel Zeit oder Arbeit das Team schon verbraucht hat.

Reporting

In Scrum gibt es keine klassischen Statusberichte. Stattdessen sind alle Stakeholder eingeladen, sich im Teamraum anhand des Sprintbacklogs und des Burndown-Charts zu informieren.
Das Burndown-Chart gibt schon früh einen Hinweis, ob das Team sein Sprintziel erreicht.