Der Scrum-Reiseführer. Tobias Renk

immer auf der Feature- oder Epic-Ebene ab (siehe Abbildung 19). Die Sprintziele lassen sich so wesentlich konkreter formulieren. In diesem Szenario könnte das erste Sprintziel daher „Bereitstellung der Infrastruktur“ lauten. Das zweite Ziel könnten Sie als „Verbesserung von Feature XY“ festlegen. Auf diese Weise wird das Team motiviert, gemeinsam auf ein Thema hinzuarbeiten, anstatt alles parallel machen zu wollen und an unterschiedlichen Themen zu arbeiten. Selbstverständlich darf die agile Vorgehensweise bei der Entwicklung der Sprintziele nicht zu kurz kommen. Sollte sich während eines Sprints herausstellen, dass aufgrund eines unerwarteten Aufwands oder einer blockierten Aufgabe nicht alles erledigt werden kann, ermitteln Sie gemeinsam mit dem Product Owner, ob das das Sprint Backlog reduziert wird. Das Sprintziel sollte dabei nicht verändert werden. „Alle User Stories aus der Sprintplanung sind zu erledigen“ ist daher kein sinnvolles Sprintziel. Es muss auch dann erreicht werden können, wenn es nicht vollständig der Planung entspricht. Das Sprintziel „Reduzierung der Code-Komplexität von Feature XY“ bietet zum Beispiel ausreichend Spielraum.

      Abbildung 19:

      Produkttaktik

      Im obigen Sprintziel aus den Bereich Refactoring könnte es das Ziel sein, eine 20-prozentige Verbesserung der Code-Komplexität zu erreichen. Was passiert, wenn nur 19 % erreicht wurden? Lässt sich dann noch immer von Erfolg sprechen? Vermeiden Sie deshalb vage Begriffe wie Erfolg oder Erfüllung von Zielen. Deutlicher wird es am Beispiel der Sorites-Paradoxie (Paradoxie des Haufens) oder an der Paradoxie des Eubulides (Paradoxie vom Kahlköpfigen). Die Sorites-Paradoxie beinhaltet die Frage, ab wann ein Sandhaufen kein Sandhaufen mehr ist, wenn einzelne Sandkörner entfernt werden.

       Gegeben: Ein Sandhaufen, aus dem einzelne Körner entfernt werden.

       Annahme: Das Entfernen eines einzelnen Korns verwandelt einen Haufen nicht in einen Nicht-Haufen.

       Paradoxie: Was passiert, wenn bei der bestehenden Annahme der Prozess „Entfernen eines einzelnen Sandkorns“ oft genug wiederholt wird? Ist ein einzelnes Sandkorn dann noch ein Haufen? Wenn nicht, wann hat es sich von einem Haufen in einen Nicht-Haufen verändert? Ist ein Sandhaufen durch die Anzahl der Körner definiert? Wenn ja, was ist, wenn alle Körner nebeneinander angeordnet sind?

      Die Paradoxie des Eubulides stellt die Frage, wie viele Haare ein Mensch besitzen muss, um nicht als kahlköpfig zu gelten. Beiden Paradoxien liegt die Annahme zugrunde, dass ein einzelnes Sandkorn oder ein einzelnes Haar nicht über die Ausprägung Haufen oder behaart oder kein Haufen bzw. kahl entscheiden könne. Die Paradoxie zeigt sich in beiden Fällen, wenn versucht wird, etwas zu bestimmen, für das keine genaue Definition existiert.

      Dieser Herausforderung können Sie umgehen, indem ein fester Grenzwert festgelegt wird. (Beispiel: 20-prozentige Reduzierung der Komplexität des Programmcodes). Gängige Praxis ist auch, einen Grenzbereich (Beispiel: 15- bis 20-prozentige Reduzierung der Komplexität des Programmcodes) oder mehrere Grenzwerte (Beispiel: Bei unter 8 bis 10 % ist das Ziel nicht erreicht, zwischen 10 und 15 % ist das Ziel erfüllt, bei über 15 % wird das Ziel übertroffen) zu verwenden. Sie können auch im Gruppenkonsens prüfen, ob das Ziel erreicht wurde (Beispiel: Gruppe entscheidet, ob die Verbesserung der Programmcodes ein Erfolg war). Lassen Sie bei der Bewertung genügend Spielraum. Welches Team hat schon Lust, das Sprintziel regelmäßig zu verfehlen, obwohl es nur wenige Prozentpunkte hinter den Zielvorgaben liegt?

      Abbildung 20:

      Überprüfungsintervalle von der Taktik bis zur Vision

      Wie auch immer die Sprintziele bewertet werden, sie haben Auswirkungen auf das nächste Ziel der Product Roadmap. Daher sollten die Sprintergebnisse, abhängig von der Länge der Sprints, alle paar Wochen oder nach zwei bis drei Sprints dahingehend untersucht werden, ob das nächste Ziel auf der Product Roadmap noch realistisch ist. Abhängig davon kann das nächste Sprintziel darauf ausgerichtet werden. Vielleicht ist auch eine Korrektur der Ziele auf der Roadmap notwendig, um das nächste Produktziel zu erreichen. Daher sollte auch die Roadmap alle paar Monate (abhängig vom Roadmap-Typ, der Sprintlänge und den Produkttypen) überprüft und angepasst werden. Wenn anhand der Roadmap erkannt wird, dass ein Produktziel nicht erreicht wird oder obsolet geworden ist, sollte auch das Produktziel angepasst werden. Das sollte alle zwei bis neun Monate erledigt werden. Das Gleiche gilt für die Produktstrategie und die Vision. Prüfen Sie diese alle sechs bis zwölf Monate und nehmen Sie entsprechende Anpassungen vor. So erreicht man eine Rückkopplung von den Sprintergebnissen bis hin zur Produktvision (siehe Abbildung 20).

      Abbildung 21:

      Schritte von der Produktidee zu den Sprintzielen

      In Abbildung 21 sind nochmal die wesentlichen Schritte auf dem Weg von der Produktidee zu den Sprintzielen zusammengefasst. Abbildung 22 zeigt die Rückkopplung, ausgehend von Sprintergebnissen bis hin zur Anpassung der Produktausrichtung.

      Abbildung 22:

      Von den Sprintergebnissen zur Anpassung der Produktausrichtung