Scrum-Grundlagen: Agile Softwareentwicklung

Was passiert im Sprint Planning Meeting?

Testen Sie unsere 2005 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
In diesem Video werden Sie erkennen, wie man mit den einfachen Fragen "Was" und "Wie" zu viel mehr Klarheit kommt als man denkt
06:51

Transkript

In den nächsten Minuten sehen wir uns gemeinsam den Ablauf des Sprint Planning Meetings an. Im Wesentlichen besteht das Sprint Planning Meeting aus zwei Teilen. Den ersten Teil nenne ich "Was"-Teil, den zweiten Teil nenne ich den "Wie"-Teil. Quasi: "Was" ist zu tun, was soll entstehen, und "Wie" wollen wir das technisch umsetzen? Das Ziel dieser Runde ist es, dass nach der Besprechung das Team mit der Umsetzung der Features beginnen kann - mit der Umsetzung einer Teilmenge. Was als Basis für dieses Planning Meeting dient, ist das Product Backlog. Das Team pickt sich die zuoberst stehenden Features heraus, die im nächsten Sprint entstehen sollen. Der Output dieser Planungsrunde ist das Sprint Planning Meeting, quasi die Arbeitsliste mit dem detaillierten Arbeitsschritten, die nötig sind, um diese Funktionalität zu realisieren. Als Zeitrahmen kann man von vier Stunden für einen 2-Wochen Sprint ausgehen. Ja, wenn Sie den 4-Wochen Sprint haben, dann ist es entsprechend doppelt so viel und bei einem 1-Wochen Sprint ist es entsprechend die Hälfte. Diese Timebox sollten Sie auch einhalten. D.h., wenn Sie nicht fertig geworden sind mit Planen, fangen Sie erst einmal an zu arbeiten und planen einfach gegebenenfalls noch einmal nach. Der erste Teil, der "Was"-Teil. Was soll entstehen? Was entstehen soll, weiß der Product Owner. D.h., der erste Teil des Sprint Planning Meeting beginnt damit, dass der Product Owner sein Product Backlog öffnet und dem Team die Anforderungen einfach nach und nach detailliert erklärt. Das Team kann nachfragen, kann Klärungen herbeiführen und der Product Owner ist vor Ort, um Rede und Antwort zu stehen. Das Product Backlog ist die Basis des Ganzen. Nur da stehen die User Stories drin. Das Team schätzt für den Product Owner ab, wie umfangreich diese Funktionalität werden wird. Sie schätzt es in Story Points. Nicht in Stunden, nicht in Personentagen, sondern in einer abstrakten Einheit, die dem Product Owner und auch dem Team hilft, die Features gegeneinander abzuwägen. Nur das Team entscheidet in diesem ersten Teil, wie viel sie glauben bewältigen zu können im nächsten Sprint. Wenn sie sich festgelegt haben, wie viel zu schaffen ist, geben sie dem Product Owner eine Zusicherung (eine Garantie wäre zu hart ausgedrückt) ein Versprechen, dass sie alles daran setzen werden, diese zugesicherten Inhalte auch zu realisieren. In der Scrum Sprache heißt das "Commitment". Das wäre der Inhalt des ersten Teils. Danach wissen wir, was entstehen soll und wie groß die Teilmenge ist, die sich das Team herausgepickt hat. Nachdem Sie das wissen, gehen Sie in den "Wie"-Teil: Wie wollen wir es technisch umsetzen? Das Team nimmt die Features, die sie dem Product-Owner zugesichert haben, öffnen bzw. erstellen ihr Sprint Backlog und überlegen sich für jedes Feature die einzelnen Detail-Schritte: "Zwei Datenbank-Tabellen, eine Business-Logic-Komponente, drei Dialog-Seiten und einen Web-Service – und hier noch diese Vorbereitungsarbeit – und hier muss ich noch diese Test-Automatisierung machen." Diese Geschichten werden pro Feature festgelegt. Das läuft meistens so ab, dass der Scrum Master an seinem Notebook sitzt und das notiert und das Entwicklerteam miteinander technisch diskutiert, wie das zu realisieren ist und den Scrum Master dann beauftragt: "Nimm bitte dieses Arbeitspaket noch mit auf, nimm bitte diesen Task noch mit auf. Das muss erledigt werden". Das Team schätzt die Aufwände pro Arbeitspaket ab. Jetzt ist auch der Moment der Wahrheit, in dem das Team in Stunden abschätzt, nicht mehr in abstrakten Story Points, sondern: "Ich glaube, um das zu realisieren, brauche ich sechs Stunden". Jetzt kann man es auch in Stunden machen, weil die Pakete viel kleiner und greifbarer sind. Man spricht hier nicht mehr von Zeiträumen, die drei Monate groß sind, sondern von Häppchen, die maximal einen Tag groß sind. Das ist auch schon ein Tipp von mir: Arbeitspakete sollten nicht größer als einen Tag sein. Wenn sie größer sind, dann überlegen Sie, wie sie es noch herunterschneiden können und auf zwei aufteilen. Damit sinkt auch die Wahrscheinlichkeit, dass Sie sich komplett vergaloppieren für einen Task. Damit Sie wissen, wie lange Sie brauchen, müssen Sie wissen, wann ist etwas fertig. Scrum nennt das die "Definition of Done". Aber was heißt schon "fertig"? Der erste Impuls ist zu sagen: "Na ja, fertig ist es, wenn es fertig ist. Es ist doch klar, wann etwas fertig ist." Aber ist es wirklich so klar? Ist es wirklich klar für alle? Sind es wirklich gemeinsame Kriterien? Der eine Entwickler denkt, es ist fertig, wenn ich es bei mir lokal kompilieren kann. Für den zweiten Entwickler ist es fertig, wenn er nicht nur den Regelfall in der Software, im Fluss abgedeckt habe, sondern auch alle Fehlerbehandlungen. Der Dritte sagt: "Es darf nicht nur auf meinem normalen Notebook laufen, sondern muss auch auf unserem zentralen Bild-Server laufen. Der Vierte sagt, es muss auch getestet sein. Der erste sagt dann wieder: "Ach ja, getestet, hatte ich ganz vergessen." D.h.: Was fertig bedeutet, ist für zehn Leute zehnmal verschieden. Deshalb ist es wichtig, dass das Team gemeinsam überlegt, was für dieses Projekt, für dieses Team und nur für dieses Team die "Definition of Done" bedeutet. Es entsteht eine Art Checkliste, die einfach nur ein paar Punkte auflistet, die für die einen offensichtlich und für die anderen vielleicht neu sein mögen. Und anhand dieser "Definition of Done" werden alle Arbeitspakete durchleuchtet und mit einem geschätzten Aufwand versehen. Das waren die zwei Inhalte des Sprint Planning Meetings: der "Was"-Teil und der "Wie"-Teil. Und wir haben uns die "Definition of Done" angeschaut.

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!