Denn sie wissen nicht, was sie tun – Den Überblick über

Denn sie wissen nicht, was sie tun –Den Überblick über agile Backlogs behaltenAgile Teams organisieren sich heutzutage mittels Company-, Product-, Sprint-, Release- und persönlichen Backlogs. DieseMenge von unterschiedlichen Backlogs wirft Fragen auf: Was ist Inhalt der einzelnen Backlogs? Wie werden die Backlogs vonwem sinnvoll verwendet? Wie hängen die Backlogs zusammen? Eine Herausforderung ist die Suche nach Lösungen vor allem fürmittlere und große Organisationen, die mit verteilten Teams in Projekten ihre Produkt(weiter)entwicklung agil planen wollen. Indiesem Artikel beantworten wir diese Fragen exemplarisch. Wir liefern Ihnen wichtige Hinweise und Erfahrungen aus der Praxis,damit Sie für sich die richtigen Antworten finden.

fest, welche Werte und Prinzipien aus ihrerSicht für die Softwareentwicklung wichtigsind (siehe Kasten 1). Diese Werte undPrinzipien sind in jedem Umfeld erstrebens-wert und einsetzbar, unabhängig davon, obsich Frameworks wie Scrum nicht 1:1 an -wenden lassen.

Was ist ein Backlog und

welche Backlogs gibt es?

Der Begriff „Backlog“ wird zum Beispiel inder Auftragsverwaltung verwendet undbeinhaltet alle eingegangenen Aufträgegeordnet nach ihrer Bearbeitungs reihen -folge. Über diese Liste werden alle nachfol-genden Prozessschritte, wie Beschaffungund Produktion, geplant und gesteuert.

Das Backlog findet nun in der agilenSoftwareentwicklung analoge Anwendung.Es enthält alle potenziell umzusetzendenBacklog Items, geordnet nach der Reihen -folge ihrer Bearbeitung. Auf Basis dieserListe erfolgt die Planung und Steuerung derUmsetzung.

In der Literatur zu agilen Themen treffenwir auf die verschiedensten Ausprägungendes Begriffes Backlog: Aus Scrum bekanntsind das Product Backlog, das SprintBacklog und das Release Backlog [Sut10],[Sut07]. Ken Schwaber nennt weiterhin ein

durch persönliche Kommunikation zwi-schen dem Team und dem Product Ownervermittelt. Der Product Owner steht jeder-zeit für Fragen zur Verfügung und über-nimmt alle erforderlichen Klärungen. DerPlanungs- und Bearbeitungshorizont wirdauf Entwicklungsiterationen (Sprints) von2-4 Wochen beschränkt. Am Ende jedesSprints steht ein potenziell einsetzbaresProduktinkrement zur Verfügung, dasheißt, der erstellte Teil der Software istgetestet und integriert lauffähig (siehe auch[Sut11]).

Die RealitätIn der Praxis ist es häufig schwer, dieseRah menbedingungen vorzufinden oder zuschaffen. Unternehmen müssen eineVielzahl von Projekten und Produktengleichzeitig durchführen und entwickelnbzw. warten. Es gibt eine Fülle von Teams,die koordiniert werden müssen und vieleOrganisationseinheiten, die involviert sind.Trotzdem ist der Einsatz agiler Methodenauch in einem nicht idealen Umfeld Erfolgversprechend.

Eine gemeinsame Basis für agile Soft -wareentwicklung wurde 2001 durch dasagile Manifest geschaffen. NamhafteVertreter agiler Methoden schrieben darin

Theorie versus Praxis

In der Softwareentwicklung stehen Unter -nehmen täglich vor neuen Herausfor -derungen, ihre Produktentwicklung effi-zient und profitabel zu gestalten. Dabeisind sie auf der Suche nach Lösungen, diesie dabei geeignet unterstützen. In den letz-ten Jahren setzen viele Branchen undUnternehmen unterschiedlichster Größenvermehrt auf den Einsatz agiler Vorgehens -weisen. Betrachten wir jedoch die Voraus -setzungen, die idealerweise für dieVerwendung agiler Methoden vorhandensein sollten, treffen wir diese vor allem inder Wirklichkeit großer Unternehmen nichtoder nur selten an.

