3.1  Arbeiten mit Lern-Storys

In Scrum wird der Begriff »Item« verwendet, was man gut mit »Element« übersetzen kann. In Scrum gibt es keine spezifische Technik für die Erstellung von Anforderungen. Wichtig ist nur, dass sie klein und handhabbar für das Team sind. In der Praxis haben sich User-Storys bewährt. Das Format der User-Story wird für das Lernen angepasst. Das Ergebnis ist die Lern-Story. Sie hat sich in der Praxis bewährt, um flexibel kleine Teile direkt in die Praxis umsetzen zu können. Der große Vorteil für Teams, die mit Scrum arbeiten, ist, dass diese Lern-Storys‌ wie alle anderen Storys behandelt werden können. Sie werden einfach alle vom Team in den Sprint gezogen und abgearbeitet. Auf diese Weise ist es möglich, in einem Sprint gleichzeitig am Produkt zu entwickeln und zu lernen. Das Lernen ist kein getrennter Prozess mehr, für den man Seminarräume oder Trainer benötigt. Es wird Teil des normalen Arbeitens. Dieser Schritt ist nicht nur für das Lernen von Scrum wichtig, sondern auch, nachdem Scrum bereits gelernt wurde. Das Team hat damit die Möglichkeit, das, was es lernen möchte, einfach zu lernen. Ganz selbstverständlich einfach im Sprint. Dazu ist es lediglich notwendig, eine Lern-Story zu schreiben und diese umzusetzen.

Zum Arbeiten mit Lern-Storys benötigt es die folgenden Rollen:

• Ein Coach‌ steuert den Lernprozess, indem er Fragen stellt. Möglicherweise hinterfragt er Lösungen. Er moderiert das Team hin zu Ergebnissen und gibt Feedback. Dieser Coach ist im Scrum-Team der Scrum-Master.

• Das Team‌ ist in Scrum auch einfach zu identifizieren. Es ist das Development-Team und der Product-Owner. Der Product-Owner hat für die folgenden Lern-Storys keine besondere Rolle. Er ist Teil des Teams.

• Der Input-Geber‌ ist jemand, der den Input für die Lern-Story vorbereitet hat. Er vermittelt den initialen Input an das Team. Jeder im Team kann zum Input-Geber für einzelne Themen werden. Auch mehrere Input-Geber gleichzeitig sind denkbar. Diese Rolle wird nur ganz am Anfang eines Lern-Sprints benötigt. Wenn das Team den Input verstanden hat, wird diese Rolle nicht mehr benötigt. Es ist auch denkbar, dass der Scrum-Master am Anfang Input-Geber ist und dann moderiert. Der Übergang sollte dann transparent gemacht werden. Ein Wechsel in der Input-Geber-Rolle ist für alle Beteiligen hilfreich. Es fördert die Lebendigkeit im Lernen. Oft lernt der Input-Geber selbst am meisten durch die Vorbereitung und durch die Fragen aus dem Team. Lehren ist eine gute Form, eigenes Wissen zu vertiefen.

Der Lern-Sprint‌ beginnt mit dem Input des Input-Gebers. Dieser präsentiert das Thema der Lern-Story. In der Lern-Story ist das Thema durch den Input beschrieben. Dieser Teil der Story beschreibt, was vom Team zum Erstellen des Outputs benötigt wird. Das Team stellt Fragen und reflektiert das Thema. Für diesen ersten Input-Teil und die Diskussionen sind Timeboxen hilfreich. Dieser erste Teil ist theoretisch und hat selbst nur wenig Mehrwert für die Umsetzung. In der Praxis haben sich eine halbe Stunde für den Input und eine halbe Stunde für die Reflexion bewährt. Dies berücksichtigt die Aufmerksamkeitsspanne des Teams. Diese Timebox ist besonders für den Input-Geber eine große Herausforderung. Er darf nicht lange um das Thema herumreden; er muss zum Punkt kommen. Der Fokus aller Beteiligten auf das Verstehen ist in dieser ersten Phase wichtig.

Danach beginnt die gemeinsame Arbeit am Output. Dieser wird in der Lern-Story durch die Sektion Output definiert. An dieser Stelle findet der Übergang vom Wissen zum Handeln statt. Das Team lernt, das Wissen anzuwenden. Gemeinsam wird zum Beispiel eine Definition of Done erstellt. Das ist ein konkretes Produkt, das für Scrum benötigt wird. Diese Phase des Lernens hat kreative Anteile.

Danach beginnt die Reflexion des Lernens und des Ergebnisses. Was haben wir gelernt? Was haben wir möglicherweise nicht gelernt? Wie gut ist das Ergebnis? Was brauchen wir möglicherweise alles noch? Wie sind wir miteinander umgegangen? Haben wir es geschafft, unsere »Definition of Fun« umzusetzen? Was hat im Team noch gefehlt? Wie war die Energie im Team? Mit solchen Fragen regt der Coach die gemeinsame Reflexion an.

