Eines der fünf Ereignisse des Rahmenwerks Scrum ist das Sprint-Planning. Die Planung des nächsten Sprints beruht unter anderem auf der Selbsteinschätzung des Teams. Geht es nach der gleichnamigen Studie von Hattie, Bildungsforscher und Professor an der australischen „University of Melbourne“, ist die Selbsteinschätzung des eigenen Lernniveaus der stärkste Faktor für ein erfolgreiches Lernen. Das Rahmenwerk Scrum kann helfen, diese Selbsteinschätzung in den Lernalltag zu integrieren und damit zu guten Lernerfolgen beitragen.
Zielformulierung
Beim Sprint-Planning plant das Entwicklerteam (Schülerteam) gemeinsam mit dem Product Owner (Lehrer:in), welche Arbeitspakete im nächsten Sprint umgesetzt werden sollen. Der Product-Owner stellt zunächst das Ziel des nächsten Sprints vor. Die Zielformulierung hilft den Schüler:innen, eine bessere Vorstellung und Sinnhaftigkeit des angestrebten Teil-Ergebnisses(Produkt-Inkrement) zu haben.
(Beispiele: „Sämtliche Objekte, die für den Legefilm benötigt werden, liegen vor, so dass wir mit der Aufnahme des Legefilms beginnen können.“ oder „Die Fragen für das Interview mit dem Experten sind so formuliert, dass wir mit der Aufzeichnung des Interviews beginnen können.“)
Voraussetzung für die Planung ist ein vom Product Owner gepflegtes und priorisiertes Produkt Backlog, aus dem er die höchst priorisierten Anforderungen, die im nächsten Sprint realisiert werden sollen, zusammengefasst hat. Der Product Owner geht die von ihm ausgewählten Anforderungen detailliert mit dem Entwicklerteam durch. Die Schüler:innen können Fragen stellen, um so eine Vorstellung von der Machbarkeit der einzelnen Anforderungen zu bekommen.
Schätzen
Im nächsten Schritt schätzt das Entwicklerteam den jeweiligen Arbeitsaufwand der einzelnen Anforderungen. Sogar für Scrum-Erfahrene in der Arbeitswelt ist es sehr anspruchsvoll, den zeitlichen Aufwand, der notwendig ist, um die Anforderungen umzusetzen, genau zu schätzen. Daher schätzen die Schüler:innen den Aufwand der einzelnen Anforderungen zunächst in Relation zueinander. Das Schätzen kann mit ganz unterschiedlichen Methoden erfolgen. Die Vergabe von Story Points kann eine Möglichkeit sein.
Vergabe von Story Points
Das Entwicklerteam gibt jeder Anforderung eine Punktzahl, die den Arbeitsaufwand zur Realisation der Anforderung wiederspiegelt. Dabei ist nicht die absolute Zahl wichtig, sondern nur die Relation der Werte zueinander. Die Schüler:innen sollen schließlich nicht eine exakte Angabe (z.B. 1 Unterrichtsstunde) machen, sondern lediglich eine Größenordnung des Arbeitsumfangs schätzen. Erhält eine Anforderung den Wert 10, so ist der Arbeitsaufwand doppelt so groß wie der einer Anforderung, die mit 5 Story Points bewertet wird. Bevor die Story Points vergeben werden können, muss das Team sich fragen, was in die Einschätzung einfließen soll. Grundsätzlich zählt dazu alles, was benötigt wird, um die Anforderung auf „Done“, zu setzen. Dazu zählt beispielsweise der Umfang der zu erledigenden Arbeit, die Komplexität der Aufgaben und die Unsicherheiten bei der Erledigung der Aufgaben.
Das Schätzen des Arbeitsaufwands ist wichtig, um abschließend entscheiden zu können, welche Anforderungen tatsächlich im nächsten Sprint realisiert werden sollen. Die Summe der Story Points sollte daher beim Sprint Planning gut im Blick behalten werden, um zu erkennen, wann die maximal realisierbare Menge an Aufgaben für den nächsten Sprint erreicht ist. Im Laufe der Zeit lernen die Schüler:innen, sich immer besser einzuschätzen und vor allem lernen sie, einschätzen zu können, wie viele Story Points das Team insgesamt in einem Sprint bearbeiten kann. Dabei sollte die unterschiedliche Leistungsfähigkeit aller Teammitglieder berücksichtigt werden, so dass die Schüler:innen lernen, die unterschiedlichen Leistungsfähigkeiten aller Teammitglieder einzuschätzen und zu respektieren.
Committed Team
Ist das Schätzen abgeschlossen, legt das Entwicklerteam in Absprache mit dem Product Owner fest, welche der vorgeschlagenen Anforderungen tatsächlich in den Sprint Backlog übernommen werden sollen. Das Team übernimmt die Verantwortung, die Anforderungen bis zum Ende des Sprints zu realisieren und nicht nur ein halbfertiges Produkt abzuliefern (Committed Team). Insbesondere wegen der ausführlichen Besprechung der Anforderungen und des gemeinsamen Schätzens des Arbeitsaufwands ist diese Art Commitment für das Team möglich und auch wichtig. Es ist eine Art Selbstverpflichtung, die sowohl die einzelnen Schüler:innen als auch das gesamte Team motiviert.
Bildung von Tasks
In der letzten Phase des Sprint Plannings bespricht das Entwicklerteam die Anforderungen noch einmal kurz und zerlegt diese in einzelne Aufgaben (Tasks), die im Laufe des Sprints von den einzelnen Schülerinnen und Schülern des Teams bearbeitet werden können. Dabei kann jedes Teammitglied auch direkt signalisieren, welche Tasks es gern bearbeiten möchte.
Burn-Down-Chart
Während der Sprint-Phase kann die noch zu erledigende Arbeit in Relation zur verbleibenden Zeit in einem Burn-Down-Chart dargestellt werden. Auf der Y-Achse trägt das Team die gesamte Anzahl der vergebenen Story Points des Sprints ein. (z.B. 35 Punkte) Auf der X-Achse werden die in einer Unterrichtseinheit bearbeiteten Story Points abgetragen, es wird also der Zeitablauf dargestellt. Das Diagramm, in dem so fortlaufend der Arbeitsfortschritt dokumentiert und kommuniziert wird, unterstützt das Team in der Selbsteinschätzung und motoviert alle Beteiligten, selbstverpflichtend zu arbeiten.
Hattie wünscht sich eine Unterrichtsgestaltung mit den Augen der Lernenden. Lehrer:innen sollen das Lernen der Schüleri:nnen steuern und ihnen anspruchsvolle Ziele setzen. Lehrer :innen sollten wissen, wo die Schüler:innen stehen, welches Lernziel sie verfolgen und an welcher Stelle im Lernprozess sie geradestehen fordert Hattie.
Das Rahmenwerk Scrum kann dazu beitragen, diese Lernprozesse für alle Beteiligten zu unterstützen.