Teil 1 der kleinen Serie zur Detailbetrachtung von Scrum finden Sie >hier<
Innerhalb des Scrumprozesses werden folgende unterschiedliche Scrum Artefakte definiert: Das Product Backlog, das Sprint Backlog und das Impediment Backlog.
Die einzelnen Backlogs im Detail
1. Product Backlog
Das Product Backlog dient der Erfassung aller Anforderungen an das zu erstellende Produkt. Hier werden alle Anforderungen (technischer als auch fachlicher Art), Features und Tätigkeiten (wie beispielsweise Deployment) aufgeführt, und in strenger Reihenfolge nach Wichtigkeit (Return on Investment) aufgelistet. Das Product Backlog wird geführt und gepflegt vom Product Owner. Das Team ergänzt die eingepflegten Einträge um Schätzungen (Story Points) und verwendet das Product Backlog für die Sprint- bzw. Releaseplanung. Hierbei gilt, dass nur vollständig beschriebene Features in den Planungsmeetings berücksichtigt werden können.
Bugs und aufgetretene Fehler landen ebenfalls im Product Backlog. Jeder Bug gilt als „Feature“ und die Behebung wird gleichberechtigt mit anderen Features vom Product Owner priorisiert und vom Team abgearbeitet.
Zusätzlich zur Beschreibung der Anforderung sollten pro Backlog Eintrag die jeweiligen Akzeptanzkriterien aufgeführt werden, nach denen die jeweilige Anforderung vom Product Owner abgenommen wird.
2. Sprint Backlog
Die Auswahl der Product Backlog Items, an denen im aktuellen Sprint gearbeitet wird, nennt sich Selected Product Backlog. Diese Auswahl wird am Anfang des Sprints gemeinsam mit dem Product Owner erstellt.
Das Sprint Backlog enthält die jeweiligen Aufgaben der Selected Product Backlog Items, die das Team im aktuellen Sprint erledigen muss.
Die Abarbeitung der Aufgaben erfolgt innerhalb des Sprints und dessen Visualisierung erfolgt mit Hilfe eines Taskboards, wo eine Aufgabe nur drei Statusausprägungen haben darf: „ToDo“, „In Progress“, „Done“.
Der Aufwand pro Aufgabe sollte kleiner gleich einem Arbeitstag sein, um einen Fortschritt im Daily Scrum Meeting bzw. eine Bewegung auf dem Taskboard sichtbar zu machen. Die zugrundeliegende Zeitschätzung wird vom Team vorgenommen und im Rahmen des Sprint Planning Meetings diskutiert.
3. Impediment Backlog
Das Impediment Backlog wird geführt vom Scrum Master und beinhaltet alle Hindernisse und Probleme, die nicht vom Team selbst gelöst werden können bzw. zu deren Behebung das Team den Scrum Master benötigt. Diese Liste kann kategorisiert und priorisiert geführt werden. Die Aufgabe des Scrum Masters ist die Behebung aller Impediments, sodass das Team effektiv weiterarbeiten kann. Das Impediment Backlog wird genauso wie das Sprint Backlog im Daily Scrum Meeting aktualisiert und der jeweilige Status kommuniziert.
In der Praxis
Eine aktuelle Untersuchung von VersionOne (State of Agile Survey – The state of agile development) aus dem Jahre 2010 zeigt, dass Scrum und dessen Featureerfassung vor allem für die Bereiche „Accelerate Time to Market“ und „Enhance Ability to Manage Changing Priorities“ genutzt wird (vgl. [VisionOne]). Die Verwaltung des Product Backlogs und deren Priorisierung durch den Product Owner stellen somit große Anforderungen an das Projekt.
Bei der Erfassung der Product Backlog Items sollte beachtet werden, dass die Anforderungen klar genug beschrieben sind. Hierfür bieten sich folgende Beschreibungsarten an: Die Software Requirements Specification IEEE 830 oder die SMART Definition für die eindeutige Beschreibung der Ziele (vgl. [IEEE 830], [SMART]). Alternativ dazu, kann ein gut beschriebenes Feature auch als User Story mit Hilfe der INVEST Kriterien erstellt werden (vgl. [Vaibhav]). Hierfür bietet sich folgendes User Story Template an: Als <Benutzer/ Benutzerrolle> möchte ich die <Funktion> haben, so dass ich folgenden <Nutzen> erhalte.
Die generelle Erfassung der Anforderungen kann auch als separater Sprint ausgelagert werden, in dem nur die Definition und Beschreibung der Features als Initialphase durchgeführt wird: „Es kann empfehlenswert sein, selbst diese Aufgaben als Sprints zu organisieren oder aber auch eine Initialphase von einigen Tagen/Wochen einzulegen, die Scrum losgelöst ist und das initiale Product Backlog organisiert. Sollten sich die ersten Anforderungen mit geringem Zeitaufwand beschreiben lassen, kann auch zunächst mit einem sehr kleinen Team gestartet werden und dieses abhängig von den weiteren Anforderungen, die noch formuliert werden, aufgestockt werden. Dies ist vom Product Owner zu entscheiden.“ (vgl. [Scrum Kompakt])
Literatur:
[VisionOne] State of Agile Development Survey Results von VisionOne [2011]
[IEEE 830] Software Requirements Specification von Wikipedia [Februar 2011]
[SMART] SMART (Projektmanagement) von Wikipedia [Januar 2011]
[Scrum Kompakt] Anforderungsaufnahme und deren Dokumentation von Scrum Kompakt [2011]
[Vaibhav] Six Features of a Good User Story – INVEST Model von Vaibhav [Oktober 2007]