User Stories erstellen
Verwandle eine Spezifikation in Stories, aus denen Entwickler bauen können.
Du hast eine PRD oder Feature-Beschreibung und musst sie in User Stories aufteilen, die klein genug für einen Sprint sind, klar genug, dass Entwickler nicht raten müssen, und testbar genug, dass QA weiß, wann es fertig ist.
Prompt-Vorlage
Du bist ein erfahrener Product Manager, der ein Feature in User Stories für die Entwicklung aufteilt.
Hier ist das Feature oder die Spezifikation, die aufgeteilt werden soll:
<context>
$ARGUMENTS
</context>
> Wenn das Obige leer ist, frage den Benutzer: "{{FÜGE DEINE PRD, FEATURE-BESCHREIBUNG, DESIGN-LINKS ODER GROBE ANFORDERUNGEN HIER EIN}}"
Teile dies in User Stories auf, die die folgende Struktur für jede Story verwenden:
**Titel:** Kurzer, beschreibender Name für die Story
**Story:** Als [spezifische Benutzerrolle] möchte ich [Aktion], um [Nutzen/Ergebnis] zu erreichen.
**Akzeptanzkriterien:**
- [ ] Angenommen [Vorbedingung], wenn [Aktion], dann [erwartetes Ergebnis]
- [ ] Enthält Randfälle, Fehlerzustände und Grenzfälle
- [ ] 4-6 Kriterien pro Story — genug, um klar zu sein, nicht so viele, dass es eine Minispezifikation wird
**Priorität:** P0 (muss für den Start vorhanden sein), P1 (sollte vorhanden sein) oder P2 (nice-to-have / zukünftig)
**Notizen:** Abhängigkeiten, Designreferenzen, technische Überlegungen oder offene Fragen.
Wende diese Prinzipien an:
- Jede Story sollte in einem einzigen Sprint abschließbar sein. Wenn sie zu groß ist, teile sie auf.
- Stories sollten unabhängig sein — vermeide Ketten, bei denen Story B nicht beginnen kann, bis Story A ausgeliefert ist.
- Schreibe Akzeptanzkriterien als testbare Verhaltensweisen, nicht als vage Beschreibungen. "Benutzer sieht eine Erfolgsmeldung" nicht "Benutzer hat eine gute Erfahrung."
- Berücksichtige die unglücklichen Pfade. Was passiert, wenn die API fehlschlägt? Wenn der Benutzer keine Daten hat? Wenn er eine Ratenbegrenzung erreicht?
- Gruppiere Stories nach Benutzer-Workflow, nicht nach technischer Komponente.
- Markiere jede Story, die Design-Input, API-Änderungen oder abteilungsübergreifende Abhängigkeiten erfordert.
Tipps
- Füttere dieses Skill mit der Ausgabe von craft-spec, um eine saubere PRD → User-Stories-Pipeline zu erhalten.
- Wenn Stories immer noch zu groß herauskommen, hat die Spezifikation wahrscheinlich einen Umfang, der zunächst in Phasen aufgeteilt werden sollte.
- Die besten Akzeptanzkriterien lesen sich wie ein Testskript — ein QA-Ingenieur sollte jedes davon überprüfen können, ohne Fragen zu stellen.
- Vergiss nicht die "Nullzustands"-Story — was sieht der Benutzer, bevor er Daten hat? Dies wird fast immer übersehen.