Ideale RahmenbedingungenAgile Frameworks, wie beispielsweiseScrum, wünschen sich kleine Teams (3-9Personen), die zusammen an einem Ort sit-zen. Das Team bleibt über die gesamte Pro -jektlaufzeit in der gleichen Konstellationbestehen und hat keine anderen Aufgabenneben dem laufenden Projekt. AlleAnforderungen, die das Team umzusetzenhat, werden von genau einer Person, demProduct Owner, verantwortet. Die Anfor -derungen werden in Form eines ProductBacklogs verwaltet und hauptsächlich

der au tor

Jens Donig

(E-Mail: [email protected])ist Senior Consultant für Systems Engineering bei der HOOD Group.Die Schwerpunkte seiner Beratungstätigkeit liegen in den BereichenRequirements Engineering und agile Softwareentwicklungsprozesse. Seitmehreren Jahren beschäftigt er sich intensiv mit der Analyse und demEntwurf von ALM-Workflows. Mit modellbasierten Methoden schlägt er dieBrücke vom abstrakten Makroprozess zum alltäglichen Arbeitsablauf.

Susanne Mühlbauer

(E-Mail: [email protected])ist Senior Consultant bei der HOOD Group. Neben Beratung im RequirementsEngineering zählen agile Ansätze zu ihren Schwerpunkten. Sie hat langjährigeErfahrung in der Softwareentwicklung und ist u. a. Referentin der REConf,Scrum Day, IEEE RE Conference.

1 www.objektspektrum.de

advertorial

Infrastructure Product Backlog [Sch10]. Inaktuellen Veröffentlichungen finden wirweitere Arten von Backlogs, wie zumBeispiel das Company Backlog [Ren11]oder das Impediment Backlog [Wik11].

Nicht alle diese Begriffe sind eindeutigdefiniert und verwendet. So finden wir bei-spielsweise bei Leffingwell [Lef10] dieBegriffe Portfolio Backlog als Ent spre -chung zum Company Backlog und Pro -gramm Backlog für das Release Backlog. Inunserer Projektpraxis stoßen wir auf weite-re Typen von Backlogs, wie z. B. Service,Deployment und Integration Backlog oderauch das persönliche Backlog. ImFolgenden beschreiben wir daher eineAuswahl dieser Backlogs im Einzelnen undversuchen, diese gemäß unserer Praxis -erfah rungen zu definieren.

1. Das Product BacklogDen Begriff „Product Backlog“ treffenwir vor allem im Scrum-Kontext an.Gemäß Scrum Guide ist das ProductBacklog eine geordnete Liste allerDinge, die in dem Produkt benötigtwerden könnten, und die einzige Quellefür Anforderungen an jegliche Ände-rung des Produktes. Es listet alleFeatures, Funktionen, Anforderungen,Verbesserungen und Bug Fixes auf undhat die Attribute “Beschreibung“,„Reihenfolge“ und „Schätzung“. DieReihenfolge der einzelnen Backlog-Einträge ergibt sich meist aus Wert,Risiko, Priorität und Notwendigkeit.Das Product Backlog enthält also alleAufgaben und Anforderungen, die zurerfolgreichen Realisierung einesProduktes notwendig sind. Das ProductBacklog ist allerdings nicht vollständig,es entwickelt sich vielmehr imProjektverlauf weiter (evolving

Backlog). Neue Einträge kommen hin-zu, andere entfallen. Die Einträge, diean oberster Stelle stehen, werden weiterverfeinert und detailliert. Arbeiten mehrere Teams gemeinsam aneinem Produkt, wird ein gemeinsamesPro duct Backlog geführt. DieZuordnung der Backlog-Einträge zuden Teams erfolgt dabei durch eineGruppierung über ein Attribut.

