Scrum sieht vor, dass zum Ende eines jeden Sprints ein Product Increment breitgestellt wird, welches potentially shippable ist. Dies bedeutet, im weiteren Sinne, dass die erstellte Produktverbesserung einen Mehrwert stiftet, der auch direkt “geerntet” werden kann (Return on Invest), wenn der Product Owner einer Veröffentlichung zustimmt. Man könnte auch sagen: DONE.

All DONE am Ende eines Sprints (Sprint Review Meeting) bedeutet DONE!

Im engeren Sinne ist dies dadurch geprägt, dass die zu Sprintbeginn im (Sprint Planning I) zugesagten User Stories vom Scrum Team

  • umgesetzt,
  • getestet und
  • auslieferbereit

sind. Ist nur einer dieser Aspekte nicht vollständig oder nur unzureichend erfüllt, so fordert dies bei einer Produktivnahme Tribut. Insbesondere, wenn der Aspekt “Test/Qualität” nur stiefmütterlich gehandhabt und über die Zeit vernachlässigt wird, steigt insgeheim die Sorge, dass etwas “übersehen” wurde oder noch etwas zu tun ist. Die Folge: vor einem GoLive wird die bereitgestellte Applikation vom Fachbereich “durchgetestet” und siehe da: doch nicht so ganz DONE.

“Kleinere Nacharbeiten bitte hier, ein paar Anpassungen bitte dort und jenes hier funktioniert nicht, wie erwartet… so können wir nicht live gehen.”

Fleißigst werden Fehler-Tickets erfasst und diese direkt an das Entwicklerteam adressiert, mit der dringlichen Bitte diese bis zum geplanten GoLive noch zu realisieren und auszuliefern - that’s not Scrum, that’s not Agile - that’s Hell! Avoid that!

Die Aufgaben während eines Sprints beinhalten nicht nur die Erstellung der Produktfeatures, sondern diese auch auf Herz und Nieren zu testen… dies im Dialog und partnerschaftlich konstruktiv mit dem Fachbereich zusammen - und das nicht nur im Zweifel.

Akzeptanzkriterien müssen vor der Realisierung einer User Story bekannt sein und / oder aktiv vom Scrum Team erarbeitet werden. Alle Seiten, insbesondere der Product Owner und das Entwicklerteam, müssen ein gemeinsames Verständnis entwickeln, was DONE bedeutet und beinhaltet, bevor mit einer Realisierung begonnen wird.

Das Scrum Ereignis Sprint Review ist der spätest mögliche Zeitpunkt, um ein Feature, eine Produkt-Verbesserung oder ein Inkrement dem Product Owner zu zeigen / vorzustellen. Alle Tests und Quality Gates bis zur Lieferung (DONE) sollten erfolgreich durchlaufen sein, so dass sich beim Review Meeting alle entspannen können und die Frage

“Nehmen wir es gleich live?”

mit einem eindeutigen

“Ja, klar, sehr gerne. Wir sind uns alle sicher, dass der Mehrwert des Produkt-Inkrements direkt vefügbar ist.”

beantwortet werden kann.

Die Sorge, dass etwas übersehen wurde kann dadurch verringert werden, dass die Betroffenen (beispielsweise Fachbereich, Benutzer) sich nicht erst kurz vor dem GoLive mit den neuen Features beschäftigen. Ein aktives Stakeholder-Management durch den Product Owner, sowie die Beteiligung der Fachbereiche und der Benutzer bei der Formulierung und Realisierung von User Stories mindern die Sorgen und vereinheitlichen die Sicht auf das Product Increment nachhaltig. Hier leisten vom Fachbereich formulierte Akzeptanzkriterien ebenso einen wichtigen Beitrag, wie seine aktive Teilnahme an Sprint Reviews, BAcklog Refinements und Sprint Plannings.

Im Rahmen eines laufenden Sprints und der vorliegenden User Stories, kann das Entwicklerteam auch darauf hinwirken, die erstellten Funktionen / Features noch vor dem finalen Review mit dem Product Owner zu besprechen und sich erste Feedbacks einholen - Inspect and Adapt, continuously.