Software-Engineering agile Pattern und agile Antipattern: Sprint-Antipattern (Teil 3)

Inhalt

Feature-Injection
Keine Remaining-Work/ Kein Burndown-Chart
Zu viele Meetings
Hardening Sprints
Das falsche Feature bekommen
Keinen Antrieb
Der Neue
Variable Sprintlänge
Variable Teilzeit Teammitglieder

1 Feature-Injection

Beschreibung des Anitpatterns:

Jemand fügt, ohne dies zuvor mit dem Team zu besprechen, ein neues Feature ins Sprintbacklog hinzu.
Der Sprintscope erhöht sich dadurch, ohne dass dies dem Umsetzungsteam bewusst ist.
Das Team findet diesen Umstand entweder heraus und wundert sich, warum ein zusätzliches PBI im Sprint verplant ist, oder es fällt nicht auf und das Team versucht den erhöhten Aufwand im Sprint zu stemmen.

Warum ist das schlecht?

Grundsätzlich ist das Umsetzungsteam für das Sprintbacklog verantwortlich, es darf somit niemand ein PBI zum Sprintboard hinzufügen, passiert dies doch, so wird dieses Recht stark untergraben und dies führt zu einem Vertrauensverlust des Teams.
Fällt dem Team nicht auf, dass zusätzliche PBIs im Sprint hinzugefügt wurden, so führt dies dazu, dass das Sprintziel potenziell nicht erreicht wird und das Team glaubt, es habe schlechte Arbeit geleistet und sich bei der Planung oder der Schätzung des Aufwands verkalkuliert.
Wird der Umstand des zusätzlichen Aufwands entdeckt, so kann es passieren, dass sich Team vor den Kopf gestoßen fühlt und ein Konflikt entstehen.
Oftmals wenn einzelne Teammitglieder PBIs in den Sprint hinein ziehen, missachten sie dabei, dass sie ggf. auch Teammitgliedern bei der Umsetzung anderer Tasks helfen können. Es kann sein, dass sich die Teamkollegen dann nicht unterstützt fühlen und Konflikte entstehen.

Verbesserungen:

Es kann sein, dass es demjenigen, der das PBI hinzugefügt hat, nicht bewusst ist, dass dies ein No-Go ist. Sollte dies so sein, so sollte der Scrum-Master diese Person in Scrum und den Umgang mit dem Sprintboard coachen.
Der Scope wird zwischen dem Umsetzungsteam und dem Product-Owner verhandelt, es darf also auch kein einzelnes Umsetzungsteam-Mitglied PBIs in den Sprint hineinziehen, ohne dies zuvor mit dem restlichen Team und dem Product-Owner abzuklären.
Zieht ein Teammitglied ein PBI in den Sprint, ohne dies zuvor mit den anderen Teammitgliedern und dem Product-Owner zu besprechen, so kann dies dazu führen, dass ggf. andere Aufgaben, die das Teammitglied ebenfalls erledigen könnte, nicht gemacht werden. Ein zusätzliches Hineinziehen von PBIs kann also auf eine Schwäche des Teams in der Selbstorganisation hindeuten. Somit sollte nie einfach eine zusätzliche Aufgabe ohne Besprechung mit den Kollegen in den Sprint hineingezogen werden, sondern viel mehr nach offenen Themen gesucht werden, die ursprünglich geplant waren.
Es können zum Beispiel qualitätssichernde Maßnahmen gemacht werden, getestet werden oder technische Schulden angegangen werden.
Der Scrum-Master sollte dies besonders genau beobachten und ggf. mit dem Team über Selbstorganisation sprechen.
Oft werden diese schnellen Features gegen Ende des Sprints von Teammitgliedern in den Sprint gezogen. Zu dieser Zeit sollten alle vor allem aber der Scrum-Master das Sprintboard und das Burndown-Chart im Auge behalten. Brennt die Remaining-Work nicht einheitlich runter, oder steigt sie kurzfristig sogar wieder an, so ist dies ein Zeichen, dass zusätzlicher Aufwand im Sprint aufgetaucht ist, also beispielsweise ein neues Feature in den Sprint gezogen wurde.
Will ein Stakeholder oder der Product-Owner ein zusätzliches Feature oder einen Bug in den Sprint schieben, so kann er dies nicht, ohne zuvor eine Absprache mit dem gesamten Umsetzungsteam durchzuführen. In diesem Fall muss das Team entscheiden, ob es noch zusätzliche Kapazitäten frei hat, weil beispielsweise einige PBIs vor der geplanten Zeit fertiggestellt wurden oder ob statt dem neuen Feature ein gleichhoch geschätztes anderes Feature aus dem Sprint genommen werden muss.
Wenn das neue Feature oder der Bug zu viel Kapazität im aktuellen Sprint einnehmen würde und dadurch essenzielle PBIs aus dem Sprint fallen würden und somit das Sprintziel stark verändert werden würde, so muss der Sprint abgebrochen und neu aufgesetzt werden. In diesem Fall steht es aber nur dem Product-Owner zu, den Sprint abzubrechen und gemeinsam mit dem Umsetzungsteam einen neuen Sprint zu planen.