2. Das Company BacklogDer Begriff „Company Backlog“ wirdhäufig als Synonym für ein gemeinsa-mes Backlog für mehrere Teams ver-wendet. Das Company Backlog bein-haltet jedoch mehr als das.Ein Company Backlog erlaubt es, dieunternehmensweiten strategischenZiele einer Unternehmung mit dengeplanten Pro jekten in Zusammenhangzu bringen. Aus diesem CompanyBacklog werden die einzelnen ProductBacklogs abgeleitet. Zudem kann es fürdie Synchronisation des Pro dukt- undProjektmanagements eingesetzt wer-den. Es dient dann der Priorisierungund Steuerung verschiedener parallellaufender oder parallel zu entwickeln-der Produkte.

3. Das Release BacklogDas Release Backlog dient ebenfallsübergreifenden Planungsaspekten. Esbeinhaltet ein Subset des Product Back -logs, das im nächsten Release geliefertwerden soll, typischerweise mit einemPlanungshorizont von drei bis sechsMonaten [Coh09].Hierfür wählt der Product OwnerBacklog Items aus dem Product Backlogaus und ordnet sie einem Release imRelease Backlog zu. Das Release Backlog

enthält nur die Backlog Items, die auf-grund strategischer Ziele in einem derkommenden Releases realisiert werdensollen. Das Product Backlog hingegenenthält auch Items von niedrigerPriorität, die gegebenenfalls nie zurRealisierung gelangen.

4. Das Sprint BacklogDas Sprint Backlog enthält die Inhaltedes Product Backlogs, die für den näch-sten Sprint ausgewählt wurden, und diePlanung für deren Umsetzung in Formvon Tasks. Es liefert einen Forecast zuden Funktionalitäten, die im nächstenProduktinkrement umgesetzt werdenund enthält alle Aufgaben, die dafürnotwendig sind.

5. Das Integration Backlog (Systemtest)Gerade in der Entwicklung komplexerSysteme, die aus mehreren Teilsystemenbestehen, muss zu jeder Änderung aneinem der Teilsysteme eine Integrationmit den anderen Teilsystemen durchge-führt werden. Da dies nicht in jedemUmfeld (man denke zum Beispiel anmedizinische Geräte oder denSteuergeräteverbund in einem Auto)innerhalb des laufenden Sprints mög-lich ist, müssen die Integrations -aktivitäten zur Durchführung vonSystemtests geplant und gesteuert wer-den. Hierfür kommt ein IntegrationBacklog zum Einsatz.

6. Das Deployment BacklogIst die Auslieferung eines Releases anden Endanwender mit größerem Auf -wand verbunden, kann dieser über einDeployment Backlog geplant werden.Die Inhalte gehen dabei von derBereitstellung von Schulungsmaterialund Trainings über Datenmigration biszum Austausch einzelner Komponentenoder der gesamten Hardware.

7. Das Impediment BacklogDas Impediment Backlog enthält alleaktuell identifizierten Hindernisse, diedas Team bei der Umsetzung seinerArbeit behindern, und steuert bzw.plant deren Beseitigung.

8. Das Service Backlog (Input für Kanban)Das Service Backlog enthält typischer-weise Backlog Items, die zur Planung undSteuerung von Wartungsaspekten undzur Bereitstellung von Services im Rah -

2Online-Themenspecial Agility 2011

Online-Themenspecial Agility 2011 advertorial

Kasten 1: Agile Werte

Backlog Items möglich ist, sind dieseBacklog Items in Tabelle 1 kurz definiert.Sollten Sie in Ihrem Umfeld andereDefinitionen dieser Begriffe vorfinden,können Sie diese entsprechend übertragen.

