Definition of Done

Bild: Pexels / Daria Shevtsova - CC0 1.0

Praktisch jeder der jemals an der Erstellung eines komplizierten oder komplexen Produkts mitgewirkt hat dürfte sie kennen - die Diskussionen um die Rand-, Umgebungs- und Kontextfaktoren der Produktentwicklung und darum ob diese abnahmerelevant sind. Die Kompatibilität mit bestimmten (Produktions-)Daten gehört dazu, Schnittstellen-Anbindungen, Dokumentation, Absicherung durch Tests und vieles mehr. "Das hätte man sich doch denken können.", "Das ergibt sich aus dem gesunden Menschenverstand" und ähnliche Argumente tauchen immer wieder auf und belegen, dass die Verständnisse an diesen Stellen weit auseinandergehen.

Um dem entgegenzuwirken gibt es in Scrum (und auch in vielen Teams die andere agile Vorgehensweisen bevorzugen) die Definition of Done (DoD), eine verbindliche Regelung, die definiert was alles gegeben sein muss damit eine Abnahme stattfinden kann. Wichtig ist dabei nicht etwa, dass die DoD umfassend alle Eventualitäten regelt. Das würde zwangsläufig zu ausufernd grossen Kriterienkatalogen führen, die alleine aufgrund ihres Umfangs nicht mehr zu übersehen und kaum zu befolgen wären. Besser sollten dort nur die Bereiche geregelt werden bei denen die Teammitglieder ein unterschiedliches Verständnis haben. Dieses durch gemeinsame Entscheidungen des gesamten (Scrum) Teams zu vereinheitlichen ist der eigentliche Mehrwert.

Ich würde immer empfehlen mit einer sehr schlanken Definition of Done zu beginnen, die z.B. nur definiert auf welcher Umgebung eine Abnahme stattfindet und dass mindestens zwei Personen an jeder Anforderung gearbeitet haben müssen (Vier Augen-Prinzip). Mit der Zeit können dann weitere Kriterien dazukommen, etwa das notwendige Ausmass von Testautomatisierung und Dokumentation oder die Sprachen in denen das Produkt verfügbar sein muss. Es ist erfahrungsgemäss immer einfacher einen geringen Umfang zu erweitern als einen grossen zurückzuschneiden, zumindest gilt das für neue oder noch unerfahrene Teams. Bei ihnen nimmt der Umfang der DoD häufig über einige Monate immer weiter zu.

Erfahrene Teams tun sich mit der Reduzierung auf das Wesentliche leichter. Viele Teams mit denen ich gearbeitet habe haben ihre DoD früher oder später auf wenige Sätze zusammengestrichen, die dann eher einen Sinn reflektiert haben als konkrete Vorgaben zu machen. Eines meiner Lieblingsbeispiele ist ein Team dessen DoD aus nur einem Satz bestand: "Eine Anforderung ist abgenommen wenn der Product Owner Kuchen mitbringt". Das ganze Team hatte ein einheitliches und sehr hohes Qualitätsverständnis, und der PO war bekannt dafür, den "Abnahme-Kuchen" nur dann mitzubringen wenn das neue Feature diesem Verständnis zur Gänze entsprach und niemand mehr Widerspruch einlegte. In diesem Zusammenhang reichte dieser eine, zunächst wunderlich klingende Satz als DoD völlig aus.

Bleibt noch die Frage: was ist wenn mehrere Teams an einem gemeinsamen Produkt arbeiten, sollte man die Definition of Done in einem solchen Fall nicht vereinheitlichen? Die Antwort darauf ist ein klares Ja. Aber: der Knackpunkt ist das Wort "man". Mit ihm ist nicht etwa ein Manager, eine QA-Abteilung oder eine sonstige übergeordnete Person oder Struktur gemeint. Die gemeinsame DoD muss gemeinsam von den beteiligten (Scrum) Teams entwickelt werden. Nur so kann sichergestellt werden, dass sie bedarfsgerecht, unbürokratisch und von den Beteiligten nicht als Fremdkörper empfunden ist (das sieht auch der Scrum Guide so). Alles andere wäre ein Antipattern.

Decision Stories

Bild: Pixabay / Qimono - CC0 1.0

