How 2 Backlog in der Bildung

Lesedauer ca. 4 Minuten

Wenn ihr Scrum im Unterricht einsetzt, dann erhalten die Lernenden von euch die Aufgabe, die es zu erledigen gilt: das Product Backlog. In vielen Fortbildungen und Sessions bei Barcamps, in denen ich den Einsatz von Scrum im Unterricht vorgestellt habe, kommt sehr häufig die Frage nach der Formulierung des Backlogs. Dieser Beitrag soll helfen ein Backlog erstellen zu können. 

Doch von Vorne 👉 Was ist überhaupt ein Product Backlog?

Das Product Backlog ist eine Liste noch nicht erledigter Aufgaben, welche das Lernprodukt und für die Erstellung relevante Informationen (Akzeptanzkriterien, Abgabetermine, Formatvorgaben, Produktziel..) beinhaltet. Es enthält alle Anforderungen an das Produkt.

Im Product Backlog ist das Produktziel/der Lerngegenstand genau formuliert. Es steht also drin, was am Ende produziert sein soll. Es werden ebenso die Erwartungen an das Produkt formuliert, genau so, wie es Auftraggeber:innen in der freien Wirtschaft in Auftrag geben würden.

Im Product Backlog finden die Scrum-Teams finden sich verschiedene Einträge, die sogenannten Product Backlog Items.  neben den Akzeptanzkriterien, welche an das Produkt angelegt werden (z.B. durchgehende Rechtschreibung), können das auch die User Storys sein. In den User Storys sind Erwartungen an das Produkt aus Sicht verschiedener User:innen beschrieben. Sie geben Informationen zu den Erwartungen der Auftraggeber:innen an das Lernprodukt. 

Der Aufbau des Product Backlogs beinhaltet also unter Anderem

  • Die Formulierung des Produkts
  • Konkrete Akzeptanzkriterien
  • Informierende User Stories 
  • Qualitätsanforderungen und mögliche funktionale Anforderungen

Das geforderte Produkt leitet sich aus dem Bildungsplan und dem jeweiligen Fachinhalt ab. In jedem Fach kann ein Produkt definiert werden. Ein paar mögliche Beispiele:

  • Erstellt eine Geschichte auf französisch mit der Software twinery.org (Französisch)
  • Produziert einen Popup-Aufsteller für eine Ausstellung (Geschichte)
  • Produziert einen Podcast zur Satz des Pythagoras (Mathematik)
  • Produziert ein In-Game-Video zur Geschichte „Ring des Gyges“ (Ethik)
  • Stellt ein Ebook zum Thema Elektronik her (Technik)
  • Entwickelt eine Veranstaltung „Einführung in WhatsApp“ für Senioren (AES)…

Jetzt ist klar, dass den Lernenden durchaus ein paar Informationen fehlen. Deswegen stehen im Product Backlog noch mehr Informationen zur Verfügung.

Schauen wir uns das an der Beispielaufgabe, die man im Kopf haben könnte, mal etwas genauer an. Meine Gedanke wäre: „Erstellt eine Geschichte auf französisch mit der Software twinery.org“. Dann könnte ich folgende Akzeptanzkriterien definieren:

1. Die Geschichte handelt von der Situation einer Wohnungsbesichtigung (Siehe Seiten XY im Buch).

2. Es kommen mindestens vier Personen vor.

3. Verwendet in der Geschichte die Grammatik von Seite XY.

Es liegt an dir und deiner Zielgruppe, wieviel Informationen du deinen Lernenden zur Verfügung stellst. Je mehr Akzeptanzkriterien und User Storys, desto mehr Informationen, aber auch ein desto engerer Rahmen für die freie selbstbestimmte Arbeit der Scrum Teams. Das ist der Regler, mit dem du arbeiten kannst – ganz abhängig von deiner Zielgruppe und den Bedingungen, die individuell sind und daher nur von dir angemessen berücksichtigt werden können.

Was genau eine User Story ist und wie du eine verfasst, das erkläre ich dir hier.

Jetzt verfeinere ich in einem weiteren Schritt meine Arbeitsaufgabe/mein Product Backlog. Ich konkretisiere den Lerngegenstand, das Ziel. Ebenso füge ich eine User Story hinzu. Dann könnte das Beispiel-Backlog wie folgt aussehen:

Produkt: Eine interaktive Geschichte

1. Die Geschichte ist auf französisch verfasst. 
2. Es wird die Software www.twinery.org verwendet.
3. Die Geschichte handelt von der Situation einer Wohnungsbesichtigung (Siehe Seiten XY im Buch).
4. Es kommen mindestens vier Personen vor.
5. Beachtet in der Geschichte die Grammatik von Seite XY.

User Story
Als Leser:in/Lehrer:in wünsche ich mir durchgehende Rechtschreibung um flüssig lesen zu können, damit ich mich ganz auf die Geschichte konzentrieren kann.

Ein Product Backlog ist nicht schwer zu schreiben, du musst dich nur etwas eindenken. Du musst eine konkrete Idee von dem Produkt haben, welches du haben möchtest. Das Produkt sollte das Ziel sein, welches es den Lernenden ermöglicht, auf dem Weg dorthin die inhaltlichen Kompetenzen zu erwerben, anzuwenden und im Prozess quasi nebenbei zu überprüfen. Die 6C‘s sind natürlich gedanklich immer an Bord. 

Alle weiteren Informationen, die du beim Einsatz von Scrum geben solltest, müssen nicht im Backlog stehen. Selbstverständlich hast du deinen Lernenden schon einen Überblick über das gesamte Rahmenwerk (framework) Scrum gegeben. Dazu kannst du unter Anderem diese Scrum-Karten verwenden, die du bei der Hopp-Foundation kostenlos bestellen kannst. 

Und bitte denk daran 👉 Der Abgabetermin ist selbstverständlich wichtig, ebenso die Bewertungskritieren. Transparenz ist ein agiler Wert! 

Ich habe im Zuge dieses Blogartikels viele Diskussionen geführt mit engagierten Fachkolleg:innen. Daher will ich an dieser Stelle nochmals darauf hinweisen: im Scrum-Guide steht relativ wenig zum Product Backlog. Unter Anderem steht dort: "Das Produktziel beschreibt einen zukünftigen Zustand des Produkts, der dem Scrum-Team als Zielvorgabe für die Planung dienen kann. Das Produktziel befindet sich im Product Backlog. Der Rest des Product Backlogs entsteht, um zu definieren, "was" das Product Goal erfüllen wird.". Der offizielle Scrum Guide führt weder Form noch Inhalt des Product Backlog im Detail aus. 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

3 + 3 =