Backlog Items repräsentieren die Inhalteder Produktentwicklung, die planungsrele-vant sind. Dabei können die Inhalte 1:1von einem Backlog Item abgebildet wer-den, wie zum Beispiel ein Requirementoder ein Test Case. Aber auch durchAttribute in mehreren unterschiedlichenBacklog Items können Informationen dar-gestellt werden, wie beispielsweise ge -schätz ter Aufwand, Nutzen und Risiken.

Weitere Zusammenhänge werden durchBeziehungen zwischen Backlog Items doku-

Aspekte betrachten, die in möglichst vielenProduktentwicklungen relevant sind.Damit können wir Aussagen über dieVerwaltung der agilen Backlogs machen,die sich unabhängig von den Projektrah -men bedingungen leicht adaptieren lassen.Deshalb untersuchen wir die Inhalte derBacklogs – die Backlog Items.

Backlog ItemsEin Backlog Item kann allgemein als Itemdefiniert werden, das in der Produktent -wicklung geplante Ressourcen verbraucht.Typischerweise sind dies neben Require -ment, Feature oder User Story auch Issue,Defect und Testset. Damit ein gleichesVerständnis über die hier verwendeten

men eines SLAs oder OLAs benötigt wer-den. Diese Backlog Items können überKanban-Prozesse abgearbeitet werden.

9. Das persönliche BacklogDas persönliche Backlog einesEntwicklers speist sich aus den Tasks,die er aus dem Sprint Backlog über-nimmt, und allen weiteren Aufgaben,die er zu erledigen hat, die aber nichtim Sprint Backlog enthalten sind. Daskönnen Aufgaben aus anderen Pro -jekten sein, aber auch die Planung per-sönlicher Weiterbildung oder generelleTätigkeiten, wie Stunden nachweiseoder Beantwortung von E-Mails.

Während wir in kleinen Projekten mit nureinem Team mit einem Product Backlog undeinem Sprint Backlog auskommen können,sehen wir, dass in anderen Kontexten eineVielzahl von Backlogs miteinander zusam -menspielen. In einem Scrum-Projekt nach derreinen Lehre sind die Verantwortlichkeitenfür das Product Backlog (der ProductOwner) und das Sprint Backlog (dasDevelopment Team) klar geregelt.

Die Zuordnungen bei einer Vielzahl vonBacklogs, Teams, Projekten und Produktenist aber nicht mehr so einfach möglich.Neben der Verantwortlichkeit für dieInhalte des Backlogs stellt sich dann auchdie Frage, wer die Backlogs letztlich fürPlanungsaspekte verwendet. Diesem As -pekt werden wir uns im Folgenden detail-liert widmen.

Wer plant mit welchen Backlogs?

Zur Klärung der Frage scheint die Analysevon Rollendefinitionen und deren Abbil -dung auf konkrete Personen in einemUnternehmen nahe liegend. Unsere Erfah -rungen zeigen aber, dass die Definitionenvon Rollen je Organisation zum Teil sehrverschieden sind. Auch innerhalb einerOrganisation werden diese Rollen mituntersehr unterschiedlich verstanden und gelebt.

Prozesse, Organisationsform, Branche undProjektgröße sind Dimensionen, die begrün-den, weshalb wir in der Praxis so vielfältigeInstanziierungen von Rollen antreffen. Wirsuchen aber Antworten, die eher allgemein-gültig sind, damit sie auf unterschiedlicheEntwicklungsprojekte übertragen werdenkönnen. Deshalb helfen uns Rollenmodellean dieser Stelle nicht viel weiter.

Sichtenwechsel notwendig!Zur Einordung der agilen Backlogs benöti-gen wir eine andere Sicht. Diese Sicht soll

advertorial


Tabelle 1: Definition von Backlog Items