2 Keine Remaining-Work/ Kein Burndown-Chart

Beschreibung des Antipatterns:

Das Team führt keine Remaining-Work-Aufzeichnung pro geplanten PBI und weiß somit nicht, wie lange es noch voraussichtlich dauern wird, bis das PBI fertig ist.
Dadurch weiß das Team auch insgesamt nicht, ob das Sprintziel realistischerweise erreicht werden kann oder nicht.
Das Team führt auch kein Burndown-Chart, weil als Ausgangsbasis für das Burndown die Schätzung der Aufwände und die Remaining-Work in allen geplanten PBIs gepflegt sein muss und dies nicht der Fall ist.

Warum ist das schlecht?

Wenn das Team die Remaining-Work nicht pflegt, kann niemand wissen, ob ein geplantes PBI in der Zeit liegt oder nicht. Wenn es über der geplanten Zeit ist, kann das bedeuten, dass andere geplante Features im Sprint nicht fertiggestellt werden können. Dies führt dazu, dass das Sprintziel gefährdet wird und gegebenenfalls nicht erreicht werden kann.
Das Team kann folglich nicht frühzeitig kommunizieren, dass das Sprintziel in Gefahr gerät. Schafft das Team dann Sprintziele nicht, kann schnell das Vertrauen in agile Methoden, Scrum und das Team infrage gestellt werden.
Durch das fehlende Monitoring der Remaining-Work und die fehlende Gesamtsumme an Remaining-Work, können Probleme, die bei der Umsetzung entstehen, von anderen nicht bemerkt werden. So können andere Antipattern wie beispielsweise die Fehlende-Unterstützung, Task-Assignment, oder Feature-Injection nicht vom Scrum-Team bemerkt werden.

Verbesserungen:

Das Team sollte beim Planning bereits die Remaining-Work aller Tickets schätzen und das Burndown-Chart einrichten.
Die Remaining-Work sollte möglichst oft angepasst werden, im Idealfall mehrmals täglich, mindestens aber wenn ein Ticket in eine andere Arbeitsphase übergeht oder fertiggestellt wurde.
Mindestens einmal täglich vor dem Stand-up sollte bei allen PBIs die Remaining-Work angepasst werden.
Im Idealfall wird ein Tool zur Verwaltung der Tickets und der Remaining-Work bzw. des Burndown-Charts verwendet. Wenn allerdings mit einem physischen Sprintboard gearbeitet wird, sollte das Team und der Scrum-Master die Zahlen und die Statistiken selbst täglich aktualisieren.
Wird die Remaining-Work getrackt und fallen Unregelmäßigkeiten oder Probleme auf, so sollte diese sofort mit dem restlichen Team samt Product-Owner und Scrum-Master besprochen werden und Gegenmaßnahmen ergriffen werden.

3 Zu viele Meetings

Beschreibung des Antipatterns:

Das Umsetzungsteam wird zu oft in Meetings eingebunden.
Oft werden technische Fragen von Stakeholdern oder Fragen zum Projekte mit Meetings geklärt. Das Team muss sich Zeit nehmen und bei den Meetings mit den Stakeholdern dabei sein.
Weiter wichtige Meetings können von Vertrieb, Marketing, dem Management, der IT oder anderen Abteilungen/Stakeholdern kommen.
Neben den Ablenkungen durch Stakeholder, benötigt auch der Product-Owner oft Meetings mit dem Team, um Anforderungen zu spezifizieren und Fragen zu klären.
Oftmals werden diese Meetings auch sehr spontan gemacht.
Die Meetings an sich sind oft nicht relevant. Fragen hätten auf anderen Kanälen gelöst werden können.

Warum ist das schlecht?

Wird das Team in zu viele Meetings eingebunden, bleibt nur mehr wenig Zeit für die Umsetzung
Werden Meetings und Unterbrechungen nicht geplant, sondern relativ spontan entschieden, werden die Teammitglieder aus der Arbeit gerissen. Geistige Rüstzeiten müssen erneut investiert werden. Es kommt zu Fehlern und Mehraufwänden.
Selbst wenn nur einige Teammitglieder in Meetings verstrickt sind, schadet dies den andern Kollegen, weil diese sich bei Fragen oder Abhängigkeiten nicht direkt an die Kollegen wenden können, die gerade im Meeting verhindert sind.

Verbesserungen:

Fragen von Stakeholdern und vom Product-Owner sollten vorab zusammengetragen und in gesammelter Form geklärt werden.
Wenn möglich, sollte der Product-Owner und der Scrum-Master das Team von direkten Zugriffen durch Stakeholder abschirmen und versuchen, die Anliegen der Stakeholder direkt zu klären.
Nur wenn es überhaupt nicht ohne einem Teammitglied möglich ist, sollte dieses in Frage-Meetings involviert werden.
Vertrieb, Marketing und IT sollten über die Zeit ein Verständnis für die Software aufbauen, dass diese möglichst selbstständig arbeiten können und nicht wegen Kleinigkeiten das Team stören müssen.
Fragen des Product-Owners zum Produkt sollte dieser Sammeln und in Refinement-Meetings oder individuell vereinbarten Meetings stellen.
Refinement-Meetings sollten immer zur selben Uhrzeit und am selben Tag oder an den zwei selben Wochentagen (je nach Projekt) stattfinden und wenn möglich nicht länger als eine halbe Stunde dauern.
Generell ist es empfehlenswert, rechtzeitig vorab eine Agenda zum Termin auszusenden und allen Beteiligten die Chance zu bieten, sich auf das Meeting vorzubereiten. Gegebenenfalls kann mit einer guten Meetingvorbereitung das Meeting verhindert oder stark verkürzt werden.

4 Hardening Sprints

Beschreibung des Antipatterns:

Meist werden Hardening-Sprints von Teams gemacht, die über längere Zeit mehr auf Output und Quantität als auf Qualität geschaut haben.
Oder das Team ist noch sehr unerfahren, besteht aus unerfahrenen Software-Engineers und legt kein Augenmerk auf Qualität.
Dadurch stagniert die Qualität des Produkts oft im Laufe der Zeit und Änderungen werden immer schwieriger und aufwendiger, bis zu jenem Punkt, an dem ein untragbares Ausmaß der Produktqualität und der Entwicklungsaufwände erreicht wird.
Das Team entscheidet dann, dass es keine neuen Features mehr einbauen kann, sondern einen Hardening Sprint braucht, um die technische Schuld die sich angestaut hat, auszubessern und das Produkt wieder zu stabilisieren/zu härten.

Warum ist das schlecht?

Der Hauptgrund, warum Hardening Sprints schlecht sind, ist, weil sie eine reine Symptombekämpfung sind.
Scrum setzt sich zum Ziel, dass jeder Sprint ein potenziell releasebares Produktinkrement erzeugt. Dazu sollte das Team gemeinsam mit dem Product-Owner und dem Engineering-Team die Definition of Done festschreiben. Und diese gemeinsam entschlossenen Regeln zur Qualität auch in jedem einzelnen Sprint und für jedes einzelne Feature einhalten.
Ein weiteres Gebot von Scrum ist es, bei jedem einzelnen Sprint neue Features oder ein verbessertes Produktinkrement umzusetzen. Und dabei ist nicht gemeint, technische Schulden zu beseitigen. Diese Regelung ist wichtig, um den Usern immer wieder mehr Mehrwert zu liefern und den Stakeholdern einen konstanten Fortschritt vorzeigen zu können. Das schafft Vertrauen ins Engineering-Team und in agile Praktiken.
Hardening Sprints sind üblicherweise auch ein starkes Alarmzeichen dafür, dass das Team agile Prinzipien und Scrum nicht richtig verstanden hat oder nicht richtig umsetzen kann.

Verbesserungen:

