Die Idee formulieren, nicht das Ticket: wie das Spec-Gate kurz bleibt

Der Product Owner in aSPARK ist absichtlich kein Ja-Sager. Nach dem ersten Entwurf läuft ein Clarify-Durchgang, der die Spec gegen eine feste Taxonomie prüft: funktionale Grenzen, Daten, Berechtigungen, Fehler- und Randfälle, nicht-funktionale Anforderungen, Integrationen, UX-Zustände, Out of Scope. Alles, was dort offen ist, kommt als Frage zurück.

Das ist gut so. Genau diese Fragen sind der Grund, warum ein Feature hinterher stimmt. Aber Sie entscheiden mit der Formulierung Ihrer Idee, welche dieser Fragen gestellt werden — die interessanten oder die offensichtlichen.

Das Muster

Eine gute Idee für /story-time oder /spark beantwortet im Vorbeigehen, was ohnehin gefragt würde, und lässt genau das offen, wo Sie eine Meinung hören wollen. Fünf Dinge lohnen sich fast immer:

1. Das sichtbare Verhalten, nicht die Umsetzung. Was sieht und tut die Nutzerin? Technische Entscheidungen gehören in den Plan, nicht in die Spec.
2. Die Zustände am Rand. Was steht da, wenn nichts da ist? Was passiert beim ersten Mal, beim letzten Element, bei 100 Einträgen?
3. Tastatur und Fokus, sobald es eine Oberfläche gibt. Das ist die Frage, die sonst garantiert zurückkommt.
4. Die Zahl oder Form, an der man es messen kann. "Zeigt an, wie viele offen sind" ist schwächer als "zeigt N items left, Singular 1 item left".
5. Out of Scope, ausdrücklich. Ein Satz, der sagt, was nicht dazugehört, spart im Review eine Diskussion und im Plan einen Umweg.

Ein echtes Beispiel

Das Feature aus unserem Demo-Video startete mit genau einem Satz:

Add a filter bar above the todo list with three toggle buttons — All, Active, Done — and a counter that reads "N items left" (singular "1 item left"), counting only active todos. Exactly one filter is selected at a time and is visually marked as selected; All is the default. The list shows only todos matching the selected filter; the counter is independent of the filter. Each filter has its own empty message: "Nothing to do — nice." for Active, "Nothing done yet." for Done; the existing "Nothing here yet" message stays for All. Buttons are real <button> elements, operable by keyboard, with the selected one exposed via aria-pressed. Out of scope: persisting the selected filter across reloads, URL routing, editing todos, animations, and any new dependency or file.

Darin steckt jeder der fünf Punkte: sichtbares Verhalten, drei benannte Leerzustände, Tastaturbedienung, ein prüfbarer Zählertext und eine ausdrückliche Abgrenzung.

Der Product Owner hat trotzdem nachgehakt — und zwar dort, wo es sich lohnte. Eine der Fragen: Wenn jemand per Tastatur unter Active ein Todo abhakt, verschwindet die Zeile sofort aus der Liste. Wohin geht dann der Fokus? Darauf hatte ich keine Antwort parat, und sie ist als Akzeptanzkriterium in die Spec gewandert. Genau dieses Detail hat der Reviewer später wieder aufgegriffen, als der Fokusrahmen auch nach Mausklicks stehenblieb.

Aus dem einen Satz wurden 3 Stories und 29 Akzeptanzkriterien. Der ganze Loop, von der Idee bis zum Release, dauerte 47 Minuten.

Was das Muster nicht tut

Es macht den Loop nicht kürzer, sondern verschiebt den Aufwand nach vorn. Act, Review und QA dauern so lange wie das Feature groß ist. Und es ersetzt nicht das Nachfragen: Wenn die Clarify-Runde eine Lücke findet, ist das kein Zeichen einer schlechten Idee, sondern der Moment, in dem ein Fehler zwei Stunden früher auffällt als sonst.

Wenn Sie keine Idee haben

Dann formulieren Sie auch keine. /next-steps sichtet den Projektstand — was ausgeliefert ist, was in Arbeit ist, was liegengeblieben ist, was die Constitution vorgibt — und schlägt ein konkretes nächstes Feature vor. Der Vorschlag ist beratend; geschrieben oder freigegeben wird nichts. Was dabei herauskommt, geben Sie dann als Idee an /story-time oder /spark, und zwar am besten so formuliert wie oben.