Die Situation des Projekts besteht aktuell in einer Zweiteilung der Ressourcen. Einerseits das Tagesgeschäft mit dem „alten“ Code und andererseits die Neuentwicklung und Konsolidierung des Codes.
Nach den ersten Sprints fiel auf, dass teilweise erhebliche Zeit im Tagesgeschäft aufgewendet werden muss.
Dies brachte die Sprint-Planung trotz eingearbeiteter Puffer hierfür in Schieflage.

Als Reaktion auf diesen Umstand werden die Tagesgeschäfts-Punkte nun wie alle anderen in die Sprint-Planung, teils grob geschätzt, mit einbezogen.
Das hat teilweise dazu geführt, dass sichtbar wurde, dass die Neuentwicklung gestoppt werden muss, um Tagesgeschäft und „Liegengebliebenes“ zu bearbeiten.

Ein weiterer wichtiger Punkt sind die Not-Einsätze. Auch diese besitzen zum Teil erheblichen Impakt, da sie sich meist auf den „alten“ Code beziehen.
Da kann schon mal ein Kollege für den halben Sprint verschwinden. Diese Not-Einsätze werden nun mit roten Kärtchen am Scrum-Board gekennzeichnet und machen so Vorhandensein und den Umfang ein Stück weit sichtbar.

Meine Auffassung ist, dass das Scrum-Board die Live-Situation der Projektarbeit visuell schnell erfassbar machen muss.
Sonst kann man darauf verzichten und sich nur mit Ticketsystemen wie z. B. JIRA beschäftigen, um die Arbeit zu organisieren und zu visualisieren.
Wenn man aber nun auch „Randständiges“ (was es nicht wirklich ist) wie Not-Einsätze oder „Mach-doch-mal-schnell“ auf die Tafel bringt, erhält man einen realistischen Überblick über das lebendige Projekt und den aktuellen Stand. Man kommt in den Raum, schaut auf das Board und erhält eine realistische Momentaufnahme. Man muss in erster Instanz nicht jemanden fragen oder im JIRA diverse Diagramme scrollen und Queries absetzen. Das spart Zeit und erhöht die Sicherheit, das Projekt im Griff zu haben. So gesehen ist das Scrum-Board ein sehr gutes Hilfsmittel für Planung und dem Erkennen der Notwendigkeit gegenzusteuern.

Das ist sicherlich nicht Scrum-only zu verstehen und kann nutzbringend auch in anderen Planungsformen angewandt werden. Aber im Zusammenhang des lebendigen Scrum-Boards mit den engen Rückmeldezyklen Daily-Scrum und kurzen Sprints (bei uns 2 Wochen) ist meiner Meinung nach ein sehr gutes Controlling und Steuern von Projekten möglich.