Zunächst muss das Team die Problematik dieses Antipattern verstehen. Dazu kann der Scrum-Master die negativen Konsequenzen dieses Verhaltens aufzeigen.
Es muss allen Teammitgliedern klar sein, dass Hardening Sprints Symptombekämpfung sind und nicht gegen die eigentliche Ursache der Probleme wirken.
Sollte das Team agile Methoden und Scrum nicht ganz verstanden haben, so muss der Scrum-Master durch Schulungen das Team in diesen Punkten auf neuesten stand bringen. Ein agiles Mindset muss vorherrschen, und das Team muss Sprint für Sprint für guten Outcome sorgen und darf nicht im Output getriebenen Denken verhaftet sein.
Falls es keine oder keine ausreichend gute Definition of Done gibt, so sollte sich das Team in einen Workshop Gedanken dazu machen und eine gemeinsame Definition of Done erstellen.
Liegt die Ursache der schlechten Qualität des Produkts in dem fehlenden Knowhow des Teams, oder einiger Teammitglieder, so kann es auch sinnvoll sein, diese auf Workshops zu schicken.
In jedem Fall macht es Sinn, dass erfahrenere Software-Engineers ihr Wissen an die unerfahreneren weitergeben. Dies ist am einfachsten durch Reviews, gemeinsame Architektur- und Design-Workshops und Pairprogramming möglich.
Auch Grundlagen für saubere Software-Engineering Prozesse, Clean Code und Code-Qualität sind notwendig. Testautomatisierung, Unit-Testing, Integrationstest und generell Testkonzepte sind notwendig, um Hardening-Sprints zu verhindern und eine gute Erweiterbarkeit und Qualität der Software zu gewährleisten.

5 Das falsche Feature bekommen

Beschreibung des Antipatterns:

Der Product-Owner glaubt, er bekommt ein Feature mit einer gewissen Funktionalität geliefert, das Team arbeitet jedoch an einem Feature mit einer teilweisen oder völlig anderen Funktionalität.
Erst sehr spät, zum Beispiel beim Review, wird dieses Missverständnis entdeckt.
Meist rührt das Problem darin, dass es das Scrum-Team nicht geschafft hat, ein einheitliches gemeinsames Verständnis für die Aufgabe zu entwickeln. Das Team redet zu wenig, oder gar nicht über die gewünschten PBIs und hat eine schlechte Kommunikationskultur.
Meist treten diese Probleme auch dann auf, wenn das Umsetzungsteam zu sehr im Lösungsraum verhaftet ist und sich nur auf die technische Lösung eines Problems konzentriert, aber eigentlich gar nicht genau weiß, was die User für Probleme haben und diese eigentlich brauchen.

Warum ist das schlecht?

Werden Features falsch umgesetzt, resultiert dies in einem erheblichen Kostenanstieg in der Entwicklung. Denn die Fehler müssen zurückgebaut und ausgebessert und die eigentlich gewünschte Funktionalität muss hergestellt werden. Somit fallen einerseits die Kosten für die falsche Implementierung an und dann noch die Kosten für die richtige Implementierung.

Verbesserungen:

Sollte das Problem aufgrund von schlecht geschriebenen oder unvollständigen Beschreibungen der PBIs bestehen, so muss der Product-Owner mehr Zeit und Leistung in die Beschreibung der Aufgaben legen. PBIs sollten immer mindesten eine User-Story aufweisen, die dem Leser der Story verständlich mach, was warum zu tun ist. Zusätzlich müssen PBIs immer Akzeptanz-Kriterien aufweisen, die genau beschreiben, was der Product-Owner bzw. der User am Ende genau in der Lösung braucht und wie Spezialfälle gehandhabt werden sollen.
Das Team sollte auf jeden Fall, falls noch nicht vorhanden Refinement-Meetings machen, bei denen das Team in regelmäßigen Abständen die vorhandenen Backlog-Items gemeinsam diskutiert und ein gemeinsames Verständnis herstellt.
Fehlt dem Software-Engineering-Team der Einblick oder das Verständnis für die Zieluser und deren Bedürfnisse, so sollte der Product-Owner dafür sorgen, dass gemeinsam mit dem Umsetzungsteam User-Tests gemacht werden. Dadurch kann das Team selbst beobachten und erfahren, wie die Software von den Zielusern verwendet wird und welche Bedürfnisse und Probleme diese haben.
In der nächsten Retrospektive sollte das Thema auf jeden Fall angesprochen werden und auch die gemeinsame Kommunikation kritisch beleuchtet werden.
Es kann beispielsweise auch oft helfen, frühzeitig Feedback vom Product-Owner einzuholen, wie etwas gemeint ist oder wie etwas umgesetzt werden soll.
Dazu ist es natürlich auch wichtig, dass der Product-Owner seinen Job ernst nimmt und sich genügend Zeit für seine Teamkollegen und seine Aufgaben nimmt.

