Später Nachmittag im Refinement-Meeting. Wir starren seit zwanzig Minuten auf ein Jira-Ticket. Der Text ist so verschachtelt, dass selbst der Autor — ich — ihn nicht mehr wirklich erklären kann. Drei Schachtelsätze, die versuchen, eine komplexe Berechnungslogik im Backend zu beschreiben.
Ich sehe in Gesichter, die irgendwo zwischen geistiger Abwesenheit und akuter Überforderung schwanken. Laut meinem Kalender verbringe ich 62 Prozent meiner Arbeitswoche in solchen Meetings. Wenn die Hälfte dieser Zeit damit verschwendet wird, Texte zu dechiffrieren, die eigentlich Klarheit schaffen sollten, haben wir ein Problem.
Es ist Ende November, als mir klar wird: Die Text-Wüste im Backlog muss weg. Ich habe vor ein paar Wochen angefangen, mich mit visuellen Notizen zu beschäftigen. Nicht, weil ich plötzlich zum Künstler mutiert bin — ich kann immer noch kaum einen geraden Kreis ziehen —, sondern aus reiner Verzweiflung. Ich konnte meine eigenen Protokolle nicht mehr lesen.
Das Problem mit der reinen Text-Story
Wir nutzen alle das klassische Template: Als [Rolle], möchte ich [Ziel], um [Nutzen]. Das ist theoretisch super. In der Praxis enden wir oft bei Monstern, die versuchen, technische Abhängigkeiten in einen Satz zu pressen, der grammatikalisch gerade noch so zusammenhält.
Anfang Januar beschließe ich, das erste Mal die Inhalte meines Sketchnotes-Kurses auf eine echte, komplexe User Story anzuwenden. Ich merke schnell, dass das Gehirn visuelle Informationen viel schneller verarbeitet als Text — man sagt etwa 60.000-mal schneller, aber mir würde schon das Doppelte reichen, um die Meetings abzukürzen.
Ich nehme mir eine Moderationskarte. Standardmaß DIN A6, also 105 x 148 mm. Viel Platz ist da nicht. Das ist der Punkt. Wenn ich die Story nicht auf dieses Format gezeichnet bekomme, ist sie wahrscheinlich zu komplex oder ich habe sie selbst noch nicht verstanden.
Ich fange an, die 3 C's einer User Story — Card, Conversation, Confirmation — wörtlich zu nehmen. Die Karte ist jetzt nicht mehr nur der Platzhalter für ein Gespräch, sondern das visuelle Ankerzentrum.
Der Prozess: Vom Schachtelsatz zum Symbol
Mitte März habe ich ein System für mich gefunden. Ich zerlege die Story in Akteure und Aktionen. Ein Strichmännchen für den User. Ein Viereck für das System. Ein Pfeil für den Datenfluss. Es sind die fünf Grundelemente, die ich gelernt habe: Punkt, Linie, Dreieck, Viereck, Kreis. Mehr braucht es nicht.
Während ich das hier tippe, erinnere ich mich an das leise Quietschen des schwarzen Fineliners auf einer glatten Karteikarte, während das Team für einen Moment still war und zuschaute. Es war dieser seltene Moment von Fokus im Großraumbüro. Keiner tippte in Slack. Alle schauten auf die wackeligen Linien, die langsam Sinn ergaben.
Ich habe früher oft versucht, meine Meeting Protokolle visuell gestalten und strukturieren zu können, aber sie direkt ins Backlog zu bringen, ist ein anderes Level. Hier geht es nicht um mich, sondern um das gemeinsame Verständnis im Team.
Dabei ist mir etwas Wichtiges aufgefallen: Visuelle User Stories können auch nach hinten losgehen. Wenn ich versuche, sie zu schön zu machen, verschiebt sich der Fokus. Die Leute fangen an, über das Design der Buttons zu diskutieren, obwohl wir eigentlich über die funktionale Logik sprechen sollten.
Die Gefahr der zu schönen Bilder
Das ist mein Learning aus dem März: Visuelle User Stories im Backlog sind oft kontraproduktiv, wenn sie den Fokus auf schnelles Design statt auf die funktionale Logik hinter der Anforderung verschieben. Sobald ein Sketch zu sehr nach UI aussieht, wird das Refinement zum Design-Review. Das will ich nicht.
Ich brauche die Logik. Woher kommen die Daten? Wo fließen sie hin? Was passiert im Fehlerfall? Ich benutze jetzt bewusst hässliche Symbole. Ein Blitz für einen Fehler. Eine Wolke für die Cloud. Ein Kasten für die Datenbank.
Ich erinnere mich an meinen Versuch, eine API-Schnittstelle zu zeichnen, die am Ende aussah wie ein zerknitterter Toaster. Ich wollte eigentlich die Transformation von Daten darstellen, aber es wurde ein Haushaltsgerät. Das Team hat kurz gelacht, aber — und das ist der Punkt — sie haben die Logik trotzdem sofort verstanden. Der Toaster wurde zum Running-Gag und zum Symbol für diesen speziellen Endpunkt.
Für die Arbeit an solchen Skizzen nutze ich oft die Mittagspause, um den Kopf frei zu bekommen. Ein tägliches Sketchnotes Tagebuch führen gegen Stress im Büro Alltag hilft mir dabei, die Symbole zu festigen, damit ich im Meeting nicht erst fünf Minuten überlegen muss, wie man eine Datenbank zeichnet.
Der Wendepunkt im Sprint Planning
Ein verregneter Dienstagnachmittag im April. Wir sitzen im Sprint Planning für das neue Checkout-Modul. Es ist ein Monster von einem Projekt mit Abhängigkeiten zu drei anderen Teams. Normalerweise die Art von Meeting, nach der ich zwei Aspirin brauche.
Ich ziehe meine vorbereitete Skizze hervor. Es ist kein Kunstwerk. Es ist eine Ansammlung von Boxen und Pfeilen auf einer DIN A6 Karte. Ich erkläre den Ablauf. Plötzlich zeigt unser Senior Developer auf eine bestimmte Stelle in meiner Zeichnung — eine kleine Linie mit einem Fragezeichen daneben.
Er sagt: "Zum ersten Mal verstehe ich die Abhängigkeit zum Checkout-Service wirklich. Wenn wir das so machen, wie du es da gezeichnet hast, bricht uns die Validierung im Frontend weg."
Stille. Dann nicken. Wir hatten diesen Fehler in drei Text-Refinements übersehen. Aber in der visuellen Darstellung war die Lücke offensichtlich. Die Linie führte ins Leere. Das war der Moment, in dem ich wusste: Das hier ist kein Hobby. Das ist ein Werkzeug.
Wie man startet (ohne Künstler zu sein)
Falls du auch PM bist und dich fragst, wie du das ohne Design-Hintergrund hinkriegst: Fang klein an. Du brauchst keine teure Software. Ein Block und ein paar gute Stifte reichen völlig aus. Ich habe lange gesucht und nutze heute die besten Sketchnotes Stifte für Einsteiger ohne Design Hintergrund, um nicht ständig mit verschmierten Linien zu kämpfen.
Hier ist mein minimalistisches Setup für visuelle User Stories:
- Akteure: Einfache Strichmännchen (Star-People).
- Aktionen: Pfeile in verschiedenen Dicken.
- Systeme: Rechtecke mit Beschriftung.
- Entscheidungen: Rauten (wie im klassischen Flussdiagramm).
Der Schlüssel ist die Reduktion. Ich versuche nicht mehr, die gesamte Story abzubilden. Ich zeichne nur den Kern der Logik. Den Teil, der in Textform zu kompliziert wäre. Den Rest schreiben wir weiterhin als Akzeptanzkriterien unter das Ticket.
Es geht nicht darum, Jira durch ein Malbuch zu ersetzen. Es geht darum, die Kommunikation im Team zu retten. Wenn ich nach einem Meeting rausgehe und weiß, dass alle das gleiche Bild im Kopf haben — auch wenn dieses Bild wie ein Toaster aussieht —, dann war es ein guter Tag.
Morgen steht das nächste Stakeholder-Review an. Ich habe schon zwei Karten vorbereitet. Sie sind hässlich. Sie sind ungerade. Aber sie werden uns wahrscheinlich zwanzig Minuten Diskussion ersparen. Und das ist im Hamburger SaaS-Alltag eigentlich alles, was zählt.