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