Wer plant mit welchen Backlogs? – Sichtenwechsel notwendig!

Kennen Sie auch die Situation, dass Ihre Projekte nicht die optimalen Voraussetzungen für Scrum haben? Sie haben also:

• Entwickler, die zeitgleich in mehreren Projekten arbeiten.
• Entwicklungsteam, die auf unterschiedliche Standorte und Zeitzonen verteilt sind.
• Nur ein auslieferbares Release, wenn die Zulieferung vieler Teams erfolgt ist.

Dann stellt sich auch Ihnen die Frage: Wer plant mit welchen Backlogs? Weil auch Ihre Projekte im Application Lifecycle Management (ALM) von den Vorzügen agiler Entwicklung profitieren sollen, werden wir hier einen Ansatz zur Beantwortung dieser Frage vorstellen.

Augenscheinlich sollte sich die Identität der Personen (Wer) über eine Analyse von Rollendefinitionen (Aufgaben, Verantwortlichkeiten und Fähigkeiten) und deren Abbildung auf konkrete Personen in einem Unternehmen ergeben. Unsere Erfahrungen zeigen aber, dass die Definitionen von Rollen je Organisation zum Teil sehr verschieden sind. Konkrete Aufgaben und Verantwortlichkeiten unterscheiden sich je Projektauftrag und beteiligter Personen und Organisationseinheiten. So wird auch innerhalb einer Organisation die gleiche Rolle mitunter sehr unterschiedlich verstanden und gelebt. Prozesse, Organisationsform, Branche und Projektgröße sind Dimensionen, die begründen, weshalb wir in der Praxis so vielfältige Instanziierungen von Rollen antreffen. Ein Beispiel können Sie vielleicht an der Rolle von Architekten nachvollziehen. Hier reicht die Bandbreite von einer dezidierten Architektur-Organisation bis zum Senior Software-Entwickler, der in seinen Projekten für die Architekturentscheidungen verantwortlich ist.

Wir suchen aber Antworten, die eher allgemeingültig sind, damit sie auf unterschiedliche Entwicklungsprojekte übertragen werden können. Deshalb helfen uns Rollenmodelle an dieser Stelle nicht viel weiter.

Sichtenwechsel notwendig!

Zur Einordnung der agilen Backlogs, benötigen wir eine andere Sicht. Diese Sicht soll Aspekte betrachten, die in möglichst vielen Produktentwicklungen relevant sind. Damit können wir Aussagen über die Verwaltung der agilen Backlogs machen, die sich unabhängig von den Projektrahmenbedingungen leichter adaptieren lassen. Deshalb untersuchen wir die Inhalte der Backlogs – die Backlog Items.

Backlog Items

Ein Backlog Item kann allgemein als Item definiert werden, das in der Produktentwicklung geplant Ressourcen verbraucht . Typischerweise sind dies neben Requirements, Features oder User Storys auch Issues, Defects und Tests.

Backlog Items repräsentieren somit die Inhalte der Produktentwicklung, die Planungsrelevant sind. Diese Inhalte können 1:1 von einem Backlog Item abgebildet werden, wie zum Beispiel ein Requirement oder ein Test Case. Andere Inhalte wie beispielsweise geschätzte Aufwände, Nutzen und Risiken können als Eigenschaften in mehreren unterschiedlichen Backlog Items abgebildet werden. Zum Beipiel werden Risiken durch Attribute in mehreren unterschiedlichen Backlog Items (Requirement, Feature, Defect usw.) definiert. Weitere Zusammenhänge sind in den Beziehungen zwischen Backlog Items dokumentiert. Zum Beispiel kann das Backlog Item Task mit dem Subtyp „Implementation“ als Child-Item zu einer User Story angelegt werden. Die Parent-Child Beziehung wird zur Planung und für Reports genutzt. Aussagen über den Stand der Implementierung einer User Story sowie die Darstellung in einem Burn-Down-Chart sind damit möglich. Je nachdem welche Planungsaufgabe ansteht, benötigen wir also eine andere Sicht auf die Backlog Items.

