Scrum-Grundlagen: Agile Softwareentwicklung

Was passiert im Sprint Review Meeting?

Testen Sie unsere 1958 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Hier erfahren Sie, warum es sinnvoll ist, dem Product Owner die Ergebnisse auf ganz bestimmte Art und Weise zu zeigen. Das "echte" Erlebnis ist entscheidend.
04:43

Transkript

In diesem Kapitel sehen wir uns gemeinsam ein weiteres Scrum-Ereignis an, das sogenannte Sprint Review Meeting. Wir kennen mittlerweile schon etliche Ereignisse und haben uns denen mit Fragen genähert. In welchem Takt wollen wir liefern, in welchem Sprint wollen wir uns organisieren? Was wird vom Product Owner gebraucht und wie setzen wir es um? Das Ereignis dazu war das Sprint Planning Meeting. Wir haben uns die Frage gestellt: "Sind wir als Team noch auf Kurs?" Das war das Daily Scrum Meeting. Und jetzt kommt die entscheidende Frage: "Ist es das, was Du gebraucht hast, lieber Product Owner?" Wir tun das im Sprint Review Meeting, d.h. in diesem Meeting stellt das Team dem Product Owner die Funktionalität, die sie realisiert haben, vor. Der Product Owner schaut sich die Funktionalität an und nimmt die im günstigsten Fall ab. Also genau das, was vorher besprochen wurde. Der Zweck dieser Review-Runde ist es, eine Institution zu schaffen, um regelmäßig Funktionalität liefern zu können. Nicht erst am Projektende nach einem Jahr, sondern wirklich in einer kurzen Taktung. Und das ist die Abnahmebesprechung dafür. Abnehmen tun wir Sachen, die fertig sind. Fertig haben wir in unserer Definition auf "Done" greifbar gemacht. Wir haben beschrieben, welche Kriterien erfüllt sein müssen. Und wir müssen uns als Team wirklich disziplinieren und in dieser Review-Runde nur diese Funktionalität zeigen, die auch wirklich fertig ist, die alle Kriterien erfüllt. Wenn auch nur ein Kriterium fehlt, dürfen wir es dem Product Owner nicht zeigen, weil wir würden uns in die eigene Tasche lügen und wir würden den Product Owner blenden mit Funktionalität, die noch nicht vollständig ist. Wir wollen ihn auch nicht blenden mit hübschen Power Points, sondern wir wollen ihm die echte Software zeigen, also wirklich die Funktionalität, die entstanden ist. Nur anhand der echten Software kann der Product Owner greifbar entscheiden, ob es das ist, was er gebraucht hat, oder ob noch Änderungswünsche vorhanden sind. Bei dieser Planungsrunde sollte jedes Teammitglied die Funktionalitäten vorstellen, die es selber implementiert hat. Das hängt zum einen damit zusammen, dass man stolz sein kann auf das, was man realisiert hat. Das kann man auch gerne zeigen und sich gut dabei fühlen. Zum anderen hat es den psychologischen Nebeneffekt: Wenn ich meinem Product Owner selber etwas zeigen muss, werde ich auch dafür sorgen, dass es funktioniert. Wenn es mein Kollege zeigt und ich mir denke: "Naja, wenn es nicht passt, der kann gut reden, der windet sich da schon raus", ist ein Unterschied. Also, jedes Teammitglied sollte selber zeigen, was entstanden ist. Der Zeitbedarf dafür sollte mit 2 Stunden für einen Zwei-Wochen-Sprint angesetzt werden, bei einem Vier-Wochen-Sprint dann entsprechend 4 Stunden. Der Product Owner hat natürlich das Recht, Wünsche zu äußern. Die notiert er sich und lässt sie ins Product Backlog für folgende Sprints einfließen. In dieser Runde ist es für Sie als Team wertvoll, wenn der Product Owner vielleicht einen Vertreter des Kunden oder vielleicht sogar einen oder zwei Endanwender mitbringt. Weil nur wenn das Team besser versteht, wie die Software später genutzt wird, kann sie auch entsprechend gleich im ersten Versuch die Funktionalität realisieren. Was passiert mit Sachen, die nicht fertig geworden sind? Der Product Owner entscheidet, ob er sie neu priorisieren und ins Backlog vielleicht weiter unten einordnen will, oder ob er, was eher die Regel ist, sagt: "Naja, es ist nicht ganz fertig geworden. Gut, dass ihr es mir nicht gezeigt habt. Macht es bitte im nächsten Sprint fertig. Ich lasse es oben mit einer hohen Priorität in meinem Backlog stehen." Mit diesen Kriterien kann man es sehr gut schaffen, Funktionalität abzunehmen, vom Tisch zu schaffen, abzuhaken und sich Neuem zuzuwenden. Unser Team hat mittlerweile den ersten Sprint absolviert. Es ist Funktionalität entstanden und Sie wollen diese Funktionalität dem Product Owner vorstellen. Ich glaube, es wird nicht gleich beim ersten Versuch richtig günstig ablaufen, aber schauen wir unserem Team mal über die Schulter. Ich selber werde in der Szene als Product Owner agieren.

Scrum-Grundlagen: Agile Softwareentwicklung

Machen Sie sich mit der Softwareentwicklung mit Scrum vertraut und sehen Sie, wie Sie komplexe Projekte agiler, qualitativ besser, kundenorientierter und motivierter meistern.

3 Std. 34 min (49 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!