Scrum Poker per Vibe-Coding: Ein Hitzeprojekt mit Claude Code

Es gibt Tage, an denen das Thermometer jede ehrgeizige Planung erledigt. Bei dieser Hitze ist an konzentrierte Tiefenarbeit kaum zu denken, und genau in solchen Phasen entstehen die Projekte, die man sich sonst nie gönnt. Dieses hier ist so eins: ein kleines Scrum-Poker-Tool, an einem Samstag- und einem Sonntagnachmittag aus einer Laune heraus entstanden, immer dann, wenn die Familie gerade anderweitig beschäftigt war.

Warum überhaupt

Für unsere Schätzrunden hatten wir ein kommerzielles Online-Tool in der Testphase ausprobiert. Funktional völlig in Ordnung, aber mit einer Eigenheit, die niemand erwartet hätte: Das mit Abstand beliebteste Feature war, Dinge auf die Leute zu werfen, die noch nicht getippt hatten. Ein Papierkügelchen, eine Tomate, was eben zur Hand war. Albern, ja. Aber es hat die sonst eher trockene Aufwandsschätzung jedes Mal aufgelockert, und die Runde hat es geliebt.

Die Trial lief gut, aber danach hätte das Tool Geld gekostet. Das war der Auslöser. Statt auf ein Abo umzustellen, war die Frage naheliegend: Wie viel Aufwand ist das eigentlich selbst? Die ehrliche Antwort an diesem Nachmittag lautete: erstaunlich wenig.

Bewusst nichts speichern

Die erste Entscheidung war die wichtigste, und sie fiel gegen ein Feature: keine Persistenz. Kein Account, keine Datenbank, kein gespeicherter Verlauf. Der gesamte Spielzustand lebt im Speicher des Server-Prozesses und ist weg, sobald die Session endet oder das Tool neu startet.

Das klingt nach einem Mangel, ist aber eine Befreiung. Eine Schätzrunde ist ein flüchtiges Ereignis: Sie dauert ein paar Minuten, danach steht die Zahl im Ticket und das Tool hat seinen Zweck erfüllt. Nichts davon muss einen Neustart überleben. Wer nichts speichert, hat keine Migrationen, keine Datenschutz-Diskussion über gespeicherte Namen, keine volllaufende Platte. Der Preis ist eine bewusste Einschränkung: Es läuft genau eine Instanz, kein Load-Balancing, keine Replikas, denn der In-Memory-Zustand lässt sich über mehrere Prozesse nicht teilen. Das ist keine Bremse: Das Tool steht offen im Netz, jeder kann eine Runde aufmachen und den Link teilen. Und eine Instanz reicht weit, denn Astro ist sparsam zur Laufzeit. Mit 2 GB Arbeitsspeicher passen reichlich parallele Sessions auf einen einzigen Prozess. Für eine flüchtige Schätzrunde ist die eine Instanz kein Kompromiss, sondern der passende Zuschnitt.

Was es kann, in einem Satz pro Schritt

Wer eine Runde starten will, gibt nur seinen Namen ein, wählt ein Kartendeck (Fibonacci oder T-Shirt-Größen) und bekommt einen teilbaren Link. Wer dem Link folgt, gibt ebenfalls nur seinen Namen ein und sitzt mit am virtuellen Tisch. Die Identität steckt in einem signierten Cookie, nicht in einem Konto: Das reicht, damit ein Reload niemanden aus der Runde wirft, und verhindert zugleich, dass man fremde Stimmen abgibt.

Der Host eröffnet eine Runde mit einem Titel, alle tippen verdeckt. Bis zum Aufdecken überträgt der Server nur, wer schon getippt hat, nicht was. Erst wenn der Host aufdeckt, werden alle Karten gleichzeitig sichtbar, samt Mittelwert und Verteilung.

Das eigentliche Feature: werfen