mentiert. Zum Beispiel kann das BacklogItem Task vom Subtyp Implementation alsChild-Item zu einer User Story angelegtwerden. Die Parent-Child-Beziehung wirdzur Planung und für Reports genutzt.Aussagen über den Stand der Implemen -tierung einer User Story sowie dieDarstellung in einem Burn-Down-Chartsind damit möglich.

Die Liste der oben aufgeführten BacklogItems könnte noch erweitert werden. Undfür einige Zuordnungen müsste imEinzelfall konkretisiert werden, welcheAttribute der Backlog Items für Themenwie beispielsweise Entwicklungskostenoder Projektrisiken genutzt werden.

Lebenszyklen von Backlog ItemsIm Folgenden führen wir noch den Begriffdes Lebenszykus’ eines Backlog Items ein.Darunter verstehen wir die Zustände, dieein Backlog Item von seiner Entstehung biszum Ende haben kann. Damit diese

Zustandsmodelle nicht beliebig definiertwerden, schlagen wir eine an der Wert -schöpfung orientierte Modellierung vor,wie sie von [DON10] beschrieben wird.Das bedeutet, dass der Zustand einesBacklog Items nur dann wechselt, wenn dienächste Reifestufe im Sinne einer erfolgtenWertschöpfung erreicht wurde. Als einBeispiel wird der Requirement-Lebens -zyklus in Kasten 2 dargestellt. Die essen-ziellen Zustände sind als solche gekenn-zeichnet und haben folgende Bedeutung:

Defined: Eine Anforderung hat den Zu -stand "Defined", wenn die Spezifikationder Anforderung vollständig ist und eingemeinsames Verständnis der Stakeholdervorliegt. Dazu muss sichergestellt werden,dass die relevanten Qualitäts kriterien ein-gehalten wurden bzw. mit Abweichungenbewusst umgegangen wird. DieAnforderung ist für die Umsetzungs -planung bereit.

Die Wertschöpfung wird durch die Qualitätder Anforderungs definition erreicht.

Committed: Die Anforderung wurde zurRealisierung durch ein Projektteam com-mitted. Das Projektteam verpflichtet sich,die Anforderung umzusetzen.Die Wertschöpfung wird durch die abge-schlossenen Planungsaktivitäten für dieAnforderung erreicht.

Accepted: Wenn die Akzeptanztests aufBasis der Anfor derung erfolgreich waren,hat die Anforderung den Zustand"Accepted". Werden die Akzeptanztestsnicht bestanden, kann eine weitereUmsetzung (Zustand "Committed") erfol-gen. Die notwendigen Umsetzungen müs-sen noch im selben Entwicklungszyklus(z. B. Sprint oder Iteration) für dieAnforderung realisierbar sein. Ansonstenmüssen die Umsetzung der Anforderungneu geplant und das Com mitment neu ein-geholt werden. Als Umsetzung wird auchein konzeptionelles Lösungskonzept ver-standen, zum Beispiel mit Prototyping. DieAkzeptanztests müssen gegen ein solchesLösungskonzept erfolgen.Die Wertschöpfung wird durch eine vomStakeholder (z. B. Product Owner) akzep-tierte Umsetzung der Anforderung erreicht.

Verified: Wenn die Verification Tests aufBasis der Anforderung erfolgreich waren,ist der Zustand "Verified" erreicht. EineValidierung des Entwicklungsergebnissesist jetzt möglich. Werden die VerificationTests nicht bestanden, wird die Anfor -derung zur erneuten Realisierung in einemnachgelagerten Entwicklungszyklus für dieUmsetzungsplanung bereitgestellt, dieAnforderung ist dann im Zustand"Defined".Die Wertschöpfung wird durch eine vomStakeholder (z. B. Product Owner) akzep-tierte Implementierung der Anforderung imauslieferbaren Produkt erreicht.

