Übungsaufgaben zu User Stories

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „User Stories“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/user-stories
- Stilbeispiel: https://oer-informatik.de/user-stories-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- User Stories
- INVEST
- Akzeptanzkriterien
- Product Backlog
- Product Owner
- Scrum
- Epic
- Anwendungsfalldiagramm

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

• Entwerfen darf jede*r Beteiligte, zum Beispiel Entwickler*innen, Auszubildende, Kolleg*innen aus Vertrieb und Buchhaltung oder die Pilothändler*innen. (1 Punkt; eine Nennung genügt)

• Über die Aufnahme ins Backlog und die Reihenfolge entscheidet der Product Owner, hier Sophie Bertram. (1 Punkt)

Eine User Story besteht aus einem Satz mit drei Teilen (je 1 Punkt, Beispiel kann in die Erläuterung eingebaut sein):

• Rolle („Als …“): Zuerst wird die Nutzergruppe genannt, aus deren Sicht die Anforderung beschrieben wird, z. B. „Als Fachhändlerin …“.

• Funktion („möchte ich …“): Dann folgt, was diese Person mit dem System tun oder erreichen möchte, z. B. „… möchte ich den Lieferstatus meiner Bestellungen sehen, …“.

• Nutzen („damit …“): Zum Schluss steht, welchen Mehrwert oder welches Ziel die Person damit erreicht, z. B. „… damit ich meiner Kundschaft einen verlässlichen Abholtermin nennen kann.“

Je Kriterium 2 Punkte (1 Punkt Bedeutung, 1 Punkt Erläuterung bzw. Beispiel):

• Negotiable (verhandelbar): Eine Story ist kein fest vereinbarter Vertrag. Die Details (z. B. wie genau die Lieferstatus-Anzeige aussieht) werden im Gespräch zwischen Product Owner, Team und Händler*innen geklärt und dürfen sich bis zur Umsetzung ändern.

• Estimable (schätzbar): Das Team muss den Aufwand der Story abschätzen können. Dazu muss sie verständlich und konkret genug sein; ist sie zu vage oder zu groß, muss sie zuerst geklärt oder geteilt werden.

• Testable (testbar): Es muss eindeutig überprüfbar sein, ob die Story erfüllt ist. Das gelingt über Akzeptanzkriterien, aus denen sich Testfälle ableiten lassen; vage Wörter wie „schnell“ oder „einfach“ sind nicht testbar.

Zum Beispiel:

• Artikel bestellen: „Als Fachhändler*in möchte ich Artikel im Händlerportal bestellen, damit ich mein Geschäft rechtzeitig mit Ware versorgen kann. Dabei werden immer meine Händlerkonditionen angewendet. Falls ich ein Schloss passend zu einer vorhandenen Schließanlage bestelle, möchte ich den Schließungscode angeben, damit das neue Schloss mit den vorhandenen Schlüsseln geöffnet werden kann.“

• Retoure anmelden: „Als Fachhändler*in möchte ich eine Retoure im Portal anmelden, damit ich defekte oder falsch gelieferte Ware ohne Telefonate zurückschicken kann. Dabei erhalte ich immer ein Rücksendeetikett zum Ausdrucken.“

Punkteverteilung: je Story 1 Punkt für Rolle und Funktion, 1 Punkt für einen sinnvollen Nutzen (nicht nur „damit es funktioniert“), 1 Punkt für die korrekt eingearbeitete Beziehung. Bei „Artikel bestellen“ muss das «include» (Konditionen immer) und das «extend» (Schließungscode nur unter der Bedingung) erkennbar sein; fehlt eines davon, gibt es den Punkt nicht. Die Erweiterung darf auch als eigene, zweite Story formuliert werden.

Je Story 3 Punkte: 1 Punkt für den erkannten Mangel, 1 Punkt für die Begründung, 1 Punkt für eine verbesserte Story.

