Vierzig Jira-Tickets in einer grauen Liste sagen nichts darüber, was in den nächsten zwei Wochen tatsächlich zählt. Genau das ist der wunde Punkt, der mich als Product Manager in einem Hamburger SaaS-Unternehmen bei fast jedem Sprint-Planning-Termin in agilen Teams beschäftigt. Sketchnotes haben mir dabei keine Wunderlösung gebracht, aber eine klare Grenze gezeigt: Text und Ticket-Listen sind stark bei Details, visuelle Notizen am Whiteboard sind stark bei Fokus. Die eigentliche Frage lautet nicht, welches Werkzeug gewinnt, sondern wann man welches zieht.
Ein Kontakt aus einem anderen SaaS-Unternehmen, Maximilian Dürr, macht es fast komplett anders. Wir kennen uns über einen LinkedIn-Kommentar, tauschen uns seither ab und zu aus. Maximilian dokumentiert sein Sprint Planning fast ausschließlich in Confluence – präzise, mit Zahlen zu Aufwand, Kapazität und Velocity, jede Zeile verlinkt zu einem Jira-Ticket. Keine Zeichnung, keine Metapher, keine Linie, die nicht sofort messbar wäre. Zwei Ansätze, ein Ziel: dass ein Team nach dem Planning weiß, was in den nächsten zwei Wochen passiert.
Die Confluence-Vorlage fürs Sprint Planning landet im digitalen Nirwana
Genau diesen Weg bin ich am Anfang auch gegangen. Eine fertige Meeting-Vorlage aus Confluence, Spalten für Akzeptanzkriterien, Risiken und offene Fragen, sauber beschriftet und kopiert. Wenig später fand ich in genau dieser Vorlage kaum etwas wieder. Die Struktur war vorhanden, geholfen hat sie mir nicht dabei, mich an irgendetwas zu erinnern. Dokumentiert war es, verstanden nicht.
In einem klassischen Scrum-Setup ersticken wir gerne alles in Textform – User Stories, Akzeptanzkriterien, endlose Kommentarspalten. Dabei verlieren wir das Sprint-Ziel aus den Augen, während wir uns an einzelnen Tickets festbeißen. Maximilians Tabellen sind für die Nachvollziehbarkeit kaum zu schlagen, jede Entscheidung lässt sich später noch belegen. Für gemeinsamen Fokus im Raum taugen sie wenig – niemand schaut während des Plannings in eine Tabelle, um sich zu orientieren.
Ein Boot, ein Eisberg, ein Sprint-Ziel
Am Whiteboard sieht meine Version anders aus. Statt einer Liste zeichne ich ein Boot für den Sprint, eine Insel für das Ziel und Wellen für die zwei Wochen dazwischen – ein Viereck mit Dreieck als Segel, mehr Talent braucht es nicht. Als ein sonst eher wortkarger Entwickler neulich einfach den Stift nahm und unter die Wasserlinie einen Klotz zeichnete, wusste jeder im Raum ohne ein Wort: Da liegt ein Risiko, über das noch niemand gesprochen hat. Wir landeten mitten im Gespräch über Risikomanagement für komplexe SaaS Projekte, ohne dass ich das Wort ein einziges Mal aussprechen musste.
Weniger zeichnen, nicht mehr
Der Fehler, den ich am Anfang gemacht habe: der Drang, jedes Ticket, jedes Feature, jeden Bug als eigenes Icon darzustellen. Zu viel visuelle Vorbereitung erstickt die spontane Problemlösung im Planning genauso wie eine zu volle Tabelle. Wenn ich mit einem fertigen, polierten Board ins Meeting komme, traut sich niemand, eine Linie zu korrigieren oder eine eigene Idee einzuzeichnen. Ein Zahnrad für die Engine, eine Wolke für die Cloud, ein Blitz für einen Bug: einfache Symbole für Softwareentwicklung, die jeder im Raum sofort liest, reichen völlig aus.
Hässlich darf es sein. Mein Boot ist schief, der Eisberg des Kollegen sieht eher aus wie ein verunglückter Kartoffelchip. Funktioniert hat es trotzdem, vielleicht gerade deswegen: Niemand hatte Angst, eine Linie zu verändern oder eine eigene draufzusetzen.
Dreimal aufs Blatt schauen, zwanzigmal wäre das Handy dran gewesen
In einem Review, das sich über anderthalb Stunden zog, habe ich mitgezählt, wie oft ich tatsächlich in mein A5-Heft geschaut habe: dreimal. Zum Vergleich – bei einem reinen Text-Call wäre mein Blick locker zwanzigmal zum Handy gewandert, allein aus Langeweile. Neben dem aufgeschlagenen Heft stand ein Glas Wasser, das während des ganzen Calls kalt blieb, weil ich schlicht vergaß, es anzurühren. Die Aufmerksamkeit war woanders gebunden, und das war gut so.
Matthias hält das für rausgeschmissene Zeit
Mein Nachbar Matthias Sobolewski arbeitet in der Logistikbranche und wohnt eine Etage tiefer. Mittags treffen wir uns manchmal auf einen Kaffee im Schanzenviertel, und für ihn ist die ganze Sketchnotes-Sache verschwendete Zeit – sein Argument: Wenn eine E-Mail reicht, warum ein Bild malen. Handfest ist der Einwand trotzdem, weil er aus einer Branche kommt, in der Prozesse fast ausschließlich in Tabellenform laufen und offenbar trotzdem funktionieren. Widerlegt habe ich ihn nicht, ergänzt schon: Im Sprint Planning entsteht die Zeichnung vorwärts, nicht rückblickend wie ein Protokoll, und sie muss zwei Wochen später noch stimmen – jede Linie, die ich ziehe, ist eine Wette.
Wann Text gewinnt, wann das Whiteboard gewinnt
Zwischen Maximilians Tabellen und meinem Whiteboard gibt es keinen Gewinner, nur unterschiedliche Jobs. Text gewinnt, wenn es um Nachvollziehbarkeit geht – wenn später jemand nachlesen muss, warum eine Entscheidung so gefallen ist, oder wenn ein verteiltes Team asynchron mitlesen soll. Das Whiteboard gewinnt, wenn ein Raum voller Leute in derselben Sekunde dasselbe Bild vor Augen haben muss, um weiterzukommen. Am deutlichsten zeigt sich das, wenn zwei Personen unterschiedliche Dinge zeichnen: Konflikte, die wir am Whiteboard lösen werden sofort sichtbar. In einer Textwüste fällt so ein Missverständnis oft erst auf, wenn der Code schon geschrieben ist.
Mein eigenes Sprint Planning läuft inzwischen doppelgleisig: Grobe Linien am Whiteboard während des Meetings, die sauberen Zahlen tippt jemand aus dem Team danach in Confluence. Keine Methode ersetzt die andere – sie fangen nur unterschiedliche Dinge ein, und ich habe aufgehört, das für ein Problem zu halten.