Häufige Fragen zu Scrum:

Gibt es 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“ für Scrum haben sich bewährt:

  • eine klare gemeinsame Vision und Goal 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 mit geschätzten BPI's (Akzeptanzkriterien bei den PBI's können helfen)
  • 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 fokussieren (Items im Sprint Backlog zahlen auf das Sprint Goal ein)
  • während des Sprints bleibt das Sprint Backlog stabil
  • das Scrum-Pattern "Interrupt Buffer" wird eingeplant
  • Team schätzt Größe der Backlog Items (User Stories) gemeinsam
  • relative anstatt absoluter Schätzungen (Story Points anstatt Zeit)
  • Wir verwenden das Scrum-Pattern "Yesterdays Weather"
  • 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 und liefern uns neue Erkenntnisse
  • die "Definition of Done" wird gepflegt und ggf. erweitert (Technische Schulden sind zu vermeiden)
  • in Sprint Reviews werden Stakeholder eingeladen
  • Sprint Retrospektiven optimieren den Prozess (Kaizen Item)
  • projektbezogene Burndown-Charts und Metriken helfen
Siehe hierzu auch: WARUM BRAUCHEN WIR SCRUM PATTERNS?
 

Product Backlog Refinement (Grooming)

Während des Sprints nimmt sich das Development-Team Zeit für neue Anforderungen. Der Product Owner bespricht mit dem Development-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 Product Backlog Refinement zeigt dem Product Owner, wo er noch Informationen einholen muss und es verbessert die Qualität der Plannings.
Der Scrum Guide sieht 10% der Development-Teamkapazität für das Refinement vor. Im Gegensatz zu den anderen Events mit 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. Detailiertere Informationen zum Product Backlog Refinement.

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.