Als Ergebnis der Reflexion kann sich herausstellen, dass es noch ganz bestimmte Ergebnisse oder Themen gibt, die das Team auch noch braucht. Dann wird das Lern-Backlog um diese Themen erweitert. Sehr spannend ist immer die Frage nach der Priorisierung. In der Praxis hat es sich gezeigt, dass es hilfreich ist, der Energie des Teams zu folgen und direkt bei diesen Themen weiterzumachen. Das Team hat dann das Gefühl, selbst Kontrolle über den Prozess zu haben und tatsächlich an seinen Themen zu arbeiten. Dabei ist jedoch realistisch abzuwägen, ob direkt der nächste Input durch einen Input-Geber möglich ist und ob eventuell andere Lern-Storys im Lern-Backlog wichtiger sind. Hier moderiert der Coach das Team zu einer Entscheidung.

Alle Lern-Storys haben die oben beschriebene Struktur:

• Die Überschrift ist für das schnelle Auffinden im Backlog notwendig.

• Das Ziel gibt an, weshalb es sinnvoll ist, diese Story zu lernen und was anschließend verbessert werden soll. Das Lernen bekommt hier eine Ausrichtung.

• Der Input‌ ist besonders wichtig für den Input-Geber. Das sind die Elemente, die ihm bei der Vorbereitung des Inputs helfen sollen. Hier wird der Umfang definiert.

• Der Output‌ beschreibt, was das Team gemeinsam erstellen soll. Hier wird der Input angewendet. Der Output muss so gewählt werden, dass es möglich ist, ihn in einem Sprint fertigzustellen.

• Die »Definition of Fun‌« soll zeigen, wie das Team gemeinsam Spaß am Lernen haben kann. Eine »Definition of Fun« kann für alle Lern-Storys identisch sein. Möglicherweise ergeben sich für bestimmte Lern-Storys jedoch spezielle Möglichkeiten. Diese werden dann hier beschrieben.

• Wenn das Team alle Storys im Sprint mit Story-Punkten schätzt, bekommt die Lern-Story selbstverständlich auch Story-Points. Wie das genau geht, folgt später im Lern-Backlog.

Nach der Erklärung der Lern-Story kommt die umzusetzende Lern-Story für dieses Kapitel. Das Ziel ist es, den Rahmen für das Lernen von Scrum gemeinsam im Team zu planen. Der Rahmen für das Lernen muss geklärt werden. Dazu gehören Antworten auf die Fragen: Wie viel Zeit darf das Team für das gemeinsame Lernen verwenden? Wann beginnt der erste Sprint? Wann endet er? In vielen Unternehmen wird an dieser Stelle die Freigabe durch eine Führungskraft benötigt. Diese ist einzuholen, und auch die Abstimmung mit wichtigen Stakeholdern ist hilfreich, um die Erwartungen an das Team zu klären.

Wenn diese grundsätzlichen Fragen geklärt sind, hilft es allen Beteiligten, möglichst frühzeitig festzulegen, wer dem Team welchen Input präsentiert. Möglicherweise gibt es Vorerfahrung oder starke Präferenzen im Team. Für die Themen, für die sich kein Freiwilliger findet, sollte wohl der Scrum-Master die Vorbereitung übernehmen. Üblicherweise hat er eine Zertifizierung und dadurch einen Wissensvorsprung.

Die Definition of Fun beschreibt, wie das Team gemeinsam Spaß am Lernen haben möchte. Jedes Team hat hier andere Vorstellungen und Bedürfnisse. Das Ziel ist es, über die persönlichen Bedürfnisse zu sprechen, um eine gemeinsame Idee für gute Zusammenarbeit beim Lernen zu entwickeln. Spaß beim Lernen ist nicht nur einfach angenehm. Menschen können besser und nachhaltiger lernen, wenn sie positiv gestimmt sind. Die Emotion wird gemeinsam mit dem Inhalt zusammen im Gehirn abgespeichert. Wenn man sich wieder erinnert, tauchen neben dem Inhalt auch einige Emotionen beim Lernen mit auf.

Die Dauer des Sprints gibt in Scrum den Rhythmus für alles Weitere vor. Dieser muss vom Team definiert werden. Die Empfehlung ist ein bis vier Wochen. Längere Sprints sind nicht sinnvoll. Eine Woche stellt eine große Herausforderung für alle Prozesse dar und ist deshalb kein guter Anfangspunkt. Die Empfehlung für den Anfang wäre zwei Wochen. Auf diese Dauer ist auch die Menge der Lern-Storys ausgelegt. Grundsätzlich ist der kürzestmögliche Sprint der beste für den Scrum-Prozess. Auf diese Weise kann kontinuierlich neue Software an den Kunden übergeben werden. Neue Anforderungen und Ideen haben weniger Wartezeit bis zur Umsetzung....