Die essenziellen Zustände der BacklogItems sind stabil. Diese Eigenschaft wirddurch die Orientierung an der Wert -schöpfung erreicht. Backlog Items undderen Lebenszyklen sind gleichermaßen aufunterschiedliche Vorgehensweisen undRahmenbedingungen für die Produktent -wicklung übertragbar. Die Skalierungerfolgt meist mit der Auswahl bestimmterItems.

Mithilfe der Lifecycle-Zustände ist esdann sehr gut möglich, genau abzugrenzen,



Kasten 2: Requirement-Lebenszyklus

■ Die Backlogs sind nicht disjunkt, siebilden Vereinigungsmengen, Schnitt -men gen und Teilmengen über BacklogItems.

■ Daraus folgt: Backlogs lassen sich sinn-voll als Sichten auf eine Menge vonBacklog Items verstehen und handha-ben. Sie liefern je nach Kontext einenpassenden Überblick auf die relevantenBacklog Items.

Daraus ziehen wir folgende Schlüsse:1. Sind die relevanten Backlog Items iden-

tifiziert, lässt sich definieren, welcheBacklogs (Sichten) tatsächlich benötigtwerden.

2. Nachdem dann Backlog Items zu mög-lichen Backlogs zugeordnet wurden,

wendige Abstimmungen durch eine doppel-te Datenhaltung vermieden werden.

Weiterhin kann ein Backlog Item, das indem betrachteten Backlog keinePlanungsrelevanz hat, dennoch zusätz-lichen Kontext liefern. Beispielsweise kannbei der Bewertung der User Stories durchdas Scrum-Team die Kenntnis über wichti-ge Issues – die das Team lösen muss – hel-fen, eine realistische Einschätzung über dietatsächliche Kapazität des Teams zu geben(siehe Zeile 9 (Issue) in Kombination mitZeile 4(Sprint Backlog) in Tabelle 2).

Die aufgeführten Backlogs und BacklogItems haben nicht den Anspruch aufVollständigkeit. Und doch sind aus Tabelle 2zwei wichtige Zusammenhänge gut erkenn-bar:

wer welchen Beitrag unter anderem in derPlanungsphase leisten muss. Beispielsweisewird definiert, dass der Product Owner sei-ne Features und User Storys definiert undpriorisiert.

Der Product Owner setzt in dieserKonstellation den Zustand „Defined“ fürseine Backlog Items. Damit dokumentiert erden spätesten Beginn der Planung. EinScrum-Team schätzt die Efforts und muss einCommittment abgeben, wie viele User Storysim nächsten Sprint realisiert werden. Damitdieses und andere Szenarien für agilePlanung transparent und nachvollziehbarablaufen können, brauchen die Beteiligtengemeinsame Sichten auf Backlog Items.

Sichten auf Backlog Items – agile BacklogsÜber die Zuordnung der Backlog Items zuden am Anfang eingeführten Backlogs wol-len wir weitere Aspekte im agilen Backlog-Management aufzeigen. Es werden folgende Verwendungsarten fürein Backlog Item in den Backlogs unter-schieden:

■ temporary: das Backlog Item gehört füreinen Abschnitt seines Lebeszyklus’ inein Backlog und wird für weitereAbschnitte seines Lebeszyklus’ in ande-re Backlogs verschoben

■ partial: nur bestimmte Typen einesBacklogs Items gehören in ein Backlog

■ derived: das Backlog Item wird in ande-re Backlog Items anderer Backlogsabgeleitet

■ parallel: das Backlog Item gehört in einerAusprägung zu mehreren Back logs

■ exclusive: das Backlog Item gehört ineiner Ausprägung ausschließlich nur indieses Backlog

Eine vorgeschlagene Verwendung der Back -log Items in den Backlogs ist in Tabelle 2aufgeführt.

Kritisch beim Zusammenwirken derBacklogs ist vor allem die paralleleVerwendung derselben Backlog Items inmehreren Backlogs (siehe Ziffer 4 inTabelle 2). Für dieses Szenario können dieLebenszyklus-Zustände keine klare Ab -gren zung der Planungsaktivitäten sicher-stellen.