Wollen wir alle User Storys eines Sprint x sehen, können wir ein solches Sprint Backlog bilden, indem wir alle User Storys abfragen, die ein Commitment zum Sprint x haben. Will ein Product Owner wissen, welche Features er für das nächste Release y priorisieren und in ein Reihenfolge bringen (Ranking) muss, lässt er sich alle Features anzeigen, die zum Release y zugeordnet sind. Will ein Scrum-Team wissen, wie weit der Umsetzungsfortschritt im Sprint ist, werden alle Aufwände (Completed Work; Remaining Work) der Tasks abgefragt, die den relevanten User Storys zugeordnet sind (Burndown-Chart).

Eine Antwort

Die unterschiedlichen Ausprägungen der Dimensionen Prozesse, Organisationsform, Branche und Projektgröße zeigen, wie vielfältig die Produktentwicklung gestaltet ist. Darauf basierende Rollenmodelle und deren Instanziierung bieten daher für das Backlog-Management keine guten Wege, mit dieser Vielfalt umzugehen.

Unser Vorschlag: Wir stellen für die Projektplanung die Planungsgegenstände in den Mittelpunkt, die Backlog Items. Die Eigenschaften der Backlog Items und die Fragestellungen für die Planungsaufgaben bestimmen maßgeblich die Sichten auf die Backlogs. An Folgenden Beispielen wollen wir dies noch einmal aufzeigen. Unser Backlog Item ist ein „Requirement“. Jetzt muss einfach entschieden werden, in welchen Backlogs das Requirement dokumentiert werden soll. Beispielsweise könnte die Erhebung in einem Company Backlog erfolgen und dann zur weiteren Detaillierung in ein Product Backlog verschoben werden. Die Umsetzungsplanung kann in unterschiedlichen Ebenen erfolgen: Produktplanung im Product Backlog, Releaseplanung im Release Backlog und für den Sprint ist diese Anforderung Input für die Selbstorganisation des Projektteams. Die Planung für den Nachweis der Realisierung kann dann entweder im Sprint selber durch Akzeptanztests oder im Integration Backlog erfolgen. Letzteres wird vor allem dann relevant, wenn ein auslieferbarer Stand nur durch Zulieferung vieler Teams erstellt werden kann.

Die Backlog Items sind im Gegensatz zu Rollen leichter auf unterschiedliche Projektsituationen adaptierbar. Sie können sich darauf fokussieren, wie mit einem Backlog Item in Ihrer Entwicklung umgegangen wird. Unser Vorschlag orientiert sich in erster Linie an den Planungsgegenständen und nicht an den Planungsaufgaben, die nur nachgelagert eine Relevanz haben. Somit setzen wir auf eine überschaubare Menge von Planungsobjekten und sind unabhängig von vielfältig ausgeprägten Planungsaktivitäten.

PS: Nutzen Sie gerne die Gelegenheit mich persönlich kennen zu lernen und erfahren Sie mehr zu “Agiles Backlogmanagement ausserhalb der Lehrbücher – Den Überblick über agile Backlogs auch in mittleren und großen Entwicklungsprojekten behalten” auf der REConf 2012. Meine Kollegin, Susanne Mühlbauer, und ich vermitteln Ihnen Erfahrungen und Best Practices für den Umgang mit verschiedenen Backlogs und Backlog Items.

Jens Donig

Kontaktieren Sie Jens Donig

Jens Donig ist systemischer Coach (dvct) und Principal Consultant für Software- und Systems- Engineering. Die Schwerpunkte seiner Coaching- und Beratungstätigkeit liegen in den Bereichen Organisationsentwicklung, Teamentwicklung und der persönlichen Entwicklung seiner Kunden. Seit mehreren Jahren beschäftigt er sich mich intensiv mit der nachhaltigen Verankerung von Veränderungsprozessen in Organisationen verschiedener Branchen. Auf Basis des systemischen Coachings, von Transformationsprozessen und agiler Werte und Prinzipien, begleitet er seine Kunden erfolgreich auf ihrem persönlichen Weg der Weiterentwicklung und Veränderung.