Übungsaufgaben zum Scrum-Projektstart: das Epic Mitfahrgesuche planen

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 „Scrum-Projektstart: das Epic
Mitfahrgesuche planen“.

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/flurmonitor-scrum-projektstart
- https://oer-informatik.de/szenario-mitfahrlabor
- https://oer-informatik.de/scrum
- https://oer-informatik.de/user-stories
- Stilbeispiel: https://oer-informatik.de/flurmonitor-scrum-projektstart-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Scrum
- Product Backlog
- User Stories
- Abnahmekriterien
- Definition of Done
- Planning Poker
- Story Points
- Velocity
- Sprint-Ziel
- Datenschutz

Kompetenzstufe: Basiskompetenz (alternativ: Kernkompetenz, 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.

Je Zeile 1 Punkt, wenn Bestandteil und Art stimmen:

Zeile 2 und 4 beschreiben Ereignisse innerhalb des Sprints; wer bei Zeile 4 „Sprint“ statt „Sprint Review“ nennt, bekommt keinen Punkt, weil es um die Vorführung des Inkrements geht.

• Product Backlog: Produktziel (hier „Offene Mitfahrgesuche erscheinen anonym auf den Monitoren.“) (1 Punkt)

• Sprint Backlog: Sprint-Ziel (1 Punkt)

• Inkrement: Definition of Done (1 Punkt)

Die Werte liegen weit auseinander. Die Personen mit der 2 und der 13 begründen ihre Schätzung (1 Punkt), danach schätzen alle verdeckt neu, bis sich die Werte annähern und das Team sich auf einen Wert einigt (1 Punkt).

So orientiert sich niemand an der zuerst genannten Zahl oder an der Meinung einer erfahrenen Person (Ankereffekt); jede Einschätzung bleibt unabhängig.

Die Werte folgen einer abgewandelten Fibonacci-Folge mit wachsenden Abständen (1 Punkt). Je größer ein Eintrag ist, desto ungenauer lässt er sich schätzen; eine Unterscheidung zwischen 6 und 7 würde eine Genauigkeit vortäuschen, die es nicht gibt (1 Punkt).

Story Points sind keine Zeiteinheit, sondern ein relatives Maß für Umfang, Komplexität und Unsicherheit im Vergleich zu anderen Einträgen (1 Punkt). Wie viel Zeit ein Punkt bedeutet, zeigt sich erst über die Velocity, also die Punkte, die das Team pro Sprint tatsächlich fertigstellt (1 Punkt).

Der Eintrag ist zu groß oder zu unklar, um ihn sinnvoll zu schätzen (1 Punkt). Er wird nicht geschätzt, sondern zuerst im Backlog Refinement mit dem Product Owner geklärt und in kleinere Stories geschnitten, die dann einzeln geschätzt werden (1 Punkt).

Je Story 2 Punkte (vollständige Schablone mit Rolle, Funktion und Nutzen 1 Punkt, sinnvoller, eigenständiger Zuschnitt 1 Punkt). Ein möglicher Schnitt:

• MON-13a: Als Fahrer*in möchte ich die offenen Gesuche auf dem Monitor mit Ort, Treffpunkt, Richtung, Datum und Zeitfenster sehen, damit ich weiß, wo noch Plätze gebraucht werden.

• MON-13b: Als Auszubildende*r möchte ich Gesuche und Angebote auf dem Monitor auf einen Blick unterscheiden können, damit ich nicht versehentlich ein Gesuch für eine freie Fahrt halte.

• MON-13c: Als Schulverwaltung möchte ich, dass jeder Monitor nur die Gesuche seines eingestellten Haltepunkts und seiner Richtung zeigt, damit der Monitor am Parkplatz nur Gesuche nach Hause anzeigt.

Ein Schnitt nach technischen Schichten („Datenbank für Gesuche“, „Template für Gesuche“) erfüllt die Forderung nicht, weil diese Einträge allein keinen Nutzen haben.

Je Kriterium 2 Punkte (vollständige Form mit Ausgangslage, Handlung und prüfbarem Ergebnis 1 Punkt, konkrete Werte und passender Inhalt 1 Punkt):

• AK-MON-13a.1: Angenommen, es gibt ein offenes Gesuch ab Gütersloh, Hauptbahnhof ZOB Steig 3, zur Schule, mit dem Zeitfenster 07:00 bis 08:00 Uhr. Wenn der Monitor im Foyer die Seite lädt, dann zeigt er eine Zeile mit Gütersloh, dem Treffpunkt, „zur Schule“, dem Datum und „07:00 bis 08:00“.

• AK-MON-13a.2 (Anonymität): Angenommen, das Gesuch stammt von Aylin Kaya mit dem Pseudonym „Morgenmuffel“. Wenn der Monitor die Seite lädt, dann kommen weder der Name noch das Pseudonym im HTML der Seite vor.

• AK-MON-13a.3 (Status): Angenommen, ein Gesuch ist vermittelt, zurückgezogen oder abgelaufen. Wenn der Monitor die Seite lädt, dann erscheint es nicht.

Der Vorschlag ist kein gutes Abnahmekriterium (1 Punkt). Er beschreibt, wie die Developers die Story umsetzen, nicht was für die Nutzenden sichtbar sein muss; diese Entscheidung gehört den Developers, und ein Product Owner kann sie nicht abnehmen. Was sichtbar sein soll, etwa „Gesuche stehen getrennt von den Angeboten“, gehört in MON-13b (1 Punkt).

Je Eintrag 1 Punkt für eine nachvollziehbare Position mit Begründung. Eine mögliche Rangfolge:

1. D, weil A, B und C ohne die Gesuche in den Daten nicht umsetzbar sind (Abhängigkeit).

2. A, weil die Anzeige den Kern des Produktziels und den größten Nutzen liefert.

3. F, weil die Gesuche ohne diese Vorgabe der Datenschutzbeauftragten nicht auf öffentlichen Monitoren erscheinen sollten; der Aufwand ist klein (Risiko).

4. C, weil sonst der Monitor am Parkplatz falsche Gesuche zeigt; baut auf A und MON-05 auf.

5. B, weil die Unterscheidung die Anzeige verständlicher macht, aber erst wichtig wird, wenn Gesuche und Angebote gemeinsam erscheinen.

6. E, weil der Nutzen unsicher, der Aufwand groß und die Datenschutzfrage ungeklärt ist; vor einer Umsetzung muss er geklärt und geschnitten werden.

F kann begründet auch vor A stehen (ohne F kein Livegang), C und B dürfen getauscht werden, wenn die Begründung passt. D vor A und E am Ende sind fachlich nötig.

F ist eine nichtfunktionale Anforderung, sie beschreibt eine Eigenschaft der Anzeige statt einer neuen Funktion (1 Punkt). Auch ohne Namen kann ein sehr genaues Zeitfenster zusammen mit Haltepunkt und Richtung auf eine bestimmte Person schließen lassen, etwa wenn nur eine Person regelmäßig um 06:53 Uhr ab einem kleinen Ort sucht; gröbere Werte erschweren diese Rückverfolgung (1 Punkt). ISO/IEC 25010: Sicherheit, Teilmerkmal Vertraulichkeit (1 Punkt). DSGVO: Datenminimierung (Art. 5 Abs. 1 lit. c) oder Datenschutz durch Technikgestaltung (Art. 25) (1 Punkt).

Die Rundung betrifft nur Gesuche und gehört daher als Abnahmekriterium zu der Story, die die Zeitfenster anzeigt (oder als eigene Story F mit Kriterium) (1 Punkt). Der allgemeine Grundsatz „keine Angaben, die auf eine Person schließen lassen“ steht schon als Datenschutz-Eintrag in der Definition of Done; er kann um „Zeitangaben von Gesuchen gerundet“ ergänzt werden, wenn das Team sicherstellen will, dass auch spätere Seiten das einhalten (1 Punkt). Beide Lösungen sind mit Begründung richtig.

• Velocity: (13 + 15 + 14) / 3 = 14 Story Points je Sprint (1 Punkt). Gezählt wird, was nach der Definition of Done fertig wurde, nicht was geplant war.

• Personentage im normalen Sprint: 4 \cdot 10 = 40 (1 Punkt)

• Personentage im nächsten Sprint: 4 \cdot 8 - 5 = 27 (1 Punkt)

• Kapazität: 14 \cdot 27 / 40 = 9{,}45, also etwa 9 Story Points (1 Punkt)

Nach Rang passen D (3), A (5) und F (1) mit zusammen 9 Story Points genau in die Kapazität (2 Punkte; C würde mit 11 Punkten die Kapazität überschreiten). Ein mögliches Sprint-Ziel: „Offene Gesuche erscheinen anonym und mit gerundeten Zeitfenstern auf dem Monitor im Foyer.“ (2 Punkte: beschreibt den Nutzen des Sprints, nicht nur die Liste der Einträge, und passt zu allen drei Einträgen).

• E aufnehmen: Die Developers entscheiden, wie viel sie im Sprint schaffen; mit 17 Story Points läge die Planung fast doppelt so hoch wie die Kapazität (1 Punkt). Außerdem ist die Datenschutzfrage von E ungeklärt, der Eintrag ist also nicht bereit. Der Product Owner kann die Reihenfolge ändern und E nach vorn holen, dann fallen andere Einträge heraus; sinnvoller ist, E zuerst mit Andrea Wolf zu klären und zu schneiden (1 Punkt).

• Review weglassen: Das Review ist Teil der Definition of Done. Ein Eintrag ohne Review ist nicht fertig und darf im Sprint Review nicht vorgeführt werden; die Qualität zu senken, um mehr zu schaffen, verschiebt die Arbeit nur nach hinten (1 Punkt). Die DoD ändert das Team höchstens in der Retrospektive und dann eher strenger, nicht für einen einzelnen Sprint (1 Punkt).

Die Linie ist noch nicht gesunken, weil kein Eintrag die Definition of Done erfüllt; daraus folgt nicht zwingend Verzug, aber ein Risiko, dass am Ende viel halb Fertiges übrig bleibt (1 Punkt). Weil A von D abhängt, sollte das Team zuerst D gemeinsam fertigstellen, statt parallel zu arbeiten (1 Punkt). Im Daily Scrum klärt es, was D aufhält, und ob das Sprint-Ziel noch erreichbar ist; wenn nicht, spricht es früh mit dem Product Owner, etwa darüber, F zuerst fertigzustellen oder den Umfang von A zu verkleinern (1 Punkt).