Aufgabe 02 - Vom Wunsch zur Story

Lernziele

• Du formulierst Anforderungen als User Stories mit Rolle, Wunsch und Nutzen und trennst Stories von technischen Tasks.
• Du schreibst Akzeptanzkriterien, die konkret genug für einen Testfall sind.
• Du zerlegst zu große Stories entlang des Nutzens und ordnest ein Backlog begründet.

Ausgangslage

Aus schwammigen Wünschen prüfbare Anforderungen zu machen ist die wichtigste Übersetzungsarbeit agiler Entwicklung. Du extrahierst User Stories aus einem chaotischen Kundeninterview, versiehst sie mit testbaren Akzeptanzkriterien, prüfst sie an INVEST und ordnest sie zu einem Backlog - dem Handwerk, das ab dem Jahresprojekt dein Alltag ist (siehe Kapitel 4, Agiles Arbeiten I – User Stories und Backlog).

Was du dafür brauchst:

• Kapitel 4 (Agiles Arbeiten I – User Stories und Backlog: User Stories, Akzeptanzkriterien, INVEST, Backlog, MoSCoW).
• Das Kundeninterview (Datei customer-interview.txt, unten abgedruckt): eine Seite wörtliches Protokoll, in dem ein Schulsprecher durcheinander eine App für die Schülervertretung beschreibt (Umfragen, schwarzes Brett, Fundbüro, “und irgendwas mit Push-Nachrichten wäre cool”).
• Ihr arbeitet in Zweierteams; ab Wesentlich_vollständig braucht ihr ein Nachbarteam für den Kreuztest.

customer-interview.txt

KUNDENINTERVIEW - Schülervertretungs-App (Arbeitstitel "SchoolBoard")
Protokoll, wörtlich mitgeschrieben, nicht geordnet. Alle Angaben sind frei erfunden.

Gespräch: Schulsprecher (Kunde) und Entwicklungsteam, Pausenraum, 25 Minuten

Team: Erzählen Sie uns bitte, was Sie sich vorstellen.

Schulsprecher: Also, es geht darum, dass die Schülervertretung endlich alle erreicht. Wir hängen was aus, und am nächsten Tag ist der Zettel weg oder verdeckt oder keiner liest ihn. Heuer hat die Hälfte den Termin vom Schulball verpasst. Wir brauchen irgendwas, wo wir was reinschreiben und jeder sieht es. Wie ein schwarzes Brett, nur halt am Handy.

Team: Wer darf dort etwas veröffentlichen?

Schulsprecher: Nur wir, die Schülervertretung. Sonst steht da am Ende Blödsinn drin. Die Schüler sollen es nur lesen. Das Neueste soll oben stehen, logisch. Und der Titel soll nicht ewig lang sein, sonst sieht man ihn nicht.

Schulsprecher: Das Wichtigste, ehrlich gesagt, sind aber Umfragen. Wir wollen wissen, was die Leute meinen. Zum Beispiel, ob der Ball im Jänner oder im Feber sein soll. Bisher sammeln wir Zettel ein, das ist eine Katastrophe, und ausgezählt wird dann irgendwie am Abend vor der Sitzung. Wir stellen eine Frage und ein paar Antworten zum Auswählen, die Leute klicken, fertig.

Team: Soll man sehen, wer wie geantwortet hat?

Schulsprecher: Nein, auf keinen Fall. Anonym. Sonst sagt ja keiner was Ehrliches, vor allem, wenn es um Lehrer geht. Aber jeder soll nur einmal abstimmen dürfen, sonst klicken die aus der Ersten fünfzigmal. Und irgendwann ist Schluss, bis Freitag oder so. Danach soll man nicht mehr mitmachen können. Und für die Sitzung bräuchten wir, wie viele was gewählt haben, und wie viel Prozent das sind. Ein schönes Diagramm wäre auch super.

Schulsprecher: Ach ja, und das Fundbüro. Das Sekretariat ist total genervt, weil dauernd jemand fragt, ob irgendwo eine Jacke liegt. Wer was findet, soll das melden können, mit einer Beschreibung und wo man es gefunden hat. Ein Foto, wenn jemand mag. Und wer was verloren hat, soll nachschauen können, ohne ins Sekretariat zu rennen. Am besten mit Suche.