Eine der eher nervtötenden Tätigkeiten in Organisationen jeglicher Grösse ist das Nachvollziehen von Entscheidungen, die vor längerer Zeit getroffen worden sind. Selbst wenn alle Beteiligten noch immer anwesend sind kann es zu einer echten Herausforderung werden rückwirkend zu klären warum und unter welchen Bedingungen ein Beschluss gefasst wurde. Grundsätzlich ist das erklärbar, gerade in einem agil arbeitenden Umfeld sind Entscheidungen so häufig nötig, dass der Einzelfall in der Erinnerung verschwimmt. Man muss also dokumentieren. Und damit beginnen weitere Probleme.

Im besten Fall wird die Entscheidung im Rahmen eines Meeting-Protokolls festgehalten. Diese sind in der Regel knapp gehalten und Ergebnis-orientiert, was dann so aussehen kann (angelehnt an einen echten Fall):

Man sieht - die Entscheidung ist festgehalten, es sind auch die an der Diskussion beteiligten Personen genannt und es wird sogar auf die besprochenen Them eingegangen. Trotzdem ist im Rückblick völlig schleierhaft was letztendlich den Ausschlag für eine Option gegeben hat. Und wie gesagt, das ist noch ein gutes Beispiel. Schlimmer sind Fliesstexte, die häufig so aussehen:

Die Ausschreibung erfolgte unter den im Vergabeportal registrierten Preferred Suppliern mit Fristende auf dem letzten Tag von Q4. Basierend auf den in der Evaluierungsphase gesammelten Kriterien (vergleiche Kriterienkatalog PA30005 in der Version vom 26.11. und Procurementrichtlinie ITBesT28, Version 32.05) konnte die Auswahl auf drei Bieter eingeengt werden (siehe Entscheidungsvorlage Bieter Q4 final mit Aufschlüsselung auf die 49 als relevant identifizierten Schlüsselkriterien). Basierend auf der im Vergleich höheren Fach- und Branchenexpertise der QWERT AG und im Hinblick auf zu erwartende Synergieeffekte mit dem vom selben Bieter unterstützten Oktopus-Projekt konne in einem ersten Pitch der postive erste Eindruck bestätigt werden ...

Und so kann es über mehrere Seiten weitergehen. Schwer zu lesen, schwer zu ertragen und schwer nachzuvollziehen. Letztendlich wird die Entscheidung hier eher verschleiert als nachvollziehbar gemacht. So sollte es also nicht sein. Aber wie dann?

Eine bessere Möglichkeit die in den letzten Tagen durch meinen Newsfeed gerauscht ist greift die Idee hinter der User Story und der Vision auf und überträgt sie: wenige, in verständlicher Sprache verfasste Sätze fassen sowohl die Entscheidung als auch die dazugehörenden Kontextinformationen zusammen. Ein Beispiel:

Basierend auf der Annahme, dass der Personalbestand weiterhin um 10 % pro Quartal wächst wird die angemietete Bürofläche um 500 m² erweitert, um während des gesamten Folgejahres eine Co-Location mit 12 m² je Mitarbeiter gewährleisten zu können. Ein Plan-Ist-Abgleich findet einal pro Quartal statt, um ggf. Anpassungen der Flächengrösse vornehmen zu können.

Sechs Informationen sind hier enthalten: zugrundeliegende Hypothese, abgeleitete Massnahme, erwarteter Mehrwert, Prüfkriterien, Überprüfungsintervall und mögliche Korrekturmassnahme. Eine auf diese Weise dokumentierte Massnahme ist jederzeit nachvollziehbar, validierbar und bei Bedarf korrigierbar, ohne dass gross diskutiert oder überlegt werden müsste. Würden Entscheidungen durchgehend nach diesem Format dokumentiert würden die Unklarheiten deutlich abnehmen.Und falls das Ding einen Namen braucht - analog zur User Story würde sich die Decision Story anbieten.

On Site Customer

Bild: Pexels / Rawpixel - CC0 1.0

Nicht alles was im agilen Kontext Sinn macht muss notwendigerweise aus Scrum oder Kanban kommen. Auch andere Ansätze haben Good Practices herausgebildet, die grossen Mehrwert stiften können. Einer davon ist der sogenannte On Site Customer aus dem Extreme Programming, bzw XP. Ein Vertreter der Kunden oder Anwender der beim Umsetzungsteam anwesend ist und mit ihm zusammenarbeitet.

