User Storys für die Schätzung vorbereiten
Drei ausgearbeitete Beispiele zu Umfang, Tests und Abhängigkeiten vor der Kartenwahl.
Vorbereiten heißt nicht, jedes Detail zu kennen
Eine besprechbare Story hat verständliches Ergebnis, Grenzen und sichtbare Fragen, keine vollständige Spezifikation. Refinement klärt und zerlegt Arbeit beim Lernen.
Die fiktiven Übungen haben keine vorgegebenen Punkte. Größe hängt von Produkt, Abhängigkeiten, Qualität und Referenzen ab. Erklärt zunächst das Lieferergebnis.
Diese Hilfe ist keine offizielle Scrum-Regel und keine Hürde für unsichere Arbeit. Eine bessere Frage ist auch ohne Schätzung nützlich.
Beispiel 1: Bestellungen anhand der Referenz suchen
Eine Supportperson findet eine Bestellung über die vollständige Referenz. API und wiederverwendbares Suchfeld bestehen. Teiltreffer und neue Filter sind ausgeschlossen.
Akzeptanz: gültige Referenz zeigt berechtigte Bestellung; unbekannte einen Leerzustand; Netzwerkfehler erlauben Wiederholung ohne Textverlust. Tastaturbedienung und klare Beschriftung sind nötig.
Fragt nach Rechten, eingefügten Leerzeichen und API-Tests für den Oberflächenvertrag. Ohne vorhandene API ändert sich der ursprüngliche Umfang.
Vergleicht eine ähnliche abgeschlossene Suche. Macht neue Rechtekonzepte deutlich: Visuelle Ähnlichkeit bedeutet nicht gleiche Größe.
Beispiel 2: Zusammenfassungs-E-Mail deaktivieren
Eine Person deaktiviert den Wochenüberblick in Einstellungen. Wiederherstellungs-E-Mails bleiben aktiv. Individuelle Häufigkeiten sind ausgeschlossen.
Akzeptanz: Einstellung bleibt nach Anmeldung erhalten, Versand beachtet sie und Speicherfehler stellen den vorherigen Zustand wieder her. Klärt bereits eingeplante E-Mails.
Unsicherheit liegt vielleicht im Versand statt im Schalter. Fragt Prozesskundige und untersucht bei Bedarf das Warteschlangenverhalten vor der Schätzung.
Beginnt binär und ergänzt Frequenzen später. Jeder Teil muss durchgängig funktionieren; eine Oberfläche ohne Versandänderung wirkt nur funktionsfähig.
Beispiel 3: Berichtsergebnisse exportieren
Eine berechtigte Person lädt gefilterte Ergebnisse als CSV mit vereinbarten Spalten und lesbarer Kopfzeile. Das fiktive Produkt ist keine angekündigte StoryFlop-Funktion.
Klärt Menge, Datumsformate, Sonderzeichen und Rechte. Sichtbare Seite oder alle Ergebnisse? Was erscheint während des Wartens? Antworten erfordern unterschiedliche Lösungen.
Akzeptanz: Filter passen, Akzente bleiben, Zielschnittstelle funktioniert und unberechtigte Zeilen fehlen. Beachtet Sicherheit und sichere Behandlung formelähnlicher Werte.
Untersucht unsichere Mengen mit repräsentativen berechtigten Daten. Ein ausdrücklich begrenzter nützlicher Export kann einem kompletten Export unbekannter Kosten vorausgehen.
Die gemeinsame Prüfung vor der Abstimmung
Zwei Personen erklären die Story. Klärt abweichende Ergebnisse vor den Karten. Tests, Review, Rechte und Abhängigkeiten gehören zur fertigen Arbeit.
Notiert Ausschlüsse gegen wiederkehrende Annahmen. Vergebt Verantwortung und Prüftermin für Fragen mit großem Einfluss auf die Lösung.
Bewahrt Antworten in der Vorlage und bringt Titel und Beschreibung zu StoryFlop. Übertragt die Einigung ins Backlog, um Kontext bei der Umsetzung zu erhalten.
- Wir können das erwartete Ergebnis erklären
- Wir wissen, wie wir es prüfen
- Abhängigkeiten, Grenzen und Fragen sind sichtbar
In die Praxis umsetzen
Interaktiven Fall ausprobieren →
Quellen und weiterführende Texte
Beispiele und StoryFlop-Anweisungen stammen aus diesem Bereich. Diese Quellen erläutern Methode und Refinement: