Was ist ein Sprint-Aufgaben-Board

---

Was ist ein Sprint-Aufgaben-Board?

Ein Sprint-Aufgaben-Board ist ein Zeitfenster. Jeder Sprint hat einen Start- und Endtermin, innerhalb dessen eine ausgewählte Reihe von Benutzerstories abgeschlossen und bestätigt werden müssen. Das folgende Bild zeigt Ihnen die wichtigsten Elemente eines Sprints, darunter eine Reihe von Benutzerstories, die beteiligten Scrum-Mitglieder, die Aufgabenverteilung, die Dauer und das Enddatum (oben rechts).

Zu Beginn eines Sprints treffen sich der Product Owner, die Stakeholder und das Entwicklungsteam, um die Benutzerstories zu priorisieren und anschließend diejenigen auszuwählen, die im Sprint abgeschlossen werden sollen. Da verschiedene Parteien unterschiedliche Präferenzen, Überlegungen und Bedenken hinsichtlich des Projekts und des Projektzeitplans haben, dient das Treffen dazu, den verschiedenen Teilnehmern die Möglichkeit zu geben, die Ansichten der anderen zu hören und zu verstehen, und gemeinsam eine Reihe von Benutzerstories zu finden, die von allen Parteien akzeptiert wird.

Sprint-Dauer

Die schnelle Lieferung qualitativ hochwertiger Arbeit ist einer der Gründe, warum Software-Teams agile Methoden in der Softwareentwicklung übernehmen möchten. Daher, obwohl es keine universell geeignete Dauer für Sprints gibt, wird allgemein vereinbart, dass die Dauer so kurz wie möglich sein sollte. Aber wie kurz sollte sie sein?

Während eine lange Sprint-Dauer nicht bevorzugt wird, kann eine unangemessen kurze Sprint-Dauer die Motivation des Entwicklungsteams zur Erledigung bedeutender Aufgaben schwächen oder sogar zu einer schlechten Qualität der Lieferungen führen.

Die Auswahl der Sprint-Dauer ist daher das Ergebnis einer Diskussion innerhalb des gesamten Teams – Product Owner, Scrum Master und Scrum-Mitglieder wie Datenbank-Designer, Programmierer, UX-Designer, Tester, Analysten usw. Doch letztendlich muss jemand eine Entscheidung treffen. Zu diesem Zeitpunkt ist der Scrum Master in der Regel derjenige, der die Antwort gibt.

Traditionell dauert ein Sprint drei Wochen bis einen Monat, aber heutzutage haben immer mehr Teams mit zweiwöchigen Sprints Erfolg. Insgesamt gibt es immer noch keine feste Auswahl für die Sprint-Dauer. Ein guter Scrum Master verfügt über kollaborative und facilitative Fähigkeiten, um die Sprint-Dauer zu bestimmen, um sicherzustellen, dass die Arbeiten wie erwartet abgeschlossen werden. Hier sind einige Faktoren, die ein Scrum Master berücksichtigen kann:

1. Vereinbarter Projektzeitplan
2. Verfügbarkeit von Kunden/Stakeholdern/Product Owner (der potenzielle Zweifel klären kann)
3. Arbeitskultur der Kunden
4. Fähigkeit des Scrum-Teams
5. Scrum-Erfahrung

Sobald das Team eine Einigung erzielt hat, werden alle zukünftigen Sprints die gleiche Sprint-Dauer beibehalten, ohne sie häufig von Sprint zu Sprint zu ändern. Dennoch ist es eine gute Praxis für das Scrum-Team, die Effektivität des Sprints regelmäßig zu überprüfen und eine optimale Sprint-Dauer zu finden, die für alle am besten geeignet ist.

Bestätigung von Arbeiten (Benutzerstories) im Sprint

Die Entwicklungsaktivitäten richten sich nach Beginn eines Sprints um die Benutzerstories, und je weiter der Sprint fortschreitet, desto mehr Benutzerstories werden umgesetzt. Doch die vollständige Umsetzung einer Benutzerstory ist noch nicht das Ende der Geschichte. Es gibt noch einen wichtigen Schritt, der durchlaufen werden muss – die Bestätigung.

Eine Benutzerstory zu bestätigen bedeutet, die implementierte Funktion auszuprobieren und zu entscheiden, ob sie wie erwartet umgesetzt wurde. Die Beurteilung sollte ausschließlich auf den Kriterien basieren, die bei der Detailierung der Benutzerstories festgelegt wurden und in Form von Bestätigungs-Elementen formuliert sind. Während der Bestätigung erhält der Product Owner eine Testumgebung oder ein Gerät, um die umgesetzte Arbeit zu testen. Der Product Owner geht die auf der Benutzerstory aufgeführten Bestätigungs-Elemente nacheinander durch. Wenn alle Elemente als abgeschlossen bestätigt werden, gilt die Benutzerstory als bestätigt. Falls ein Element als nicht abgeschlossen oder nicht wie erwartet funktionierend erkannt wird, fordert der Product Owner das Entwicklungsteam zur Korrektur auf. Der Korrektur- und Bestätigungsprozess wird wiederholt, bis die Benutzerstory vollständig bestätigt ist.

Wann soll bestätigt werden?

Der Sprint – und tatsächlich das Agile – ist ein kontinuierlicher Lieferprozess. Statt die Benutzerstories am Ende eines Sprints zu bestätigen, sollte die Bestätigung unmittelbar nach der Fertigstellung jeder Benutzerstory erfolgen. Falls der Product Owner jedoch nicht an der kontinuierlichen Bestätigung teilnimmt, können wöchentliche Treffen mit einer Dauer von jeweils 1 bis 2 Stunden organisiert werden. Während des Treffens arbeitet der Product Owner mit dem Team zusammen, um die abgeschlossenen Benutzerstories zu bestätigen. Das Treffen beinhaltet auch eine Diskussionsrunde, in der Unklarheiten, die bei der Umsetzung der anderen im Sprint enthaltenen Stories aufgetreten sind, geklärt werden.

Bestätigung ist nicht gleichbedeutend mit Testen

Wie bereits gesagt, dient die Bestätigung dazu, sicherzustellen, dass die Benutzerstory korrekt umgesetzt wurde. Die Beurteilung basiert ausschließlich auf den Kriterien, die als Bestätigungs-Elemente bei der Detailierung der Benutzerstory festgelegt wurden, weder mehr noch weniger. Die Umfang der Überprüfung ist weit davon entfernt, sicherzustellen, dass die Funktion für den produktiven Einsatz bereit ist. Wann also sollte ein „echtes Testen“ durchgeführt werden?

Verschiedene Teams haben unterschiedliche Praktiken im Bereich Software-Testing. Einige Teams bevorzugen ein Sprint-Test, bei dem Tests wie Integrationstests und Regressionstests am Ende eines Sprints durchgeführt werden. Andere Teams bevorzugen die Einrichtung eines Stabilisierungssprints, wie der Name schon sagt, zum Testen und Beheben von Fehlern. In diesem Sprint werden keine neuen Entwicklungstätigkeiten durchgeführt.

Unabhängig davon, welche Methode Sie wählen, denken Sie daran, dass die Entscheidung nicht die eines einzelnen, sondern die aller ist.

Visual Paradigm bietet alle Tools, die Sie benötigen für agile Softwareentwicklung, darunter UML-Use-Case-Diagramm-Tool, (agil) Nutzerstory, Sprint, Storyboard und Wireframes für UX-Design, Aufgabenverwaltungstool, usw.