Möglich ist entweder eine Differen -zierung der Planung auf Attribute-Ebeneoder man entscheidet sich, das BacklogItem nur in einem Backlog zu editieren.Letzterer Vorschlag wird von uns favori-siert, da mögliche Inkonsistenzen oder auf-

advertorial


Tabelle 2: Verwendung der Backlog Items in Backlogs

kann je nach individuellem Rollen -verständnis des Unternehmens adaptiertwerden, wer welche Backlog Items/Backlogs bearbeitet und dafür verant-wortlich ist.

3. Der Bürger „erster Klasse“ ist nicht dasBacklog, sondern das Backlog Item.

4. Das Zusammenwirken verschiedenerBacklogs hängt vom Lebenszyklus undder Beziehungen zwischen BacklogItems ab.

Formen des Backlogs

Ein häufiger Diskussionspunkt ist dieFrage, ob ein Backlog elektronisch geführtwerden muss oder ob ein sogenanntes„Backlog Board“ eingesetzt wird. Es gibtfür beide Ansätze ein Für und Wider.

Für ein Backlog Board spricht die hapti-sche Komponente und der unmittelbareZugang zu den Informationen. BeimKonzept des Boards werden alle BacklogItems in Form von Karten auf einerPinnwand angeordnet. Die Pinnwand istfür alle einsehbar und die Planung wirddurch das Anordnen der Karten gemeinsamam Board durchgeführt. Diese Form derBacklog-Organisation funktioniert fürTeams, die gemeinsam an einem Ort sitzen.Alle anderen Personen, die sich über dieInhalte eines Backlogs informieren wollen,müssen jedoch ebenfalls physisch anwe-send sein.

Vorteil eines elektronischen Backlogs ist,dass die Beteiligten unabhängig von ihremphysischen Aufenthaltsort darauf zugreifenkönnen. Weiterhin bietet es die Mög -lichkeit, unterschiedliche Sichten auf dieInhalte zu generieren und die Inhalte nachverschiedenen Aspekten zu gruppieren. Vorallem bei vielen Einträgen ist dies mit einemelektronischen Backlog weitaus einfachermachbar als durch das Umordnen vonKarten an einem Board. Ein weitererVorteil ist die Versionierung des Backlogsund die Möglichkeit, die Historie desBacklogs und dessen Einträge nachvollzie-hen zu können. Auch hier bietet einelektronisches Backlog Vorteile gegenüberdem Abfotografieren eines Backlog Boards.

In der Praxis sehen wir, dass sich eineKombination der beiden Formen anbietet.Für Arbeiten in der Gruppe ist dem physi-schen Backlog Board Vorzug zu geben, fürDokumentation und Analysearbeiten istdas elektronische Backlog besser geeignet.

Ebenso ist die Überlegung einzubeziehen,ob es sich um ein strategisches oder ein ope-ratives Backlog handelt. So kann für das

Sprint Backlog ein Board eher ausreichendsein, wohingegen für die unternehmensweitePlanung ein Company Backlog besser inelektronischer Form vorliegen sollte.

Zusammenfassung

Agile Entwicklung ist in aller Munde undauch mittlere und große Organisationenwollen ihre Entwicklungsprojekte mit agi-len Vorgehensweisen ausstatten. Diesmacht ein Umdenken erforderlich. DieRahmenbedingungen, die zum Beispieldurch ein Framework wie Scrum definiertwerden, trifft man im Alltag großerEntwicklungsorganisationen sehr selten an:

■ Entwickler arbeiten zeitgleich in meh-reren Projekten.

■ Entwicklungsteams sind auf unter-schiedliche Standorte und Zeitzonenverteilt.

■ Ein auslieferbares Release muss durchZulieferung vieler Teams erstellt werden.

