Wie geht ein Scrum-Team mit dringlichen Aufgaben um, die auf der Bildfläche erscheinen, während der aktuelle Sprint bereits läuft? Eine Lösung ist die Etablierung einer Inbox am Board: An dieser neutralen Stelle kann der ProductOwner den ungeplanten Vorgang ablegen, ohne ihn zu priorisieren, und ihn so direkt ins Daily Standup und damit in den Scrum-Prozess integrieren.
"Störer" im Sprint: Konfliktpotenzial und Gefahr für das Sprint-Ziel
Ein ganz normaler Morgen im Leben eines Scrum-Teams. Während des Standup-Meetings entdeckt das Team drei neue Ad-hoc-Aufgaben in der Fast Lane am Board, der Überholspur für die Blocker-Tasks. Die Reaktion:
"Och nö. Muss das sein? Wir waren gerade auf einem guten Weg, das Sprint-Ziel zu erreichen!"
Ein typischer Fall in vielen Software-Entwicklungsteams: Statt an den geplanten Aufgaben zu arbeiten, beschäftigt man sich gewollt oder ungewollt mit sogenannten Störern, ungeplanten Aufgaben, die vermeintlich wichtiger – oder eher nur dringlicher – als die vorgesehenen Arbeiten sind. Und das ist natürlich insbesondere dann deprimierend, wenn das Team sich gerade im "Flow" befindet und im eigentlichen Projekt gute Fortschritte erzielt.
Es muss also vor allem im Sinne des ScrumMasters sein, diese Störungen tunlichst zu vermeiden. Denn entgegen der Laienmeinung, ad-hoc sei doch agil, weiß der ScrumMaster sehr wohl, dass solche Störer das geplante Sprint-Ziel in Gefahr bringen können.
Der ProductOwner hingegen befindet sich in einem Interessenkonflikt: Er steht zwischen dem Kunden mit seiner vermeintlich dringenden Anfrage und dem Team, das vorankommen will, und zwar wie ursprünglich gemeinsam geplant. Geht eine solche Kundenanfrage ein, hat er das Anliegen, sie dem Entwicklungsteam ans Board zu hängen. Sein Gedankengang dabei:
"Der Kunde sagt doch, dass es dringend ist. Also kommt die Aufgabe am Board zunächst ganz oben in die Fast Lane mit den höchstpriorisierten Vorgängen, dort fällt sie wenigstens auf. Das Team kann sie bei Bedarf ja immer noch runterpriorisieren."
Was nun passiert, könnte wie folgt aussehen:
- Szenario 1: Das Team stellt die Priorisierung in der Fast Lane gar nicht in Frage, lässt alles stehen und liegen und arbeitet an der Erledigung dieser Störer. Das eigentliche Sprint-Ziel gerät dadurch natürlich ins Wanken.
- Szenario 2: Statt die Aufgaben sofort unkommentiert anzugehen, fühlt das Team sich vom ProductOwner nicht verstanden oder sogar auf den Schlips getreten: "Wieso hängst du das in die Fast Lane? Diese Sache ist doch schon lange bekannt und eigentlich überhaupt nicht dringend. Und dafür wollen wir den Sprint definitiv nicht gefährden."
Die Inbox und ihre Integration ins Daily Standup
Um solche oder ähnliche Konflikte von vornherein zu vermeiden, dem ProductOwner aber die Möglichkeit zu geben, seine Aufgabe auf dem Taskboard loszuwerden, verwenden unsere Teams einen neutralen Ablageort: Hier kann der ProductOwner die neuen, ungeplanten Aufgaben platzieren, ohne vorab eine Priorisierung vorzugeben. Diesen Ort nennen wir Inbox.
So wird diese Inbox in das Standup-Meeting integriert:
- Nachdem alle Teammitglieder die Frage "Was habe ich gestern gemacht?" beantwortet haben, werfen sie gemeinsam einen Blick auf die Inbox.
- Hängen dort Aufgaben, werden sie kurz besprochen bzw. vom ProductOwner vorgestellt.
- Hat das Entwicklerteam sie verstanden, nimmt es gemeinsam mit dem ProductOwner eine Priorisierung vor.
- Entsprechend der Priorisierung wird der Vorgang dann an seinen "richtigen" Platz auf dem Board gehängt.
- Die Inbox ist nach dem Daily Scrum stets leer.
Welche Möglichkeiten der Priorisierung hat das Team aus Entwicklern und dem ProductOwner dabei? In absteigender Rangfolge sind folgende Optionen zu nennen, die das Entwicklungsteam gemeinsam mit dem ProductOwner diskutieren sollte:
- Fast Lane: Das Team unterbricht alles andere und fängt sofort an. Die Aufgabe ist so dringlich, dass sie wichtiger als das Erreichen des Sprint-Ziels einzuordnen ist. Im Zweifel muss der Sprint abgebrochen werden.
- Änderung des Sprint-Umfangs: Ist es ein sehr wichtiges Ticket, das definitiv Bestandteil des Sprints sein muss, kann das Team es beschätzen und wenn möglich in Absprache mit dem ProductOwner eine ähnlich große Story, die noch nicht begonnen wurde, aus dem Sprint entfernen und dafür die neue aufnehmen.
- Aufnahme in die Task Lane: Wenn möglich, soll die Aufgabe noch in diesem Sprint erledigt werden, aber das Sprint-Ziel hat Vorrang.
- Aufnahme in das Product Backlog: Es handelt sich gar nicht um einen schwerwiegenden Fehler, sondern vielmehr um ein Feature, das ganz normal eingeplant werden kann.
Fazit
Eine Inbox auf einem Taskboard hat zwei wesentliche Vorteile: Mit ihr hat man einen Ort, um neue Aufgaben abzulegen und im Standup zu besprechen und dann auch gemeinsam zu einer Einschätzung der Wichtigkeit oder Dringlichkeit zu kommen. So bildet sie eine clevere Möglichkeit, Konflikte zu vermeiden und auch ungeplante Vorgänge schnell in den Scrum-Prozess zu integrieren.
“Agile” einführen oder optimieren? Wir sind Ihr Partner!
Haben Sie Fragen zu agilen Vorgehensweisen in der Organisation und der Software-Entwicklung? Möchten Sie Agilität in Ihrem Unternehmen einführen oder bestehende Prozesse verbessern? Bei //SEIBERT/MEDIA ist “Agile” in Projekten an der Tagesordnung. Gerne helfen wir Ihnen bei der Etablierung und Optimierung agiler Prinzipien und Verfahren in Ihrem Unternehmen – sprechen Sie uns einfach unverbindlich an. Ausführliche Informationen zu unseren Agile-Dienstleistungen finden Sie in unserem Agile-Orientierungsangebot mit Leistungsbeschreibungen und Beispielkalkulationen.
Weiterführende Informationen
Welche Vorteile bietet mir als Kunde ein Scrum-Projekt?
Agile vs. Wasserfall-Modell: Was die Forschung sagt
Praxistipps für Entwickler beim Einsatz von Scrum
Agile-Studie: Modelle, Methoden, Tools, Erfolge und Probleme in der Praxis der agilen Software-Entwicklung
Scrum in der Praxis: Ein Team startet durch
Mehr über die Creative-Commons-Lizenz erfahren
