Zurück zum Playbook
DefineDD-07
Ein gutes Ticket schreiben
Macht das Ticket verständlich und testbar und respektiert das mit den Engineers vereinbarte Arbeitsformat.
ProduktstatusVerfügbar
Input3 benötigte InputsNutzerbedürfnis und zugehöriger Brief oder PRD · Designs und erwartete Fehlerfälle · Fokus der Initiative und freigegebene Product-Brain-Leitlinien
SkillsDraft a Jira story · Prepare task context · Review an artifact against agreed criteriaProduct Manager + Product Manager Agent
ErgebnisUmsetzungsreife Jira-Story: Titel, Warum, beobachtbares Verhalten, testbare Akzeptanzkriterien, Fehlertexte und Evidenzlinks.Artefakt: Jira-Story
Owner
Product Manager
Mensch + Agent
Beteiligte · Agents
EngineerQAProduct Manager Agent
Auslöser
Eine abgegrenzte Story oder ein Arbeitselement ist bereit zum Schreiben.
Benötigter Kontext
ConfluenceNutzerbedürfnis und zugehöriger Brief oder PRDDesign SystemDesigns und erwartete FehlerfälleCompany BrainFokus der Initiative und freigegebene Product-Brain-Leitlinien
Optionaler Kontext
JiraBestehendes Element in JiraCodeBetroffene Code-Pfade
Skills
Draft a Jira storyPrepare task contextReview an artifact against agreed criteria
Vorgeschlagener Gesprächsbogen
- 1Story-Umfang vereinbarenNutzer-Outcome und kleinste zusammenhängende Arbeitseinheit klären. Das nützliche Ticket-Format mit Engineering vereinbaren und zu grossen Umfang erkennen.Skills: Prepare task context
- 2Verhalten und Akzeptanz entwerfenKlaren Titel, Warum, beobachtbares Verhalten, testbare Akzeptanzkriterien, echte Fehlertexte und Evidenzlinks schreiben. Umsetzungsentscheide offen lassen, sofern kein freigegebener Entscheid sie einschränkt.Skills: Draft a Jira story
- 3Engineering-Bereitschaft prüfenAls empfangender Engineer lesen; mehrdeutiges Verhalten, fehlende Links oder Entscheide erkennen und mit den relevanten Leitlinien im Company Brain vergleichen.Skills: Review an artifact against agreed criteria
- 4Die Story besprechen und bestätigenJede blockierende Frage klären, den finalen Entwurf mit dem bestehenden Element vergleichen und die gewünschte Version bestätigen. Die Übernahme in die Quelle folgt der üblichen expliziten Bestätigung.
Ergebnis
Umsetzungsreife Jira-Story: Titel, Warum, beobachtbares Verhalten, testbare Akzeptanzkriterien, Fehlertexte und Evidenzlinks.
Artefakte
Erstellt: Jira-Story
So sieht gut aus
- Akzeptanzkriterien sind testbar und das Verhalten ist beobachtbar.
- Der empfangende Engineer findet kein mehrdeutiges Verhalten und keinen fehlenden Entscheid.
- Umsetzungsentscheide bleiben offen, sofern kein freigegebener Entscheid sie einschränkt.
Freigabe
Der Product Manager bestätigt die gewünschte Version, bevor sie in Jira übernommen wird.
Ziel
Jira
Meist als Nächstes
Menschen und Agenten nutzen dasselbe freigegebene Firmenwissen. Der Owner bleibt verantwortlich. Zugewiesene Agents bereiten vor und prüfen. Ein benannter Mensch gibt an der Freigabe frei.
Vertiefung im AI PM Lab
Beiträge, die das Denken hinter dieser Activity erklären.
- Spec-Driven Development für Agentic Software Engineering: Warum die Spec der Vertrag zwischen Team und Agents ist
- Strukturierte KI-Workflows: Warum euer Team nicht bessere Prompts braucht, sondern Struktur
- KI-Tools für Product Manager: der Stack, der Kontext trägt
- Skill Files: Die nächste KI-Kompetenz nach dem Prompting
Wähl den Einstieg, der zu deiner Rolle passt.
Wählt einen Entscheid und prüft, wo die Umsetzung abweicht. Klärt mit einem Gründer einen sinnvollen ersten Scope.