1. Mangel: Als Rolle steht „das System“, nicht eine Nutzergruppe; der Nutzen fehlt, und beschrieben ist eine technische Lösung (nächtlicher Import aus einer Tabellenkalkulation). Damit ist nicht erkennbar, wem die Story nützt (Valuable), und die Regel „aus Sicht der nutzenden Person“ ist verletzt. Besser: „Als Fachhändler*in möchte ich im Portal immer meine aktuell gültigen Konditionen sehen, damit ich meine Verkaufspreise verlässlich kalkulieren kann.“ (Wie die Daten ins Portal kommen, klärt das Team im Refinement.)

2. Mangel: Die Story enthält vier Funktionen und ist viel zu groß für einen Sprint (Small), damit auch kaum schätzbar (Estimable). Sie ist ein Epic und muss geteilt werden. Besser: in einzelne, voneinander unabhängige Stories schneiden (Independent), z. B. „Als Fachhändlerin möchte ich meine Rechnungen als Datei herunterladen, damit ich sie in meine Buchhaltung übernehmen kann.“ – weitere Stories für Bestellen, Retouren und die Umsatzauswertung.

3. Mangel: „schnell“ und „zufrieden“ sind nicht messbar, die Story ist nicht Testable; außerdem beschreibt sie eine nichtfunktionale Anforderung ohne konkrete Funktion und einen leeren Nutzen. Besser: an eine Funktion binden und messbar machen, z. B. „Als Fachhändler möchte ich in der Artikelsuche schnell Treffer erhalten, damit ich auch während eines Kundengesprächs nachsehen kann, ob ein Teil lieferbar ist.“ mit dem Akzeptanzkriterium „Die Trefferliste erscheint bei 95 % der Suchanfragen in höchstens 2 Sekunden.“ Alternativ als übergreifende Vorgabe in die Definition of Done aufnehmen.

Je Kriterium 2 Punkte (1 Punkt vollständiges Format mit Ausgangslage, Aktion und Ergebnis, 1 Punkt prüfbarer, passender Inhalt). Zum Beispiel:

Je Aussage 1 Punkt (richtiges Urteil mit stimmiger Begründung bzw. Berichtigung):

1. Nicht zutreffend. Das Product Backlog ist eine dynamische Liste und nie „fertig“: Neue Wünsche kommen jederzeit hinzu, überholte Stories werden gestrichen, und die Reihenfolge wird angepasst. Geplant wird jeweils nur der nächste Sprint.

2. Zutreffend. Oben stehen kleine, verstandene und geschätzte Stories; aus ihnen wählt das Team im Sprint Planning die Arbeit für den nächsten Sprint. Weiter unten dürfen Einträge noch grob sein, etwa Epics.

3. Nicht zutreffend. Wünsche einbringen darf jede*r Beteiligte, die Reihenfolge legt aber allein der Product Owner fest, hier Sophie Bertram. Frau Nowak kann ihr den Nutzen der Sammelbestellung erläutern, damit sie die Story passend einordnet.

4. Nicht zutreffend. Ins Product Backlog gehört alles, was am Produkt noch zu tun ist, also auch Fehlerbehebungen und technische Arbeiten. User Stories sind nur die häufigste Form der Einträge; Scrum schreibt keine bestimmte Form vor.

Begründung (2 Punkte, je sinnvoller Grund 1 Punkt), zum Beispiel:

• Die Anforderungen der Händler*innen sind noch nicht vollständig bekannt und ändern sich durch die Rückmeldungen aus dem Pilotbetrieb; Stories lassen sich alle zwei Wochen neu priorisieren.

• Die Pilothändler*innen sehen nach jedem Sprint ein nutzbares Zwischenergebnis und können früh Rückmeldung geben, statt erst am Ende ein fertiges Produkt abzunehmen.

• Bis zur Abschaltung von CSB-Order am 31.03.2027 können die wichtigsten Funktionen zuerst umgesetzt werden.

Grenze (1 Punkt), zum Beispiel: Ohne Gesamtdokument fehlt leicht der Überblick über alle Anforderungen; bei einem Festpreis- oder Ausschreibungsverfahren oder bei verbindlichen Vorgaben (z. B. Datenschutz, E-Rechnung) braucht es trotzdem schriftlich festgelegte, vollständige Anforderungen.