Wie häufig in derartigen Fällen ist die Einrichtung des On Site Customers die Reaktion auf einen Missstand. Bedingt dadurch, dass komplexe Themen nicht immer einfach zu erklären sind und verstärkt dadurch, dass Kunde und Entwickler so unterschiedliche Hintergründe haben können, dass sie quasi verschiedene Sprachen sprechen, sind in der Produktentwicklung Missverständnisse praktisch unvermeidbar. Diese zu beheben kostet dann Zeit und Geld. Der einfachste (und in vielen Fällen einzige) Weg um diese Situation aufzulösen ist die Anwesenheit eines Kunden, bzw. Endanwenders vor Ort, der unmittelbares Feedback geben kann ob die Umsetzung den Bedürfnissen entspricht.

Was dabei zu beachten ist: dieser Kundenkontakt sollte nicht nur in den Rewiew- oder Demonstrationsmeetings erfolgen (wobei das zumindest besser ist als nichts) sondern auch darüber hinaus. Ein Kunden- oder Benutzervertreter kann in Refinements seine Sicht der Dinge erläutern, kann Teams und Product Owner beraten welche Anforderungen dringend sind, welche einen hohen Business Value haben oder ein grosses Risiko beseitigen, kann MVPs und Prototypen begutachten, sich an Akzeptanztests beteiligen, eine Schnittstelle zu anderen Teilen seines Unternehmens bilden, etc.

Um das Verständnis zu klären: der On Site Customer ist nicht notwendigerweise eine immer gleiche Person, es kann auch sein, dass es mehrere gibt die sich in dieser Rolle abwechseln oder gemeinsam erscheinen. Es kann sogar sein, dass das Umsetzungsteam komplett zu den Kunden/Nutzern zieht und dort eingebettet arbeitet. Im Grunde sind die Konstellationen nicht begrenzt, alles was möglich ist kann ausprobiert werden. Nur von einer Idee ist abzuraten - davon, dass nicht die eigentlichen Benutzer des Produkts zu On Site Customern werden sondern deren Vorgesetzte. Das schafft erfahrungsgemäss direkt wieder neue Kommunikationsprobleme.

Ein Sonderfall tritt ein wenn das mit der Umsetzung betraute Team ein verteiltes Team ist, also eines das nicht an einem Ort sitzt sondern geografisch verstreut angesiedelt ist. Da solche Teams in der Regel über Videokonferenzen und Screensharing kommunizieren kann man einen On Site Customer auch auf diese Weise einbinden. Dass damit Effektivitäts- und Effizienzverluste verbunden sind ist zwar richtig, allerdings sind diese dann durch Teamstruktur verursacht und nicht durch die Kunden-Kooperation.

Minimum Work in Progress

Bild: Flickr / Vic - CC BY 2.0

Jeder der sich etwas mit den Themen Kanban oder Lean beschäftigt hat dürfte vom Konzept des Limited WIP (Limited Work in Progress) bereits gehört haben. Es ist von entscheidender Bedeutung wenn es darum geht Durchlaufzeiten zu erhöhen und Störungen des Arbeitsflusses zu vermeiden. WIP-Limits gelten als eines der zentralen Erkennungsmerkmale von Kanban-Systemen, und doch wird praktisch immer nur eine ihrer möglichen Dimensionen betrachtet, die andere wird weitgehend ignoriert.

Die überall bekannte Dimension, die oft auch mit dem generellen Begriff des Limited WIP gleichgesetzt wird ist die des Maximum Work in Progress. Diese Obergrenze und ihren Sinn näher zu betrachten wäre ein Thema für sich, verkürzt gesagt verhindert sie Multitasking und trägt dazu bei, dass Arbeit nicht unkontrolliert einfliessen und sich irgendwo im System stauen kann. Auch für sich alleine erbringt sie einen Mehrwert, kann aber nur einem Teil der möglichen Fehlentwicklungen auffangen.

Was durch eine WIP-Obergrenze nur eingeschränkt reguliert werden kann ist die Gefahr, dass irgendwo im System Leerlauf entsteht. Die tritt unter anderem dann auf, wenn zeitweise alle verfügbaren Kräfte auf eine einzige Stelle des Wertstroms konzentriert werden, etwa auf das Releasen. Wenn infolgedessen die Arbeit in einem früheren Abschnitt (etwa der Software-Entwicklung) vorübergehend eingestellt wird, kann es sein, dass ein mittlerer Teil (z.B. die Qualitätssicherung) plötzlich nichts mehr hat was er verarbeiten kann. Bis von weiter vorne neue Zwischenergebnisse kommen herrscht dann an dieser Stelle Stillstand.

Ein Mittel um einen solchen kostspieligen Leerlauf zu verhindern (auch im Stillstand müssen Gehälter bezahlt werden), ist die Einrichtung weiterer WIP Limits, nur in diesem Fall an der Untergrenze. Ein solches Minimum Work in Progress sorgt dafür, dass bei ihrem Erreichen sofort neue Arbeit nachgezogen werden muss, selbst wenn das auf den ersten Blick nicht dringend erscheint. Die nachfolgende Station ist dadurch ebenfalls immer in der Lage Arbeit nachzuziehen sobald sie freie Kapazitäten hat.

An dieser Stelle muss auch klar sein, dass ein Minimum WIP nicht nur Probleme lösen sondern sie im schlimmsten Fall sogar erzeugen kann. Wenn es dazu führt, dass einer oder mehrere Abschnitte eines Produktionsprozesses zu 100 Prozent ausgelastet sind, sind mitunter verstopfte Warteschlangen die Folge. Optimalerweise sorgt es daher nicht nur dafür, dass jederzeit Arbeit nachgezogen werden kann, sondern es lässt auch Spielraum für neue, ungeplante Arbeit. Minimum WIP und Maximum WIP sollten nicht gleich groß sein, sondern immer einen Korridor dazwischen freilassen.

Eine Hilfe für die (De)Zentralisierung von Entscheidungen

Bild: Pxhere - CC0 1.0

Da das Thema der Skalierung von agilen Vorhaben bei fast allen meinen Kunden eine Rolle gespielt hat, komme ich nicht daran vorbei, mich mit den verschiedenen gängigen Skalierungsframeworks zu beschäftigen, unter anderem mit SAFe. In diesem Zusammenhang bin ich an dessen Dezentralisierungs-Prinzip hängengeblieben, bzw. an einem dort empfohlenen Tool. Mit seiner Hilfe kann geklärt werden ob eine Entscheidung zentral oder dezentral getroffen werden sollte.

Nun kann man in Bezug auf SAFe geteilter Meinung sein, das Tool ist aber tatsächlich hilfreich, vor allem in Organisationen in denen Agilität noch nicht sehr tief verwurzelt ist. Ins Deutsche übersetzt (und leicht angepasst) sieht es so aus:

Die drei Entscheidungskategorien sind schnell erklärt: häufige Entscheidungen würden zentrale Instanzen überlasten, was zu langen Wartezeiten führen würde. Zeitkritische, also dringende Entscheidungen würden in der zentralen Instanz weniger dringende, aber in der langfristigen Betrachtung wichtigere Themen verdrängen. Kontextabhängige Entscheidungen würden einen zeitaufwändigen Wissenstransfer zur zentralen Instanz erfordern oder müssten uninformiert getroffen werden. Um diese negativen Auswirkungen zu vermeiden bleibt nur eine Delegation nach unten, in die Teams.

Wie genau die drei Faktoren ermittelt werden können kann von Fall zu Fall unterschiedlich sein, ein denkbarer Weg wäre z.B., dass alle Beteiligten sich zusammenfinden und durch das Hochhalten von Fingern oder Planning Poker Karten ihre Einschätzung abgeben. Das hätte den zusätzlichen Vorteil, dass verschiedene Sichtweisen eingebracht werden können. In anderen Fällen ist das Ergebnis vielleicht so offensichtlich, dass es keiner grossen Diskussion mehr bedarf.

Zuletzt empfiehlt es sich, das Tool in gewissen Abständen immer wieder einzusetzen, da die Faktoren sich mit der Zeit ändern können. Beispielsweise kann es sein, dass der Austausch mit einem Kunden zuerst auf Geschäftsführer-Ebene stattfindet, sich aber mit der Zeit zu einem intensiven Austausch zwischen Produktentwicklung und Endanwender entwickelt. In einem solchen Fall wäre eine nachträgliche Dezentralisierung sinnvoll.

Siehe auch: Subsidiarität.

Brainstorm Hole

Es ist nicht so, dass Brain Stormings per se schlecht wären. Man muss sich aber bewusst machen: der Grundsatz, dass jeder alles sagen darf ohne kritisiert zu werden kann dazu führen, dass auch viel Unsinn dabei ist. Dass sollte von Beginn an jedem klar sein. Ohne gute Moderation entstehen dann Situationen wie die hier.

Kommentierte Links (XXXVI)

• Mike Cohn: Defect Management by Policy

  Als ehemaliger Testmanager bin ich an dieser Stelle ganz bei Mike Cohn: der einfachste Weg Defects zu priorisieren, bzw. festzulegen wann sie gefixt werden sollen, ist eine Einordnung in Gruppen, bzw. Kategorien. Eine Einzelfall-basierte Entscheidung wäre vielleicht individuell passender, treibt aber den Wert der Cost Per Reasonable Decision in unschöne Höhen. Was mit welcher Defect-Gruppe, bzw. Kategorie passiert ist nach jeweiligem Kontext festzulegen, ich bin da bekanntermassen ein Fan von Zero Bugs und Instant Implementation. Nicht, dass ich den anderen Fall nicht auch erlebt hätte, aber gerade darum - wer schon einmal in der Quälerei einer mehrmonatigen nachgelagerten Bugfixing-Phase gewesen ist will da nie wieder hin.

• FAZ: Rugby für das Büro

Eines vorweg: wenn agile Softwareentwicklung "superhip, superinnovativ und superstressig" ist (Zitat des FAZ-Autors Benjamin Fischer) dann ist sie falsch umgesetzt. Schließlich sind die Umsetzungsteams verpflichtet nur soviel in die Sprints, bzw. in Progress zu nehmen wie realistisch machbar ist, und auch dem Management stehen verschiedene Techniken zur Verfügung um Überlastung zu vermeiden. Was Fischer aber richtigerweise auch schreibt: in Umbruchphasen zwischen klassischem Management und agilem Vorgehen kann die Situation für alle Beteiligten aufreibend sein, alleine deshalb weil sich aktueller Status und angestrebter Karrierepfad plötzlich in Luft auflösen. Ein Problem das häufig unterschätzt wird.

• Mark Schwartz: Leading Change from the Middle

  Wenn es eine Gruppe gibt deren Leben im Rahmen agiler Transitionen schwerer wird, dann ist es das mittlere Management. Oft zu Recht und häufig zu Unrecht wird es als Teil des Problems und nicht als Teil der Lösung gesehen, weshalb nur die wenigsten Transitionsprogramme eine klare Antwort darauf haben, welche Rolle ein mittlerer Manager zukünftig spielen soll und wie er dorthin kommen kann. Vor dem Hintergrund, dass die Vordenker von Scrum in dem mittleren Management eigentlich einen zentralen Faktor gesehen haben ist das sehr zu bedauern. Um so besser, dass es vereinzelt doch Überlegungen in diese Richtung gibt, wie diese hier von Mark Schwartz. Und ganz nebenbei: dass sie auf einem offiziellen Firmenblog von Amazon veröffentlich wird zeigt, dass diese Firma vieles besser macht als die Konkurrenz.
  

• Nicolas Muldon: Customer Personas - How to Write Them and Why You Need Them In Agile Software Development

  Einer meiner Lieblingstweets der letzten Zeit lautet: "Lest eure User Stories. Und stellt euch dabei vor, wie der User, den das betrifft, das GENAU SO sagt." Was dahinter steckt ist die Erkenntnis, dass User Stories in den meisten Fällen genau das nicht sind, was sie eigentlich sein sollen - aus der Sicht eines Nutzers/Anwenders geschrieben. Stattdessen sind es die alten Elfenbeinturm-Ideen, nur wunderlich formuliert. Nicolas Muldon hat völlig recht wenn er schreibt, dass Personas hier für bessere Ergbnisse sorgen können. Richtig eingesetzt helfen sie dabei, besser zu verstehen was überhaupt die Wünsche und Bedürfnisse der Menschen sind, für die man sein Produkt baut.

• Ian Borges: Why Semco Doesn’t Want Your Company To Be Like Semco

  Noch immer ist es so, dass manche Unternehmen versuchen ihre agile Transition zu beschleunigen indem sie die erfolgreichen Ansätze von anderen Firmen eins zu eins kopieren. Einen gewissen Hype gab es zeitweise um den Spotify Way, was mittlerweile zum Glück zurückgeht. Ab und zu hört man jetzt andere zu kopierende Vorbilder, wie Zalando, ING oder Semco. Was in diesem Artikel stellvertretend für sie alle gesagt wird: das wird auch hier nicht funktionieren. Der aktuelle Stand in diesen Firmen beruht auf jahrelangem, zum Teil jahrzehntelangem kulturellen Wandel und befindet sich auch weiterhin in einem stetigen Zustand der Anpassung und Veränderung. Eine Momentaufnahme davon einzufrieren und als Blaupause zu verwenden ist nicht zielführend.

Sprintziele

Bild: Wikimedia Commons / Santeri Viimäki - CC BY 4.0

Kurze Frage: welcher Begriff wird im Scrum Guide ganze 26 mal (!) erwähnt, findet sich aber in sehr vielen Scrum Teams nicht wieder? Die Antwort: das Sprintziel, bzw. Sprint Goal. Obwohl Sprintziele von offensichtlich so großer Bedeutung sind würde ich sagen, dass sie bestenfalls in der Hälfte der über 100 Teams mit denen ich über die Jahre zusammengearbeitet habe verwendet wurden. Die anderen haben einfach nur mehr oder weniger zusammenhängende Arbeit in ihre Sprints gezogen, im Normalfall die obersten User Stories / Anforderungen ihres Product Backlogs. Und das ist ein Problem, denn ohne diese Ziele sind einige Vorteile schwerer erreichbar.

Ein Sprintziel hilft dem Product Owner bei der Planung. Wie in anderen Vorgehensweisen lassen sich auch in Scrum Aufgaben vom Grossen ins Kleine herunterbrechen. Aus der Produktvision wird z.B. eine Teilvision, daraus einige Meilensteine und daraus mehrere Sprintziele. Auch die können und sollen einem Inspect & Adapt unterliegen, trotzdem (oder gerade deswegen) können sie ein gutes Werkzeug sein um Arbeit in Etappen einzuteilen, die man nach und nach planen und angehen kann.

Ein Sprintziel hilft dem Product Owner bei der Priorisierung. Was im Backlog weiter oben stehen sollte und was nicht ist oft nur schwer zu bestimmen. Ist z.B. eine bessere Exportierbarkeit von Kundendaten wichtiger als eine bessere Importierbarkeit von Stammdaten? Wer kann das sagen? Werden die einzelnen Anforderungen zu Sprintzielen gruppiert kann das einfacher sein. Wenn das nächste Sprintziel z.B. lautet, bis zum bald bevorstehenden Stichtag DSGVO-kompatibel zu sein, dann ist klarer was dazugehören sollte (Kundendaten exportieren) und was nicht (Stammdaten-Import).

Ein Sprintziel hilft einem Team dabei fokussierter und konzentrierter zu arbeiten. Gerade bei komplexen und komplizierten Themen gibt es kaum einen größeren Produktivitäts-Hemmer als häufiges Kontext Switching. Sich in kurzen Abständen in immer neue Themen eindenken und immer neue Schnittstellen und Abhängigkeiten klären zu müssen kann in absurdem Ausmass Zeit fressen. Umgekehrt kann das fokussierte Arbeiten an einem Themenkomplex für Synergieeffekte im Denken und Umsetzen sorgen, die vieles beschleunigen.

Ausserdem hilft ein Sprintziel auch bei der Erfolgsmessung, und zwar in der denkbar einfachsten Weise. Man muss sich nur fragen: Haben wir das Sprintziel erreicht, ja oder nein? Damit das möglich ist müssen die Formulierungen natürlich klar und überprüfbar sein, also nicht "Wir wollen ein besseres Nutzungserlebnis bieten" sondern "Wir wollen die Anzahl der bis zum Geschäftsabschluss notwendigen Mouseclicks unter 20 drücken". Als Nebeneffekt führen die dafür nötigen Überlegungen und Diskussionen auch zu einem besseren Verständnis dessen was mit der Anforderung eigentlich gewollt ist.

Zuletzt noch ein Hinweis der selbstverständlicher klingt als er ist - es sollte ein Sprintziel geben, nicht mehrere. Auch hier ein Beispiel: "Wir wollen die die Performance erhöhen und das Design von Rot-Blau auf Grün-Silber umstellen" ist zwar ein Satz, trotzdem sind es mehrere Ziele. Ich habe mit Teams gearbeitet, die alle Sprintziele abgelehnt haben in denen ein Komma, ein Punkt oder die Wörter "und" und "ausserdem" vorkamen. Es hat ihnen geholfen.