Das Sprint Review Meeting wird zu Ende des Sprints durchgeführt. Die entwickelten Features werden dem Kunden präsentiert und Feedback eingeholt. 

 

Was ist das Sprint Review? 

Das Sprint Review ist ein echtes Highlight für die Stakeholder, denn hier gibt es Ergebnisse zu sehen! Zum Ende eines Sprints wird das Sprint Review Meeting durchgeführt, in dem die entwickelte Funktionalität dem Kunden live vorgeführt und Feedback eingeholt wird.

 

Wer lädt zum Sprint Review ein?

Die Teilnehmer sind: Das Entwicklungsteam, die Stakeholder, der Product Owner und der Scrum Master.

Hierbei präsentieren also Entwicklungsteam und Product Owner den Stakeholdern den Projektfortschritt auf der Systemumgebung „CAT“ (Customer Acceptance Testing), welche ab dem Sprint-Review für die Inspektion der Sprintergebnisse dem Kunden zur Verfügung steht.

Sprint Review

 

Wie läuft das Sprint Review Meeting ab? 

Das Entwicklungsteam demonstriert zunächst den neu hinzugekommenen Teil des Inkrements den Stakeholder und lässt sie diesen selbst anwenden. Anhand des Feedbacks der Stakeholder ergeben sich potentielle Produktverbesserungen in Form neuer Inputs für das Product Backlog und somit auch für den nächsten Sprint.

Die Ergebnisse des Sprints werden hier auch „formell“ abgenommen, da alle Tests inkl. Integrationstests bereits während des Sprints erfolgt sind. Im Sprint Review geht es darum, anhand des Inkrements festzustellen, inwiefern Anpassungen im Product Backlog vorzunehmen sind. So kann das Produkt weiterhin verbessert werden.

User Stories, an welchen zwar in diesem Sprint gearbeitet wurde, jedoch die Tests nicht bestanden haben, gelten nicht als Teil der Lieferung des Sprints und „wandern“ zurück ins Product Backlog.

Wir liefern für jeden Sprint neben der Bereitstellung der Software auf einer Test-Infrastruktur („CAT“) auch einen umfassenden Sprint-Report ab, der neben einer Übersicht der gelieferten Software auch Dokumentation zum Sprintplan und der Umsetzung umfasst.

 

Wie funktioniert eine rollierende Planung? 

Das Entwicklungsteam wird das vom Product Owner bereitgestellte Product Backlog in Punkte-Einheiten, sogenannten Story Points, jeweils so umfassend abschätzen, dass ausreichend viele User Stories aus dem Product Backlog für mindestens drei Sprints geschätzt zur Verfügung stehen.

Diese Schätzung wird laufend durchgeführt, sodass im „eingeschwungenen“ Zustand stets ein hinreichend geschätztes Product Backlog verfügbar ist, welches als Basis für die Release-Planung herangezogen wird.

Auf Wunsch kann diese Schätzung auch deutlich weiter in die Zukunft vorgenommen werden. Damit ist auch eine langfristige Planung möglich, wenngleich die Genauigkeit der Planung mit der Entfernung des Planungshorizonts abnimmt.

Am Ende eines Sprints wird die Entwicklungsgeschwindigkeit, die Velocity, festgestellt, in dem die Schätzungen, in Story Points, all jener User Stories addiert werden, die im Sinne der „Definition of Done“ geliefert wurden. Diese über mehrere Sprints hinweg gewonnene Duchschnitts-Velocity dient als Grundlage für die weitere (Release-) Planung.

Wir bei Objectbay verstehen uns als Ihr Digitalisierungs-Partner im Kontext Individual Software. Von der Idee zum fertigen Produkt, wir liefern end2end und unterstützen unsere Kunden

  • bei der Modernisierung oder Erweiterungen bestehender digitaler Lösungen
  • beim Ablösen veralteter Individualsoftware durch neue Frameworks
  • bei der Entwicklung völlig neuer digitaler Produkte, Services und Anwendungen

 

Sie wollen mehr über die Arbeitsweise von Objectbay erfahren?

Hier geht's zum gesamten Whitepaper „So läuft's bei uns @Objectbay“.

JETZT HERUNTERLADEN!

 

Für E-Mail-Updates anmelden

Suchen