6 Keinen Antrieb

Beschreibung des Antipatterns:

Das Team ist gefangen in einem ewigen Trott an Sprints, die nie fertig werden. Es werden pausenlos Tickets im Sprint angefangen, die nicht bis zum Ende des Sprints fertiggestellt werden können. Diese unfertigen Tickets werden dann auf den nächsten Sprint verschoben.
Auch die Produktinkremente werden in den meisten Sprints nicht fertig, sodass Product-Owner und User entweder schlechte oder gar keine Releases bekommen.

Warum ist das schlecht?

Liefert das Team die vereinbarten Sprintziele nicht ab und kann es keine sauberen Inkremente bereitstellen, so verlieren die Stakeholder und User sehr schnell das Vertrauen in das Team und das Produkt. Dies kann massive wirtschaftliche und soziale Folgen für das Team und das Unternehmen haben.
Durch die Nichteinhaltung der Sprintziele entsteht auch ein großer Konfliktpunkt zwischen Product-Owner und Umsetzungsteam. Die gemeinsame Arbeit und die Kommunikation miteinander kann leiden und Konflikte können entstehen.

Verbesserungen:

Oft gerät ein Scrum-Team in eine derartige Abwärtsspirale, wenn die Planung und das Schätzen der PBIs für den Sprint nicht richtig funktioniert oder das Team aus anderen Gründen keinen Antrieb mehr hat. Meist führt jedoch das Eine zum Anderen. Denn werden Sprintziele immer wieder nicht erreicht, so leidet auch die Moral im Team.
Gegen die Planung und schlechte Aufwandsschätzungen kann systematisch vorgegangen werden. Am Ende des Sprints sollte das Team genügen Puffer für das Testen und Stabilisieren des Produkts miteinplanen. Für die Grobschätzung sollte am besten gemeinsam und systematisch mit der Hilfe von Story-Points geschätzt werden. Mit der Hilfe von detaillierteren Stundenschätzungen kann die Feinplanung und Feinschätzung erfolgen.
Für die Moral und den Antrieb sollten zunächst die strukturellen Probleme beseitigt werden und dann durch offene Gespräche, Teambuilding und Anreizsysteme vom Management/Scrum-Master gegengesteuert werden.
Sollten sich bei der Analyse und Verbesserung der strukturellen Probleme des Scrum-Teams und des Scrum-Prozesses immer wieder herausstellen, dass es einige Punkte gibt, die nicht umzusetzen sind, kann dies ein Hinweis darauf sein, dass Scrum nicht die richtige Methode für dieses Team oder dieses Problem ist. Dann kann beispielsweise auf Kanban oder eine andere Vorgehensmethode umgestellt werden.

7 Der Neue

Beschreibung des Antipatterns:

Mitten im Sprint taucht ein neuer Kollege auf, der von nun an im Team mitarbeiten soll.
Der neue Kollege und die Aufwände zum Betreuen dieses neuen Kollegen sind aber nicht im Sprint eingeplant oder berücksichtigt.

Warum ist das schlecht?

Dieses Antipattern ist vor allem dann besonders schlecht, wenn das Team unter einem hohen Druck steht, beispielsweise wenn die Software schon live ist und es viele aktive User gibt und neue Features geplant und umgesetzt werden müssen.
Da die zusätzlichen Aufwände für die Betreuung und Einführung des neuen Kollegen nicht berücksichtigt wurden, führt dies zu einen noch höheren Druck auf das Umsetzungsteam. Dies kann einerseits dazu führen, dass sich der neue Kollege nicht wohl aufgenommen fühlt und schnell frustriert wird, und andererseits, dass das Team durch die zusätzliche Mehrbelastung unfreundlich und gestresst wirkt.
Im schlimmsten Fall kündigt der neue Kollege oder bittet um eine Versetzung in ein anderes Team, oder die Stakeholder werden enttäuscht, weil das Sprintziel nicht eingehalten wurde.

Verbesserungen:

