Das Sprintziel ist ein Hilfsmittel in der nach Scrum organisierten Produktentwicklung und beschreibt, was das Ziel eines Sprints ist (was ja offensichtlich ist). Es ist dabei eine Ableitung und Konsequenz aus der Produktvision. Ein Sprintziel heißt niemals alle Inhalte des Product Backlog zu schaffen. Das würde ein Sprintziel nur ad absurdum führen, denn wie soll es dann dem Team helfen? Meine Lieblingsform für Sprintziele ist die User Story.
Zweck des Sprintziels
Noch einmal kurz zum Kernnutzen eines Sprintziels. Natürlich kann man im Planning mit dem Team einfach so viele Items aus dem Product Backlog in das Sprint Backlog nehmen wie das Team glaubt zu schaffen. Aber dann kann es schnell sein, dass ein Fokus fehlt. Ein Fokus, der dem Team hilft zu entscheiden, was im Sprint wirklich wichtig ist. Ein Team kann mit klarem Fokus auch bei unvorhergesehenen Ereignissen entscheiden was getan werden muss. Wird beispielsweise jemand aus dem Team krank, kann das Team selber entscheiden, was aus dem Sprint Backlog wieder ins Product Backlog wandert. Sie können selber entscheiden, ob sie Teile ihrer Arbeit modifizieren und damit weiterhin das Sprintziel erreichen. Das befreit sie auch von einer „Betreuungsnot“ durch Product Owner. Natürlich bin ich für eine enge Zusammenarbeit. Manchmal sind Product Owner aber im Urlaub, krank oder anderweitig nicht verfügbar. Das Team aber muss weiter entscheidungs- und handlungsfähig sein.
Inhalt eines Sprintziels
Das Sprintziel gibt dem Team den Grund, warum man das Inkrement baut (siehe auch Topic 2 im Sprintplanning). Dennoch fällt es schwer ein Sprintziel direkt aus dem Ärmel zu schütteln. Wir können uns aber vorzustellen, man würde den Chef, einen Kunden oder jemand anderen wichtigen außerhalb des Teams in einem kurzen Satz erklären, was man eigentlich im aktuellen Sprint machen würde. Es ist auch in Ordnung, wenn das Sprintziel eine der Storys exakt widerspiegelt. Dann muss diese User Story aber auch für den Kunden/Nutzer/etc. so wichtig sein, dass das Team das Gefühl hat, mit diesem Sprint einen wichtigen Beitrag geschafft zu haben. Im Regelfall passiert mir das nur, wenn noch eine wichtige Story für ein Epic oder ein geschlossenes Featureset benötigt wird, ohne dass andere Inhalte nicht verwendet werden kann (oder sich für Nutzer nicht gut anfühlen würde).
Das Sprintziel als Story formulieren
Man kann das Ziel eines Sprints in vielen verschiedenen Varianten formulieren. Wenn ein Team bereits User Storys benutzt, schreibt ein Sprintziel als User Story (oder noch besser als Persona-driven User Story). Wir sind es gewöhnt, dass Storys mal feiner und mal gröber sind. Ein Sprintziel könnte zum Beispiel wie folgt lauten: „Als Anwender kann ich meine Rechnungen automatisch versenden, damit ich nicht mehr daran denken muss sie später abzusenden.“. Diese Form beschreibt wie bei jeder User Story den Grund, warum ein Nutzer das braucht und ist im Kern ein Versprechen für Kommunikation und Austausch. Das Team kann ein solches Sprintziel wie auch jede andere Story besprechen und ausgestalten. Dazu gehören auch Akzeptanzkriterien. Gerade wenn ein Team kein fertiges Konzept zur Umsetzung bekommt, sondern selber die einzelnen Ergebnisse herleiten kann, hilft es hier noch einmal das Gesamtpaket eines Sprints mit allen Beteiligten zu besprechen und zu klären.
Da die Akzeptanzkriterien eines Sprints teilweise Storys aus dem Sprintbacklog wiederspiegeln, empfehle ich die Kriterien zu priorisieren. Es gilt klar herauszustellen, welche Akzeptanzkritieren absolut erforderlich sind damit das Sprintziel erreicht ist. Einige Backlog Items zahlen vielleicht nicht direkt auf das Sprintziel ein. Dafür weiß das Team dann welche sie zuerst „opfern“ können.
Was könnte also dagegen sprechen das Sprintziel als User Story zu formulieren? Eigentlich nichts 🙂
0 Kommentare