Projektentwicklung mit agilen Methoden ermöglichen

Agile Methoden sind im Lehrbetrieb oft schon Alltag, bevor du sie in der Schule kennenlernst. In diesem Modul verstehst du, warum Teams in Sprints arbeiten, wer im Scrum-Team welche Aufgabe hat und wie ein Product Backlog entsteht. Du schreibst eigene User Stories mit Akzeptanzkriterien, schätzt sie mit Story Points und pflegst ein Board in Jira, Azure Boards oder Trello. Am Ende kannst du in einem agilen Team mitarbeiten, die Meetings sinnvoll nutzen und erkennen, ob Scrum oder Kanban besser zu einer Aufgabe passt.

Das sind die Fähigkeiten, die am Ende des Moduls sitzen sollten. Jedes Ziel mit einem Beispiel aus dem Lehrbetrieb.

1. 1

   Agiles und planbasiertes Vorgehen unterscheiden und begründet wählen

   Kompetenz A

   Du verstehst, warum man bei unklaren oder sich ändernden Anforderungen lieber in kurzen Zyklen arbeitet und regelmässig Feedback holt. Du kennst die vier Werte des Agilen Manifests und kannst erklären, wann ein klassischer Plan trotzdem sinnvoller ist.

   Situation

   Die Marketingabteilung einer Krankenversicherung in Luzern möchte ein neues Online-Formular für Adressänderungen. Was genau abgefragt werden soll, ist noch unklar.

   Deine Aufgabe

   Begründe in fünf Sätzen, ob das Projekt agil oder klassisch umgesetzt werden soll.

   Gutes Ergebnis

   Empfehlung Scrum mit zweiwöchigen Sprints: Die Anforderungen sind unscharf, eine erste Version mit Name und Adresse kann nach zwei Wochen getestet werden, und die Fachabteilung gibt im Review direkt Rückmeldung. Fixe gesetzliche Pflichtfelder werden trotzdem vorab definiert.

   Agiles Manifestiterativ / inkrementellFeedbackzyklusWasserfallPlanbarkeit
2. 2

   Rollen, Events und Artefakte von Scrum erklären und anwenden

   Kompetenz B

   Du weisst, was Product Owner, Scrum Master und Developers tun und wer worüber entscheidet. Du kennst Sprint Planning, Daily Scrum, Sprint Review und Retrospektive mit Zweck und typischer Dauer, ebenso Product Backlog, Sprint Backlog und Inkrement.

   Situation

   Du kommst neu in ein Scrum-Team, das für einen Onlinehändler in Zürich den Bestellprozess überarbeitet. Im Daily erzählt jemand 15 Minuten lang über einen Fehler.

   Deine Aufgabe

   Erkläre, was im Daily schiefläuft, und schlage vor, wie das Team es besser machen kann.

   Gutes Ergebnis

   Das Daily dient der Abstimmung zum Sprintziel und ist auf 15 Minuten beschränkt. Detaildiskussionen werden notiert und direkt danach mit den betroffenen zwei Personen geklärt. Der Scrum Master achtet auf die Timebox.

   Product OwnerScrum MasterDevelopersSprintTimeboxInkrement
3. 3

   User Stories mit Akzeptanzkriterien formulieren

   Kompetenz C

   Du schreibst Anforderungen aus Sicht der Benutzerin: Wer will was und wozu. Mit Akzeptanzkriterien legst du fest, wann die Story erfüllt ist. Du prüfst Stories mit den INVEST-Kriterien und teilst zu grosse Stories auf.

   Situation

   Die HR-Abteilung eines Logistikunternehmens in Basel will, dass Mitarbeitende ihre Ferien online beantragen können.

   Deine Aufgabe

   Formuliere eine User Story mit drei Akzeptanzkriterien.

   Gutes Ergebnis

   'Als Mitarbeiterin möchte ich Ferien im Portal beantragen, damit ich kein Papierformular mehr ausfüllen muss.' Kriterien: Restferientage werden angezeigt. Der Antrag geht automatisch an die vorgesetzte Person. Bei Überschneidung mit einer Betriebssperre erscheint eine Warnung.

   User StoryAkzeptanzkriterienINVESTEpicStory Splitting
4. 4

   Ein Backlog priorisieren und den Aufwand gemeinsam schätzen

   Kompetenz D

   Du hilfst dem Product Owner, das Backlog nach Nutzen und Dringlichkeit zu ordnen, zum Beispiel mit MoSCoW. Im Team schätzt du den Aufwand relativ mit Story Points und Planning Poker und verstehst, wozu die Velocity dient.

   Situation

   Für die neue Kundenplattform einer Gemeindeverwaltung liegen 18 Stories im Backlog. Das Team schafft erfahrungsgemäss 20 Story Points pro Sprint.

   Deine Aufgabe

   Priorisiere die Stories mit MoSCoW und plane, was in den ersten Sprint passt.

   Gutes Ergebnis

   Sechs Must-Stories (Login, Formular Wohnsitzbestätigung, Bezahlung) mit total 19 Punkten kommen in Sprint 1. Should- und Could-Stories bleiben geordnet im Backlog. Die Planung wird im Sprint Planning mit dem Team bestätigt.

   MoSCoWStory PointsPlanning PokerVelocityBacklog Refinement
5. 5

   Ein Kanban-Board aufsetzen und den Arbeitsfluss steuern

   Kompetenz E

   Du baust ein Board mit sinnvollen Spalten, setzt WIP-Limits und erkennst Engpässe. Du weisst, dass Kanban ohne Sprints auskommt und sich besonders für laufende Anfragen wie Supportfälle oder Datenaufträge eignet.

   Situation

   Das Controlling-Team einer Kantonalbank bekommt laufend Auswertungswünsche per Mail. Niemand weiss, was in Arbeit ist.

   Deine Aufgabe

   Richte in MS Planner oder Trello ein Board ein und lege Regeln fest.

   Gutes Ergebnis

   Spalten 'Eingang', 'Geklärt', 'In Arbeit (max. 3)', 'Review', 'Geliefert'. Jede Anfrage wird eine Karte mit Auftraggeber und Termin. Nach zwei Wochen zeigt sich, dass Karten im Review hängen. Das Team plant fixe Review-Slots.

   Kanban-BoardWIP-LimitPull-PrinzipDurchlaufzeitEngpass
6. 6

   Qualität mit Definition of Done sichern und in der Retrospektive verbessern

   Kompetenz F

   Du verstehst die Definition of Done als gemeinsame Checkliste für 'fertig'. In der Retrospektive reflektierst du mit dem Team, was gut lief und was nicht, und leitest eine bis zwei konkrete Massnahmen ab.

   Situation

   Im Review zeigt sich zum zweiten Mal, dass eine Story zwar umgesetzt, aber nicht getestet und nicht dokumentiert ist.

   Deine Aufgabe

   Ergänze die Definition of Done und moderiere eine kurze Retrospektive mit dem Format 'Start, Stop, Continue'.

   Gutes Ergebnis

   DoD neu: Akzeptanzkriterien getestet, Kurzanleitung im Confluence- oder SharePoint-Wiki, Review durch zweite Person. Massnahme aus der Retro: Testfälle werden schon im Sprint Planning notiert.

   Definition of DoneRetrospektiveStart/Stop/Continuekontinuierliche Verbesserung

Die Kompetenzmatrix zerlegt das Modul in Themenstränge und drei Stufen. Für den Kompetenznachweis solltest du überall mindestens Stufe 2 erreichen. Dein Stand bleibt in diesem Browser gespeichert und färbt Lernweg und Übungen ein.

Noah ist im 1. Lehrjahr bei der Seeland Versicherungsdienst AG in Biel, 220 Mitarbeitende. Er wird einem Scrum-Team zugeteilt, das für das Kundenportal eine Online-Schadenmeldung entwickelt. Zuerst versteht er wenig vom Vokabular, nach einigen Sprints arbeitet er voll mit.

1. Kapitel 1

   Warum hier niemand ein Pflichtenheft schreibt

   Noah wundert sich, dass es für die Schadenmeldung kein dickes Pflichtenheft gibt. Die Product Ownerin erzählt ihm vom letzten Projekt: 60 Seiten Anforderungen, und nach neun Monaten wollten die Kundinnen plötzlich Fotos hochladen, was nirgends vorgesehen war. Noah stellt beide Vorgehen in einer Tabelle gegenüber und sieht, warum das Team bei unklaren Kundenwünschen lieber alle zwei Wochen etwas Lauffähiges zeigt.

   Ziel 1

2. Kapitel 2

   Zwei Wochen, ein Ziel

   Im Sprint Planning legt das Team das Sprint-Ziel fest: Eine Kundin kann einen Velodiebstahl vollständig online melden. Das Daily findet jeden Morgen um 9 Uhr in Teams statt und ist auf 15 Minuten begrenzt. Im dritten Daily diskutieren zwei Entwickler 25 Minuten über eine Datenbankfrage, und alle anderen warten. Der Scrum Master verschiebt die Diskussion in ein separates Gespräch, und Noah merkt, wofür die Timebox gut ist.

   Ziel 2

3. Kapitel 3

   Was genau heisst Fotos hochladen?

   Noah soll die Story für den Foto-Upload schreiben. Seine erste Version 'Fotos hochladen können' ist zu vage, also ergänzt er mit der Product Ownerin Akzeptanzkriterien: höchstens 5 Bilder, je maximal 10 MB, JPG oder PNG, klare Meldung bei zu grossen Dateien. Beim Planning Poker zeigt Noah eine 3, eine Entwicklerin eine 13, weil jedes Bild auf Viren geprüft werden muss. Das Team teilt die Story in Upload und Virenprüfung und schätzt beide neu.

   Ziel 3Ziel 4

4. Kapitel 4

   Der Stau in der Spalte Test

   Neben dem Scrum-Board betreut das Team ein Kanban-Board in Jira für Supportanfragen aus dem Kundendienst. Noah fällt auf, dass in der Spalte 'Test' neun Karten liegen, aber nur eine Testerin im Team ist. Das Team führt ein WIP-Limit von 3 ein, und Entwickler helfen beim Testen, sobald das Limit erreicht ist. Nach drei Wochen sinkt die Durchlaufzeit einer Anfrage von 8 auf 5 Arbeitstage.

   Ziel 5

5. Kapitel 5

   Fertig heisst wirklich fertig

   Im Sprint Review zeigt sich, dass der Foto-Upload am Handy nicht funktioniert, obwohl die Story als erledigt markiert war. In der Retrospektive mit Start, Stop, Continue schlägt Noah vor, 'auf iPhone und Android getestet' in die Definition of Done aufzunehmen. Im nächsten Sprint prüft er bei jeder Story, ob der Punkt erfüllt ist, und berichtet in der Retro: alle 6 Stories erfüllen die neue Regel, kein Handyfehler mehr im Review.

   Ziel 6Ziel 2

1. 1

   Warum agil?

   ca. 2 Std.

   Du lernst den Unterschied zwischen einem fixen Plan und kurzen Lieferzyklen kennen und verstehst, welches Problem agile Methoden lösen.

   • Die vier Werte des Agilen Manifests lesen und mit eigenen Beispielen aus dem Lehrbetrieb erklären
   • Zwei Projekte aus deinem Betrieb vergleichen: Was war planbar, was hat sich unterwegs geändert?
   • Das Papierflieger-Spiel in drei Runden durchführen und auswerten

   Trainiert Kompetenz A1

   Lernziel1

2. 2

   Scrum verstehen

   ca. 3 Std.

   Du lernst Rollen, Events und Artefakte kennen und kannst einen Sprint von Anfang bis Ende beschreiben.

   • Den Scrum-Ablauf als Skizze auf einer A4-Seite zeichnen
   • Im Lehrbetrieb fragen, ob und wie Scrum eingesetzt wird, und Unterschiede notieren
   • Ein Daily im Rollenspiel durchführen und die Timebox einhalten

   Trainiert Kompetenz B1

   Lernziel2

3. 3

   Anforderungen als User Stories

   ca. 3 Std.

   Du formulierst Stories, Akzeptanzkriterien und Epics für ein realistisches Vorhaben und teilst zu grosse Stories sinnvoll auf.

   • Für ein Ferienantrag-Portal zehn User Stories schreiben
   • Jede Story mit INVEST prüfen und mindestens eine Story aufteilen
   • Stories mit einer Kollegin tauschen und gegenseitig Feedback geben

   Trainiert Kompetenz C1C2

   Lernziel3

4. 4

   Priorisieren, schätzen, planen

   ca. 3 Std.

   Du ordnest ein Backlog, schätzt mit Planning Poker und planst einen Sprint auf Basis der Velocity.

   • Das Backlog aus dem vorherigen Schritt mit MoSCoW priorisieren
   • Planning Poker in einer Dreiergruppe spielen und Abweichungen diskutieren
   • Das Backlog in Jira, Azure Boards oder Trello erfassen

   Trainiert Kompetenz D1D2C3

   Lernziel43

5. 5

   Kanban und Arbeitsfluss

   ca. 2 Std.

   Du baust ein Kanban-Board für laufende Anfragen und lernst, mit WIP-Limits Engpässe sichtbar zu machen.

   • Ein Board in MS Planner oder Trello für deine eigenen Lehrbetriebsaufgaben einrichten
   • Eine Woche lang Karten bewegen und die Durchlaufzeit notieren
   • Scrum und Kanban in einer Tabelle gegenüberstellen

   Trainiert Kompetenz E1E2A2

   Lernziel51

6. 6

   Mini-Sprint durchspielen

   ca. 3 Std.

   Du erlebst einen kompletten Sprint im Kleinformat, inklusive Review und Retrospektive.

   • In einer Gruppe einen 90-Minuten-Sprint mit Planning, zwei Dailys, Review und Retro durchführen
   • Eine Definition of Done festlegen und im Review prüfen
   • Zwei Verbesserungsmassnahmen aus der Retro formulieren

   Trainiert Kompetenz B2F2F3D3

   Lernziel264

Sprint

Fixer Zeitraum von meist ein bis vier Wochen, in dem das Team ein nutzbares Ergebnis liefert.

Product Backlog

Geordnete Liste aller bekannten Anforderungen an das Produkt, gepflegt vom Product Owner.

Sprint Backlog

Auswahl an Backlog-Einträgen für den aktuellen Sprint plus Plan, wie das Team sie umsetzt.

Inkrement

Das nutzbare Ergebnis eines Sprints, das die Definition of Done erfüllt.

User Story

Kurze Beschreibung einer Anforderung aus Sicht einer Benutzerrolle mit Nutzen und Akzeptanzkriterien.

Velocity

Anzahl Story Points, die ein Team durchschnittlich pro Sprint fertigstellt.

WIP-Limit

Obergrenze für gleichzeitig laufende Arbeiten in einer Spalte eines Kanban-Boards.

Definition of Done

Gemeinsam vereinbarte Kriterien, die jede Story erfüllen muss, bevor sie als fertig gilt.

Passende Module