Team: Gibt es noch andere Gruppen, die die App nutzen sollen?

Schulsprecher: Die Lehrer vielleicht. Die schreiben nämlich dauernd Schularbeiten genau auf den Tag, an dem wir was machen, zum Beispiel den Sporttag. Wenn die unsere Termine sehen könnten, müssten wir nicht jedes Mal hinterherlaufen. Mehr wollen die glaub ich nicht, nur schauen.

Schulsprecher: Und irgendwas mit Push-Nachrichten wäre cool. Dass man halt was mitkriegt. Ich hab das bei anderen Apps gesehen, das ist super.

Schulsprecher: Mein Cousin hat gesagt, wir sollen das unbedingt mit React machen und eine Cloud nehmen, das macht man jetzt so. Und am besten mit KI, das haben ja jetzt alle.

Team: Was soll die KI machen?

Schulsprecher: Na, halt KI. Dass es smart ist. Und es soll modern aussehen, nicht so wie die Schulhomepage.

Schulsprecher: Ach so, und den Kaffeeautomaten im ersten Stock sollte auch jemand reparieren, der schluckt immer das Geld. Aber das ist wohl nicht euer Thema. Wann wäre denn die erste Version fertig? Heuer noch?

Ende des Protokolls.

Das Protokoll ist bewusst ungeordnet, wie ein echtes Gespräch: Nicht jeder Satz ist ein Wunsch, und nicht jeder Wunsch ist schon eine Story.

Allgemein

Projektordner anlegen siehe https://qiz.at/projektordner

• Lies vorher kurz https://qiz.at/assignmentsabgabe durch.
• Nur vollständige Abgaben (siehe https://qiz.at/rules) können positiv bewertet werden.
• Abgabe- und Testdetails siehe https://qiz.at/assignmentsabgabe
• Abgegeben wird ein Textdokument (z. B. README.md im Projektordner) mit allen Ergebnissen der bearbeiteten Stufen: Backlog mit allen Stories, Akzeptanzkriterien der drei gewählten Stories samt Kreuztest-Notizen, Story-Schnitt und - wenn bearbeitet - INVEST-Überarbeitung sowie MoSCoW-Einordnung mit dem begründeten Nein.

Wesentlich_überwiegend

Aufgabe

• Markiere im Interview alle Wünsche und formuliere daraus mindestens acht User Stories im Format “Als [Rolle] möchte ich [Wunsch], damit [Nutzen]”. Achte auf die Rollen: Schüler, Schülervertretung und Lehrkraft wollen Verschiedenes.
• Beantworte in zwei bis drei Sätzen: Welcher der drei Teile einer User Story (Rolle, Wunsch, Nutzen) wird am häufigsten weggelassen, und warum ist gerade er der wertvollste?
• Mindestens ein Wunsch ist keine Story, sondern eine technische Vorliebe oder zu vage (“mit KI!”). Identifiziere ihn und formuliere die Rückfrage, die du dem Schulsprecher stellen würdest.
• Wähle drei Stories und schreibe je drei bis fünf Akzeptanzkriterien, so konkret, dass ein Test daraus werden könnte (Given-When-Then oder Checkliste); benenne zu jeder Story mindestens einen Randfall.
• Erkläre in zwei bis drei Sätzen: Was unterscheidet eine Akzeptanzkriterien-Liste von einer Story, und warum ist sie ein Vertrag?

Tipp: Ein Randfall ist z. B. eine leere Eingabe, ein Grenzwert, eine Wiederholung oder eine fehlende Berechtigung. Jedes Kriterium muss entweder wahr oder falsch sein - „übersichtlich“ oder „schnell“ lässt sich nicht prüfen.

Bewertungskriterien

Vollständig, wenn:

• mindestens acht Stories mit Rolle, Wunsch und echtem Nutzen vorliegen, mehrere Rollen vorkommen und keine technischen Tasks als Stories getarnt sind,
• der vage Wunsch erkannt und mit einer gezielten Rückfrage statt als Story behandelt ist,
• drei Stories je drei bis fünf prüfbare Akzeptanzkriterien und je mindestens einen benannten Randfall haben,
• die beiden Fragen fachlich korrekt beantwortet sind.

Abgabe

Wie unter Allgemein.

Wesentlich_vollständig

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

• Tauscht mit dem Nachbarteam: Kann es aus euren Kriterien einen Testfall ableiten, ohne nachzufragen? Notiere jede Stelle, an der es nachfragen musste - das ist eine Lücke im Kriterium. Schließe die Lücken im Kriterium selbst.
• Eine deiner Stories ist zu groß (vermutlich die Umfrage-Funktion). Zerlege sie entlang des Nutzens in zwei bis drei einzeln lieferbare Stories - nicht entlang der Technik (“Backend”/“Frontend”). Begründe in einem Satz, warum man entlang des Nutzens und nicht entlang der Technik schneidet.
• Ordne das gesamte Backlog aus Sicht des Schulsprechers und begründe deine Top 3 mit der Frage “Was ist das kleinste Produkt, das schon nützt?”.

Tipp: Beim Kreuztest arbeitet das Nachbarteam nur mit euren Kriterien, nicht mit dem Interview. Ein geordnetes Backlog hat einen ersten, zweiten und dritten Platz, nicht drei Mal „hoch“.

Bewertungskriterien

Vollständig, wenn:

• die Rückfragen des Nachbarteams notiert und als Ergänzung in die Kriterien eingearbeitet sind,
• die große Story in zwei bis drei einzeln vorführbare Stories entlang des Nutzens zerlegt ist (keine Aufteilung nach Schichten) und die Begründung stimmt,
• das Backlog eine echte Rangfolge hat und die Top 3 über den Nutzen für den Kunden begründet sind.

Abgabe

Wie unter Allgemein.

PlusPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

• Nenne die sechs Kriterien hinter den Buchstaben von INVEST und begründe, welche zwei im Schulprojekt am häufigsten verletzt werden.
• Prüfe deine drei wichtigsten Stories gegen alle sechs INVEST-Kriterien und behebe jeden Verstoß. Dokumentiere eine Story vorher/nachher.

Tipp: Sieh dir jedes der sechs Kriterien einzeln an, nicht nur die zwei, die dir zuerst einfallen. Eine Story, die sechs Mal „ja“ bekommt, lohnt sich zu hinterfragen.

Bewertungskriterien

Vollständig, wenn:

• die sechs INVEST-Kriterien korrekt benannt und die zwei häufigsten Verstöße begründet sind,
• alle sechs Kriterien an drei Stories geprüft sind,
• mindestens eine Story ein nachvollziehbares Vorher/Nachher hat, in dem jeder benannte Verstoß behoben ist.

Abgabe

Wie unter Allgemein.

MandalorianPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

• Lege das Minimum Viable Product fest: die kleinste Auswahl aus deinem Backlog, die für sich benutzbar ist und einen echten Nutzen liefert. Begründe, warum genau diese Stories und keine weniger.
• Ordne das gesamte Backlog nach MoSCoW ein und fülle ausdrücklich die Kategorie Won’t have (this time) mit mindestens zwei Wünschen - jeweils mit dem Satz, den du dem Schulsprecher sagst, um das Nein zu begründen, ohne ihn zu verlieren.
• Begründe in zwei bis drei Sätzen, warum die MoSCoW-Kategorie Won’t have die wichtigste ist.

Tipp: Ein gutes Nein nimmt den Wunsch ernst, nennt den Grund („nicht jetzt, weil …“) und bietet eine Bedingung oder einen Termin für den späteren Wiedereinstieg.

Bewertungskriterien

Vollständig, wenn:

• das MVP die kleinste benutzbare Menge ist und begründet ist, warum weniger nicht reicht,
• Won’t have mindestens zwei Wünsche enthält, je mit einem Satz, der Wunsch, Grund und Wiedereinstieg enthält,
• die Bedeutung von Won’t have nachvollziehbar begründet ist.

Abgabe

Wie unter Allgemein.

Zeit dafür

Durchschnittlich bis Wesentlich_vollständig: ca. 70 min

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules