Ein Pfeil, drei Kästchen und ein Fragezeichen haben unserem Senior Developer gereicht, um eine Abhängigkeit zu sehen, die wir vorher in drei Text-Refinements übersehen hatten. Kein Satz, keine ausformulierte User Story, nur eine Linie, die ins Leere lief. Genau darum geht es in diesem Sketchnotes-Tagebuch: User Stories im Product Backlog nicht mehr nur zu schreiben, sondern zu zeichnen, damit Product-Management-Meetings nicht an Schachtelsätzen scheitern. Visual-Thinking klingt nach Kreativworkshop – bei uns ist es eher Notwehr gegen Text, den am Ende keiner mehr entschlüsseln kann. Agile-Methoden versprechen kurze, klare Stories, liefern in der Praxis aber oft nur längere Sätze mit mehr Kommas.
Vorher habe ich es mit reiner Struktur probiert, nicht mit Bildern: vorgefertigte Meeting-Vorlagen aus Confluence kopiert, für jedes Refinement eine neue Kopie angelegt. Spätestens beim dritten Refinement fand ich in keiner einzigen Vorlage die Entscheidung wieder, die wir eigentlich getroffen hatten. Die Vorlage war sauber. Nur leer an der Stelle, die gezählt hätte.
Warum reine Text-User-Stories im Refinement scheitern
Unser Template ist das klassische: Als [Rolle], möchte ich [Ziel], um [Nutzen], die Struktur der User Story. Theoretisch reicht das völlig. In der Praxis landen wir oft bei Sätzen, die versuchen, technische Abhängigkeiten zwischen drei Systemen in eine Zeile zu pressen, die grammatikalisch gerade noch hält.
Eine Moderationskarte im Format DIN A6, 105 mal 148 Millimeter, ist inzwischen mein Rahmen dafür. Viel Platz bleibt da nicht, und das ist Absicht: Passt die Story nicht auf die Karte, ist sie entweder zu komplex, oder ich habe sie selbst noch nicht ganz verstanden.
Card, Conversation, Confirmation, die drei C's einer User Story, nehme ich inzwischen wörtlicher als am Anfang. Die Karte ist nicht mehr nur Platzhalter für ein späteres Gespräch, sondern der visuelle Ankerpunkt selbst. Und weil auf einer A6-Karte kein Platz für Fließtext ist, zwingt mich das Format zu einer Hierarchie: Was oben steht, ist der Auslöser, was darunter hängt, die Folge – genau diese Hierarchie zeigt, wie Epics und Stories räumlich zueinander gehören, ohne dass ich dafür ein Tool öffnen muss.
Vom Schachtelsatz zum Symbol
Akteure werden zu Strichmännchen, Systeme zu Vierecken, Datenflüsse zu Pfeilen. Fünf Grundformen reichen: Punkt, Linie, Dreieck, Viereck, Kreis. Mehr brauche ich halt nicht.
Meinen ersten brauchbaren Fineliner habe ich mir nicht gekauft. Matthias Sobolewski, mein Nachbar eine Etage tiefer, der auch remote arbeitet, hat ihn mir geliehen, nachdem ich mit einem viel zu dicken Stift nur Kleckse produziert hatte.
Während die anderen im Refinement noch auf ihren Tastaturen tippen, hört man bei mir oft nur das feine Kratzen der Spitze auf dem Papier. Es ist einer der wenigen Momente im Großraumbüro, in denen kurz niemand tippt.
Notizen aus reinen Meetings zu visualisieren, hatte ich vorher schon geübt, siehe Meeting Protokolle visuell gestalten und strukturieren, aber sie direkt ins Backlog zu bringen, ist eine andere Liga. Hier geht es nicht um mich, sondern um ein gemeinsames Bild im Kopf des ganzen Teams.
Wenn das Bild zu hübsch wird
Zu schöne Bilder lenken ab, das ist meine Erfahrung aus den ersten Wochen: Sobald ein Sketch zu sehr nach fertigem UI aussieht, wird aus dem Refinement ein Design-Review, und wir diskutieren Buttonfarben statt Fehlerfälle.
Also zeichne ich bewusst hässlich. Ein Blitz für den Fehlerfall, eine Wolke für irgendeinen Cloud-Service, ein Kasten für die Datenbank. Mehr Symbolik braucht es nicht, wenn es nur um Logik geht, nicht um Optik.
Einmal wollte ich eine Datentransformation an einer API-Schnittstelle zeichnen, und am Ende sah es aus wie ein zerknautschter Toaster. In den ersten Sekunden hat niemand verstanden, was das darstellen soll, erst nach meiner Erklärung ist der Groschen gefallen. Das Team hat kurz gelacht, aber die Logik dahinter war trotzdem sofort klar: Der Toaster wurde zum internen Running-Gag für genau diesen Endpunkt.
Für solche Skizzen nutze ich oft die Mittagspause, laufe eine Runde durch die HafenCity, um den Kopf freizubekommen, bevor nachmittags das nächste Meeting ansteht. Ein tägliches Sketchnotes Tagebuch führen gegen Stress im Büro Alltag hilft mir dabei, die Symbole so zu festigen, dass ich im Meeting nicht erst überlegen muss, wie eine Datenbank aussieht.
Pfeile zwischen zwei Kästen zeigen bei mir inzwischen eher Abhängigkeiten als reine Reihenfolge, welche Story eine andere blockiert, sehe ich oft erst, wenn ich die Verbindung tatsächlich zeichne, nicht wenn ich sie nur denke.
Der Moment, in dem die Lücke sichtbar wurde
Sprint Planning für das neue Checkout-Modul, mit Abhängigkeiten zu drei anderen Teams, normalerweise die Art Meeting, nach der ich zwei Aspirin brauche.
Ich habe eine vorbereitete Skizze dabei, kein Kunstwerk, nur Boxen und Pfeile auf einer Karte. Kaum erkläre ich den Ablauf, zeigt unser Senior Developer auf eine Linie mit einem Fragezeichen daneben.
"Jetzt verstehe ich zum ersten Mal die Abhängigkeit zum Checkout-Service wirklich", sagt er. "Wenn wir das so bauen, wie du es gezeichnet hast, bricht uns die Validierung im Frontend weg."
Stille, dann Nicken. Drei Text-Refinements hatten diese Lücke übersehen, aber im Bild war sie offensichtlich: Die Linie führte ins Leere.
Zwei Wochen, nachdem ich angefangen hatte, Datenflüsse nur noch mit Pfeilen statt mit Sätzen zu markieren, brauchte ich beim Wiederlesen keine Sekunde mehr, um zu wissen, was gemeint war – genau dieser Pfeil war einer davon.
Ab Woche sechs zeichne ich Systemsymbole, ohne nachzudenken, welche Linie wofür steht. In den ersten Wochen musste ich mir das jedes Mal kurz vergegenwärtigen, irgendwie geht das erst seit Kurzem von allein.
Wie du User Stories als Sketchnotes anfängst, ohne Künstler zu sein
Falls du auch PM bist und ohne Design-Hintergrund starten willst: Fang klein an. Teure Software brauchst du nicht, ein Block und ein paar brauchbare Stifte reichen. Ich nutze inzwischen die besten Sketchnotes Stifte für Einsteiger ohne Design Hintergrund, einfach weil ich keine Lust mehr auf verschmierte Linien habe.
Mein Grundvokabular bleibt klein: Akteure werden zu einfachen Strichmännchen, Aktionen zu Pfeilen unterschiedlicher Dicke, Systeme zu beschrifteten Rechtecken, Entscheidungen zu Rauten wie im klassischen Flussdiagramm.
Maximilian Dürr, ein Junior PM bei einem anderen SaaS-Unternehmen, den ich über LinkedIn kenne, hat neulich gefragt, ob das auch bei ihnen funktionieren würde. Er bringt in solchen Gesprächen gern Zahlen aus anderen Firmen mit und wollte wissen, ob sich unsere Refinement-Zeiten überhaupt messbar verändert haben. Eine klare Zahl konnte ich ihm nicht liefern, nur den Eindruck aus den Meetings selbst.
Der Schlüssel ist Reduktion, nicht Vollständigkeit. Ich zeichne nur den Kern der Logik, den Teil, der in Textform ohnehin zu kompliziert wäre. Den Rest schreiben wir weiterhin ganz normal als Akzeptanzkriterien unters Ticket.
Es geht nicht darum, Jira durch ein Malbuch zu ersetzen. Es geht darum, dass alle nach einem Meeting das gleiche Bild im Kopf haben, und der zuverlässigste Test dafür ist, ob jemand auf eine Lücke in der Zeichnung zeigt, bevor der Sprint beginnt, nicht danach.