Den ganzen technischen Unterbau hätte man auch nüchtern bauen können. Aber das Herzstück, der Grund für das ganze Projekt, ist das Werfen. Jeder kann jederzeit ein Icon auf einen anderen Avatar schleudern: ein Papierkügelchen, eine Tomate, ein Emoji nach Wahl. Es fliegt sichtbar über den Tisch und trifft. Reiner Zierrat, kein Einfluss auf das Ergebnis, und genau deshalb richtig.

In der Praxis ist das der sanfte soziale Druck, den eine Schätzrunde braucht: Wer zu lange überlegt, fängt sich eben eine Tomate. Es ist das Feature, das ich beim Vorbild am meisten vermisst hätte, und das erste, das ich nachgebaut habe.

Die Belohnung: Einstimmigkeit

Den Abschluss bildet eine kleine Feier. Tippen beim Aufdecken alle dieselbe Karte, gibt es Konfetti, ein Feuerwerk und ein Banner. Einstimmigkeit ist im Planning Poker der seltene, schöne Moment, in dem sich alle ohne Diskussion einig sind, und der darf gefeiert werden.

Echtzeit ist dabei die einzige echte technische Anforderung: Wirft jemand, muss es bei allen sofort ankommen. Das läuft über Server-Sent-Events, nicht über WebSockets. Für eine Verbindung, über die der Server nur an die Clients sendet und die Aktionen ohnehin als normale Anfragen zurückkommen, sind SSE die einfachere Wahl. Weniger bewegliche Teile, gleiche Wirkung.

Vibe-Coding, ehrlich betrachtet

Das Bemerkenswerte ist nicht die App, es ist die Art, wie sie entstanden ist. Ich habe sie fast vollständig per Vibe-Coding mit Claude Code geschrieben: beschreiben, was passieren soll, das Ergebnis prüfen, nachschärfen. Über das Werkzeug haben wir hier schon nüchterner geschrieben, und dieses Projekt bestätigt beide Seiten. Für eine überschaubare, gut abgegrenzte Anwendung ohne Altlasten trägt der Ansatz erstaunlich weit. Ein Avatar-Layout auf einer Ellipse, eine Wurf-Animation, ein Konfetti-Canvas: solche Dinge sind schnell beschrieben und schnell geprüft.

Mindestens so überraschend war, wo das ging. Es war ein Projekt für die Lücken: zwei Wochenend-Nachmittage, immer in den Momenten, in denen die Familie gerade nicht verfügbar war. Teile davon sind per Remote-Session vom iPad und vom Handy entstanden, manche Prompts kamen vom Beckenrand im Schwimmbad. Und das Ausrollen lief denselben Weg: Claude Code hat den Code geschrieben und ihn anschließend selbst deployt, also den Release-Tag gesetzt, die Pipeline beobachtet und auf dem Server die neue Version gezogen. Von der Idee bis zur laufenden Instanz, ohne einmal die Maus anzufassen.

Die ehrlichen Einschränkungen gelten hier wie überall: Die Arbeit verschwindet nicht, sie verschiebt sich vom Schreiben zum Prüfen. Plausibel aussehender Code ist nicht automatisch korrekter Code, und bei einer Wegwerf-App ist die Versuchung groß, genau das zu übersehen. Dass hier nichts mit echten Daten oder echtem Geld passiert, macht die Sache angenehm risikoarm: ein guter Spielplatz, um auszuprobieren, wie weit der Ansatz wirklich trägt.

Fazit

Herausgekommen ist ein kleines, bewusst flüchtiges Werkzeug: kein Login, keine Datenbank, eine Instanz, und als wichtigstes Feature das Werfen von Tomaten. Nichts davon würde man so in einem Produkt bauen, das Bestand haben soll. Aber als Hitzeprojekt zweier Wochenend-Nachmittage zeigt es ganz gut, was sich verschoben hat: Der Engpass ist heute selten das Tippen. Er liegt davor, beim genauen Beschreiben, und danach, beim ehrlichen Prüfen. Gute Werkzeuge nehmen einem das Tippen ab. Den Rest, und das ist die eigentliche Arbeit, nicht.