Sprint Backlog

Ein Sprint Backlog ist eine Tabelle von Aufgaben innerhalb der agilen Softwareentwicklung bzw. des Scrum, die realisiert werden müssen, um die vorher definierten Ziele des Product Backlog in ein Softwareprodukt zu überführen. Der Sprint Backlog erleichtert somit die Planung der Softwareentwicklung und ermöglicht es, Aussagen über Zeitaufwand und noch zu erledigende Aufgaben zu machen. Der Sprint Backlog als Artefakt in der agilen Softwareentwicklung kommt nach dem Product Backlog; auf den Sprint Backlog folgt eine Burndown Chart.

Allgemeine Informationen

Der Sprint Backlog ist Teil des Scrum: Mit Scrum wird ein Konzept in der agilen Softwareentwicklung beschrieben, das kundenorientiert, flexibel und iterativ ist. Durch genau festgelegte und vorher mit dem Kunden kommunizierte Anforderungen an ein Programmierprojekt und durch den Fokus auf die Wiederholung – Iteration – soll das Softwareprodukt qualitativ besser sein und genau zu den Vorstellungen des Kunden passen. Ein Scrum oder das Konzept der agilen Softwareentwicklung ist von einem spezifischen Programmierparadigma, Frameworks und von Programmiersprachen zu unterscheiden.

Im Scrum können durchaus verschiedene Paradigmen und Sprachen zur Programmierung verwendet werden. Es geht vielmehr um die Organisation der Arbeitsabläufe und eine ständige Überprüfung und mögliche Veränderungen der Arbeitsprozesse, um einerseits den Endanwender der Software und den Kunden zufrieden zu stellen. Der Scrum ist in Phasen unterteilt, die als Artefakte bezeichnet werden. Der Sprint Backlog ist eines von fünf Artefakten.[1]

Funktionen

Ein Sprint Backlog schafft Übersichtlichkeit, indem die zu erledigenden Aufgaben in Segmente unterteilt werden. Sie werden inhaltlich und insbesondere in Bezug zu der Teamorganisation erstellt. Jeder Teil des Teams erhält Aufgaben und notiert auf dem Sprint Backlog, wie viel Zeit für eine Aufgabe benötigt wird. In der Regel werden Stunden angegeben, auch Arbeitstage sind möglich.

Durch die Einteilung in relativ kleine Zeiteinheiten, ist ein guter Überblick über das Projekt und seine Aufgaben sowie Phasen gegeben. Man spricht bei den einzelnen Phasen eines Scrum von Artefakten, weil jede Phase oder alle Phasen zusammen eine ausführbare, getestete Software zum Ergebnis haben sollen.

Die Verantwortung für das Artefakt liegt beim gesamten Team. Die einzelnen Aufgaben sind projektabhängig, jedoch bestehen sie oft aus Teilen wie der Erstellung des Quellcodes für modulare, segmentierte Programmteile, Quellcode für das User Interface, Programmtests oder Fehlerhandling und Help-Funktionen. Jedes Team ist für einen speziellen Bereich zuständig.

Die Aufgaben können zudem priorisiert werden, um die Flexibilität des Projektes zu erhöhen und ggf. die Abläufe aufeinander abzustimmen, wenn bestimmte Aufgaben von anderen abhängen – also ein Team nicht weiterarbeiten kann, bevor die Ergebnisse eines anderen vorliegen. So wird ein Höchstmaß an Agilität und Flexibilität bei der Softwareentwicklung erreicht.[2]

Praxisbezug

Sowohl beim Sprint Backlog als auch bei anderen Artefakten ist es besonders wichtig, das gesamte Team mit in die Prozesse einzubeziehen. Kommunikation ist ein essentieller Teil der agilen Softwareentwicklung. Deshalb werden Meetings anberaumt, um Aufgaben und Teams auf dem Laufenden zu halten. Auch eventuelle Probleme werden so innerhalb der Softwareentwicklung identifiziert. Deshalb ist es auch üblich, den Sprint Backlog während des Sprints – der Erstellung des Codes – zu bewerten und eventuelle Änderungen vorzunehmen. So wissen alle Teammitglieder, an welchem Punkt sich das Projekt gerade befindet und was unter Umständen verändert werden muss.

Dadurch, dass das Scrum-Konzept iterativ und die Verwaltung und Organisation der Aufgaben bzw. Artefakte transparent ist, können einzelne Phasen der Entwicklung wiederholt werden, ohne dass sich die Timeline des gesamten Projektes wesentlich verschiebt oder einzelne Teams nicht weiterarbeiten können.[3]

Bedeutung für das Development

Der Sprint Backlog und andere Artefakte des Scrum in der agilen Softwareentwicklung dienen einer hohen Usability. Der User muss letztendlich mit der Software arbeiten, deshalb orientiert man sich bei dieser Art der Softwareentwicklung auch an seinen Bedürfnissen. Zwar ist der Ansatz beim Scrum ein anderer, als dies beim User Centered Design der Fall ist, jedoch steht auch hier der User im Zentrum.

Der Scrum kommt dem User entgegen, indem auf die User Experience schon implizit während der Entwicklung der Informationsarchitektur in Form von User Stories eingegangen wird: Die Iteration oder Wiederholung soll Fehler beheben, die User Experience steigern und ein hohes Maß an Barrierefreiheit sicherstellen. Gleichzeitig ist der Kunde ein wichtiger Ausgangspunkt, denn er definiert die Anforderungen des Product Backlogs und gibt somit vor, was er sich für sich oder seine User vorstellt.

Einzelnachweise

  1. ↑ Scrum Artefakte. scrum-fibel.de. Abgerufen am 28.04.2014.
  2. ↑ Der Scrum Prozess im Überblick. scrum-fibel.de. Abgerufen am 28.04.2014.
  3. ↑ 9 Tips for Creating a Good Sprint Backlog. scrumalliance.org. Abgerufen am 28.04.2014.

Weblinks


Abgerufen von „https://de.ryte.com/wiki/index.php?title=Sprint_Backlog&oldid=16312“

Kategorie