Im Laufe Ihres Projektes werden Sie feststellen, dass Ihr Backlog immer weiter anschwillt. Das ist ganz normal und geschieht auch, wenn wir sehr konsequent immer wieder unsere Anforderungen überprüfen. Man hat neue Ideen, grob gefasste Anforderungen werden verfeinert und aufgeteilt.
Ich beobachte immer wieder Product Owner, die ihr Backlog sehr gewissenhaft und ordentlich pflegen und dennoch Gefahr laufen, den Überblick zu verlieren, weil immer mehr und noch mehr erfasst wird. Besonders groß ist diese Gefahr, wenn man sehr euphorische und engagierte Kollegen hat. Ich möchte damit nicht sagen, dass Sie Ihre Kollegen bremsen sollen, aber wenn Ihr Backlog den Entwicklerkollegen davon läuft, dann stellen sich sehr bald ein paar Probleme ein, die wir leicht vermeiden können.
Es ist nicht wirklich motivierend, wenn das Backlog immer größer anstatt kleiner wird. Als Entwickler bekomme ich dann sehr schnell das Gefühl, in einem Endlosprojekt festzusitzen und Sisyphusarbeit zu leisten. Als Product Owner werde ich irgendwann den Überblick verlieren und die Anforderungen nicht mehr richtig bewerten und priorisieren können. Im schlimmsten Fall kann ich so mein Projekt ins Chaos stürzen.
Eine Möglichkeit, mein Backlog vernünftig zu ordnen, ist die Verwendung von Epics und Themen, wobei ein Epic eine Gruppe von Anforderungen darstellt, die gemeinsam ein größeres Feature bilden. In unserem Beispiel mit dem Webmailer (aus einem früheren Beitrag) wäre der Punkt »Terminkalender«, den wir zunächst nur als Stichwort für die spätere Umsetzung erfasst haben, sicherlich ein Epic, das sich aus mehreren Anforderungen (Eintragen von Terminen, Erinnerungen, Einladungen versenden usw.) zusammensetzt. Der Mehrwert für den Anwender entsteht im allgemein erst dann, wenn die meisten oder sogar alle Anforderungen eines Epics umgesetzt sind, weil erst dann das neue Feature komplett einsetzbar ist.
Themen hingegen können gleichartige Anforderungen zusammenfassen (z.B. unter dem Stichwort Performance). Diese können sich auf unterschiedlichste Features beziehen und auch einzeln einen Mehrwert generieren.
Es spricht nichts dagegen, sowohl Themen als auch Epics in Ihrem Backlog zu verwenden, oder nur Themen oder nur Epics. Scrum macht Ihnen nicht viele Vorgaben, wie Ihr Backlog auszusehen hat, es spricht lediglich davon, dass sie dort Ihre Anforderungen priorisiert aufgelistet haben. Ich empfehle Ihnen dringend die Verwendung von Epics und Themen in komplexen Projekten. Diese Dinge helfen Ihnen nicht nur dabei, die Dinge sauber zu ordnen, sie helfen Ihnen auch dabei, sich immer wieder darauf zu besinnen, nicht zu viele Baustellen auf einmal anzugehen, womit wir bei einem der Kernpunkte von Kanban angelangt sind.
Ihnen ist selbstverständlich (hoffentlich) bewusst, dass es Ihnen nichts bringt, viele Dinge gleichzeitig anzugehen, trotzdem erliegen viele Product Owner der Verführung, den Sprint eher nach Gesichtspunkten der Aufwandsschätzung aufzubauen und ihn damit möglichst ideal zu füllen, als bei einem Thema oder einem Epic (also einem größeren Feature) zu bleiben. So werden immer mehr Baustellen aufgerissen, die Entwickler müssen sich immer wieder umstellen, und die größeren Features, die sich immer aus mehreren Anforderungen zusammensetzen, bleiben länger als nötig unvollendet.
Diesen Punkt spricht Kanban sehr viel deutlicher als Scrum an. Scrum begrenzt work in progress lediglich anhand der Anforderungen, die wir in einen Sprint quetschen können, erlaubt uns aber, diese völlig wild zu mischen. Kanban hingegen limitiert diesen Wert direkt und zwingt damit den Anwender dazu, sich auf wenige Dinge zu konzentrieren. Vergessen Sie Kanban als dieses leicht esoterisch angehauchte Ding, das gern unter dem Begriff Alles ist im Fluss zusammengefasst wird. Einer der Kernaussagen dieses Systems lässt sich frei übersetzt so zusammenfassen:
Mach verdammt nochmal nicht zu viele Baustellen gleichzeitig auf!
Doch zurück zu den euphorischen und engagierten Kollegen, die den Product Owner mit immer neuen Ideen bombardieren. Zunächst einmal muss (und ich kann das garnicht genug betonen) der Product Owner alle Ideen konsequent auf ihren Wert und ihre Umsetzbarkeit hin bewerten. Wenn er ehrlich ist, werden viele dieser Anregungen dann garnicht erst den Weg ins Backlog finden.
Zum zweiten sollte man sich als Product Owner wirklich daran halten, dass Dinge, deren Umsetzung noch in weiter Ferne liegt, nicht genauer ausgearbeitet werden. Erst dann werden aus einem Stichwort mehrere Anforderungen. Denken Sie an das Beispiel mit dem Terminkalender. Erst wenn wir uns genauer mit dem Thema beschäftigen, erstellen wir die ganzen Anforderungen für das Anlegen von Terminen oder das Versenden von Einladungen.
Ich habe auch gute Erfahrungen damit gemacht, parallel zum Backlog einen Ideenpool aufzubauen, wo zunächst einmal alles gesammelt wird, was an Anregungen und Vorschlägen reinkommt. Damit wird die Bewertung eben dieser Dinge nicht direkt im Backlog vorgenommen sondern vorgezogen. Damit halten wir uns das eigentliche Backlog sauberer und erfassen dort wirklich nur die Dinge, die mit großer Wahrscheinlichkeit auch umgesetzt werden.
