Montagmorgen im Hamburger Büro. Die Luft ist stickig, der Kaffee in meiner Tasse bereits bedenklich abgekühlt. Wir starren kollektiv auf den großen Monitor an der Wand. Dort klafft eine graue Liste mit etwa 40 Jira-Tickets. Es ist Sprint Planning — eigentlich der Moment für Fokus und Klarheit. Stattdessen sehe ich in Gesichter, die den Point of no Return der Aufmerksamkeit längst überschritten haben.
Ich bin Product Manager. Laut meinem Kalender verbringe ich 62 Prozent meiner Arbeitswoche in Meetings. Ende letzten Jahres habe ich aus reiner Verzweiflung angefangen, meine Notizen visuell zu strukturieren. Nicht, weil ich zeichnen kann — ich habe keine Vorkenntnisse und mein Design-Verständnis endet bei der Wahl der richtigen Tabellenfarbe. Ich habe es angefangen, weil ich meine eigenen Protokolle nach dem dritten Quartal schlicht nicht mehr lesen konnte.
Das Problem mit der textlichen Überlastung
In einem typischen Scrum-Umfeld neigen wir dazu, alles in Textform zu ersticken. Wir schreiben User Stories, Akzeptanzkriterien und Kommentare. Im Planning führt das oft dazu, dass wir zwar über Details diskutieren, aber das große Ganze — das Sprint-Ziel — aus den Augen verlieren. Vor etwa drei Monaten saß ich in einer besonders zähen Runde. Wir debattierten über Datenbank-Migrationen, während die Hälfte des Teams gedanklich schon in der Mittagspause war.
Ich griff zum Marker. Mein Herz klopfte ein bisschen schneller, meine Hände waren leicht feucht. Ich bin kein Zeichner. Aber die Textwüste am Monitor half uns nicht weiter. Ich trat ans Whiteboard und zeichnete ein einfaches Boot. Ein Viereck, ein Dreieck als Segel. Nichts, was einen Designpreis gewinnen würde. Dieses Boot sollte unseren Sprint darstellen.
Die Metapher als Anker
Ich zeichnete eine Insel am rechten Rand des Boards. Das war unser Ziel. Dazwischen: Wellen für den zweiwöchigen Zeitraum. Ich begann, die kritischen Abhängigkeiten nicht als Liste, sondern als Strömungen einzuzeichnen. Plötzlich passierte etwas. Die Blicke wanderten vom Monitor zum Whiteboard. Die Diskussion veränderte sich von "Ticket 402 vs. Ticket 405" zu "Wie umfahren wir diese Strömung, um die Insel zu erreichen?"
Ein skeptischer Entwickler, der normalerweise eher wortkarg ist, stand auf. Er nahm mir den Stift aus der Hand. Er zeichnete einen massiven Block unter die Wasseroberfläche — einen Eisberg. "Das hier ist das Risiko bei der API-Anbindung", sagte er trocken. Es war der Moment, in dem die Visualisierung zum kollektiven Werkzeug wurde. Wir sprachen plötzlich über Risikomanagement für komplexe SaaS Projekte, ohne dass ich das Wort einmal benutzen musste.
Warum weniger Details mehr Fokus bedeuten
Hier liegt die Falle, in die ich am Anfang oft getappt bin: der Drang zur Perfektion. Ich dachte, ich müsste jedes Ticket, jedes Feature und jeden Bug als Icon darstellen. Ein fataler Fehler. Zu viel visuelle Vorbereitung im Sprint Planning erstickt die spontane Problemlösung. Wenn ich mit einem fertigen, hochglanzpolierten Kunstwerk ins Meeting komme, traut sich niemand, einen Fehler zu korrigieren oder eine eigene Idee einzuzeichnen.
Die Magie passiert in der Unvollkommenheit. Mein Boot war hässlich. Der Eisberg des Entwicklers sah eher aus wie ein verunglückter Kartoffelchip. Aber es war funktional. Wir nutzen oft einfache Symbole für Softwareentwicklung, die jeder versteht. Ein Zahnrad für die Engine, eine Wolke für die Cloud, ein Blitz für einen Bug. Das reicht völlig aus.
Während im Raum die hitzige Debatte über die Migration weiterging, genoss ich für einen Moment das sanfte, rhythmische Kratzen meiner 0.5 mm Spitze auf dem Papier meines DIN A5 Notizbuchs. Ich hielt die wichtigsten Punkte für mich fest, während das Team am Whiteboard das eigentliche Problem löste. Die Dual-Coding-Theorie besagt, dass unser Gehirn Informationen besser verarbeitet, wenn sie verbal und visuell gleichzeitig kommen. Ich sehe das jede Woche live in Aktion.
Der Mut zur Lücke am Whiteboard
Letzte Woche im Review fiel mir auf, wie nachhaltig diese simple Zeichnung gewirkt hatte. Niemand sprach mehr von Ticketnummern. Das Team erinnerte sich an den "Eisberg". Visualisierung ist kein Selbstzweck und erst recht keine Kunstform für PMs, die zu viel Zeit haben. Es ist ein kognitives Werkzeug, um die Komplexität zu reduzieren.
Manchmal entstehen dabei auch Konflikte, die wir am Whiteboard lösen, weil Missverständnisse sofort sichtbar werden. Wenn zwei Personen unterschiedliche Dinge zeichnen, wissen wir sofort: Wir sind uns nicht einig. In einer Textwüste fällt das oft erst drei Tage später auf, wenn der Code bereits geschrieben ist.
Ich habe gelernt, dass ich nicht das gesamte Backlog zeichnen muss. Ich skizziere nur die neuralgischen Punkte. Den roten Faden. Den Rest erledigt Jira. Mein Sketchnotes-Tagebuch hilft mir dabei, dranzubleiben, auch wenn meine Symbole manchmal so kryptisch sind, dass ich sie selbst einen Tag später kaum deuten kann. Aber im Moment des Plannings geben sie uns genau das, was uns früher fehlte: einen gemeinsamen Blickwinkel auf das, was wir in den nächsten zwei Wochen eigentlich erreichen wollen.