Wir limitieren unseren “Work in Progress”, um jederzeit den Fokus zu behalten.
Wo ist die Herausforderung?
Tickets zu groß
Tickets erst am ende des Sprintes im Pullrequest / Test
Verursacht häufigen Themenwechsel am Tag am Ende des Sprintes
Inkrementelles Arbeiten
Bestehende Unterbrechungen nutzen, um den Pipelinestau abzuarbeiten
Von Daily zu Daily Fokus setzen
Deploybares ausliefern
Kleine Änderungen und schnelles Feedback
Wie gehen wir dann mit Pullrequest um?
Brauchen wir diese dann noch?
Jetzt schon vorhandene Regeln
Test und PR Spalte abarbeiten, bevor neues Ticket genommen wird
Weiterhin offen
Teamvision
Pipelinegeschwindigkeit erhöht
Am Ende des Sprintes ist klar was geschafft wurden ist
Sprint-Übergang mit halbfertigen Tickets leichter
Tagesarbeit kann mit Bulletpoints im Ticket dokumentiert werden
einzelne Unteraufgaben nicht unbedingt nötig
Verhindert lange Sackgassen, bei ratlosigkeit
Entwickler haben Zeit für Feedback und Support
Zielsetzung und Zielerreichung im Daily benennen
Fortschritt ersichtlich
Entspricht der Daily-Meeting-Agenda
"Ich bin gerade bei XYZ" reicht nicht aus
Daily-Agenda
• Was habe ich gestern / am letzten Arbeitstag getan, um das Sprint-Ziel zu erreichen?
• Was werde ich heute tun, um das Sprint-Ziel zu erreichen?
• Habe ich ein Impediment gefunden, dass mich oder das Team bei der Erreichung des Sprint-Ziels behindert?
Pairprogramming kann situativ nach Bedarf eingesetzt werden
Reduzierung Pairprogramming auf das Wesentliche
Minimierung Fehlerrisiko
Unterbrechungen keine Störung
Arbeitsfortschritt stets abgeschlossen
Team-Flexibilität erhöht
Prio von rechts nach links und von oben nach unten
Größere Themen über mehrere Sprints von denselben Kollegen abarbeiten lassen
Zu viele Projekte und Themen
weniger Wechsel im Sprint
Urlaub sollte nicht der einzige Grund für die Sprintzuordnung sein