Die unterschiedlichen Ausprägungen derDimensionen Prozesse, Organisationsform,Branche und Projektgröße zeigen, wie viel-fältig die Produktentwicklung gestaltet ist.Darauf basierende Rollenmodelle undderen Instanziierung bieten daher keineguten Wege, mit dieser Vielfalt umzugehen.

Betrachten wir abschließend nochmalsden Lebenszyklus einer Anforderung.

Die Anforderung wird erhoben, wirddann angemessen definiert, dann für dieUmsetzung geplant, umgesetzt und derNachweis wird erbracht, dass die geforder-te Charakteristik im Produkt enthalten ist.Das Backlog Item heißt „Requirement“.Der Lifecycle liefert konstante Ergeb -niszustände. Jetzt muss einfach entschiedenwerden, in welchen Backlogs dieseZustände dokumentiert werden.

Beispielsweise könnte die Erhebung imCompany Backlog erfolgen und dann zurweiteren Detaillierung in ein ProductBacklog verschoben werden. Die Umset -zungsplanung kann in unterschiedlichenEbenen erfolgen: Produktplanung imProduct Backlog, Releaseplanung imRelease Backlog und für den Sprint ist die-se Anforderung Input für die Selbst -organisation des Projektteams.

Die Planung für den Nachweis derRealisierung kann dann entweder im Sprintselber durch Akzeptanztests oder imIntegration Backlog erfolgen. Letztereswird vor allem dann relevant, wenn einauslieferbarer Stand nur durch Zulieferungvieler Teams erstellt werden kann.

Unsere Empfehlung ist, planungsrelevan-te Inhalte, also letztlich die Backlog Items,für die Entscheidung, wie mit unterschied-lichen Backlogs gearbeitet werden soll, her-anzuziehen. Die Backlog Items und ihreLebenszyklen sind im Gegensatz zu Rollenleicht adaptierbar. Sie können sich darauffokussieren, wie mit einem Backlog Item inder Entwicklung umgegangen wird undadaptieren die Ergebnisse auf beliebigeProjektformen.

So behalten Sie den Überblick und kön-nen klar trennen, wann welche BacklogItems (in welchem Zustand) geplant wer-den müssen. Welche Backlog -„Sichten“ Siefür Ihre Planung nutzen wollen, muss inizi-al definiert werden – einschließlich derZuordnung der relevanten Items. Darausergibt sich dann ein „natürliches“ Zusam -menspiel der Backlogs, weil stabile und ein-deutige Lebenszyklen der Backlog Itemsleicht verständlich sind und die agilePlanung unterstützen. ■

www.HOOD-Group.comwww.agiles-Backlogmanagement.de



Literatur & Links

[Don10] J. Donig, Dr. M. Künzle, Navigationsbesteck für Workflows – Teil 1: Arbeitsabläufe inder Softwareentwicklung optimieren, in: OBJEKTspektrum 06/2010[Sut11] J. Sutherland, K. Schwaber, The Scrum Guide, www.scrum.org, 2011[Sut07] J. Sutherland and K. Schwaber, The Scrum Papers: Nuts, Bolts, and Origins of an AgileMethod. Boston: Scrum, Inc., 2007[Sch10] K. Schwaber, Training Material Professional Scrum Master, [email protected], 2010[Coh09] M. Cohn,http://blog.mountaingoatsoftware.com/why-there-should-not-be-a-release-backlog/2009

[Lef10] D. Leffingwell, Agile Software Requirements, Addision Wesley, 2010[Agi01] Agile Manifesto, http://agilemanifesto.org/iso/de/, 2001[Ren11] Scrum of Scrums im Produktmanagement,http://www.renemt.de/2011/01/11/scrum-of-scrums-im-produktmanagement/, 2011[Wik11] http://de.wikipedia.org/wiki/Scrum#Impediment_Backlog, 2011

Documents

Denn sie wissen nicht, was sie tun – Den Überblick über