Alle Beteiligten wollen den neuen Kollegen herzlich im Team aufnehmen, damit dies möglich ist, sollten die dazu benötigten Zeiten auch eingeplant werden.
Es ist Gang und Gebe, dass neue Teammitglieder während eines laufenden Sprints in das Team aufgenommen werden, jedoch müssen die dadurch entstehenden Mehraufwände in der Sprintplanung berücksichtigt werden und das Onboarding bereits im Vorfeld gut vorbereitet werden. So können für diese Vorbereitungsarbeiten bereits im vorhergehenden Sprint Aufwände entstehen.
Geraden in größeren Unternehmen weiß das Team oft nicht wirklich, wann neue Kollegen zum Team hinzugefügt wurden, dies lässt dann auf ein bestehendes organisatorisches Antipattern schließen.

8 Variable Sprintlänge

Beschreibung des Antipatterns:

Das Scrum-Team erkennt, dass es aufgrund von Verzögerungen den Sprint um einige Tage verlängern muss oder den Sprint aufgrund von schnelleren Umsetzungen verkürzen kann und ändert kurzerhand die Sprintlänge.
Anmerkung: Ein verkürzter Sprint aufgrund von Feiertagen etc. zählt explizit nicht zu diesem Antipattern.

Warum ist das schlecht?

Aufgrund der veränderten Sprintlänge können keine Lehren aus Fehlern in Schätzung und Planung gezogen werden.
Sprints sollen neben dieser Lernmöglichkeit auch deswegen immer gleich sein, damit sich Stakeholder und User auf regelmäßige Releases einstellen können. Verändert das Team die Sprintlänge, so kann das Vertrauen in die Umsetzungskompetenz des Teams leiden.
Eine Verschiebung des Sprintendes kann auch eine Vermeidungstaktik sein, um Probleme im Team oder in der Planung nicht ansprechen zu müssen. Dieses Verhalten schadet also bei der Zielerreichung des Projekts.

Verbesserungen:

Das Team sollte sich mit den zugrunde liegenden Problemen beschäftigen, anstatt das Problem hinaus zu schieben.
Der Scrum-Master sollte verhindern, dass die Sprintlänge vom Team verlängert oder verkürzt wird.
Die Planung und Schätzung von PBIs im Sprint sollten aufgrund der Fehler, die gemacht werden, verbessert werden. Dies ist nur dann möglich, wenn die Sprints nicht variable sind.

9 Variable Teilzeit-Teammitglieder

Beschreibung des Antipatterns:

Einzelne Teammitglieder sind nur Teilzeit im Scrum-Team beschäftigt.
Die Teilzeit, die sie pro Sprint anwesend sind, schwankt obendrein noch stark.

Warum ist das schlecht?

Ein Sprint baut auf Planbarkeit und Verlässlichkeit auf. Sind einige Teammitglieder unregelmäßig aktiv und kann man deren Kapazität nur schwer oder gar nicht einplanen, so kann das Team sich nicht gut auf Sprintziele festlegen.
Fehler in Planung und Schätzungen können ebenfalls schwerer erkannt werden, weil immer die schwankende Kapazität der Kollegen mit hineinspielt.
Teilzeitkräfte sind generell schon schwierig in Scrum-Teams zu integrieren, weil Scrum aus viel Absprachen, Planungen und Meetings besteht. Dies ist schwieriger, wenn die benötigten Kollegen zum Zeitpunkt des Meetings oder des Bedarfs nicht erreichbar sind.
Außerdem sind Teilzeitkräfte dadurch auch weniger produktiv, weil sie im Verhältnis mehr Zeit in Meetings und Abstimmungen verbringen, als sie für Umsetzungen aufwenden.

Verbesserungen:

Die Teilzeit-Teammitglieder müssen für eine Planbarkeit pro Sprint sorgen. Dies gelingt besser bei kürzeren Sprints.
Somit kann beispielsweise die Sprintdauer von vier auf zwei Wochen reduziert werden.
Sollten die Zeiten und Kapazitäten der Teilzeitkräfte dennoch nicht gut planbar sein, können separate Tracks im Sprint geplant werden, die nicht Teil des Sprintziels sind und so zu sagen als nice to have noch umgesetzt werden können, ohne dabei jedoch eine Verpflichtung auf das Produktinkrement zu haben. Dies ist allerdings mit einigen Schwierigkeiten verbunden und bedarf hoher Disziplin, Eigenverantwortung und Selbstorganisation der Teilzeitkräfte.