Agil, Projektmanagement, Softwareentwicklung

Artefakte und Events in Scrum

Geschätzte Lesezeit: 5 Minuten


Im dritten und letzten Teil unserer Blogartikelserie stellt sich die Frage: Wie funktionieren die Events in Scrum und was für Artefakte gibt es?

Das endgültige Projektziel ist bei Entwicklungsprojekten nicht vollständig planbar. Aus diesem Grund ist eine andere Vorgehensweise bei als klassische Projektplanung angebracht. Am Anfang steht daher die Projektvision. Diese umfasst den Zweck und das Ziel des Projektes, sowie eine Beschreibung des Kontextes: Es ist eine Grundvorstellung, der der Product Owner grobe Anforderungen zuordnet. Die aus der Projektvision resultierenden Aufgaben und Anforderungen werden im Product Backlog festgehalten. Da Transparenz ein essentieller Wert von Scrum darstellt, ist es wichtig, dass alle Beteiligten oder Interessierten auf dieses Dokument Zugriff haben.

Die Verfeinerung der Anforderungen erfolgt im nächsten Schritt über User-Stories. Beispielsweise können in eine User-Story die Erfahrungen von Anwendern als auch von Stakeholdern einfließen. Auf diesem Weg entsteht Klarheit über zu programmierende Anforderungen und Aufgaben. Dies ermöglicht dem Entwicklerteam anwenderfreundliche Nutzerinterfaces zu entwickeln.

Was sind die Scrum-Artefakte?

Nun kommen die Artefakte und Aktivitäten ins Spiel. Diese sind voneinander abhängig. Wichtig ist zu erwähnen, dass alle Aktivitäten von Scrum zeitlich begrenzt sind und nicht verlängert werden dürfen. Dies wird durch den Scrum Master kontrolliert.

Das Product Backlog ist eine Liste, die alle notwendigen User-Stories enthält. In ihr sind somit auch alle Anforderungen an die Module der zu erstellenden Software aufgeführt. Diese Liste ist dynamisch und kann jederzeit durch den Product Owner geändert und ergänzt werden.

Bei großen Projekten sind in der Applikation viele User-Stories zu programmieren. Die Aufgaben haben eine unterschiedliche Priorität. Der Product Owner klärt mit dem jeweiligen Entwicklerteam die Beschreibung, Anforderungen und Hinweise der jeweiligen Aufgaben, um vor Allem ein gemeinsames Verständnis der Aufgabenstellung zu schaffen. Das Entwicklerteam schätzt den Arbeitsaufwand ein, den die jeweiligen Schritte benötigen. An dieser Stelle ist es wichtig zu erwähnen, dass Scrum eine große Toleranz hinsichtlich Anforderungsänderungen im laufenden Projekt aufweist. Dies garantiert Flexibilität angesichts undurchsichtiger Projektbedingungen.

Was ist ein Sprint?

Und was verstehen wir nun unter einem Sprint? Der Sprint ist ein zeitlich beschränkter und regelmäßiger Entwicklungszyklus, auf den weitere Entwicklungszyklen folgen können. Er dauert typischerweise zwischen einer und 4 Wochen. Am Anfang eines jeden Sprints erfolgt die Sprint-Plannung. Hier werden die Anforderungen, die sich im Product Backlog befinden, in Aufgaben aufgeteilt und offene Detailfragen geklärt. Diese strukturieren die Projektbeteiligten so, dass die entsprechenden Programmierungen in möglichst kleinen Arbeitspaketen vorliegen.
Ziel des Entwicklerteams innerhalb eines Sprints ist die Erstellung eines Zwischenproduktes. Das ermöglicht den Beteiligten, einen Überblick über den Fortschritt zu erhalten und kontinuierliches Feedback einfließen zu lassen. Das entwickelte Inkrement wird auch „Minimum Marketable Feature“ genannt: dieser Begriff beschreibt ein Mindestmaß an Funktionalität, sodass das Produkt einen Nutzen für die potentiellen Anwender beinhaltet. Dementsprechend kann der Product Owner prinzipiell nach jedem Sprint entscheiden, ob er dieses Produkt vermarkten möchte.

Um jedoch Abstimmungsfehler nach Beginn des Sprints zu verhindern, erfolgt der tägliche Daily Scrum. Dieser dauert maximal 15 Minuten. Während dieser Zeit besprechen die Mitglieder des Entwicklerteams die Ergebnisse des letzten Tages. Sie berichten über die Fortschritte und Probleme, die sich ergeben haben. Strukturieren lässt sich ein solches Event mit folgende Fragen: Welche Fortschritte habe ich gestern gemacht? Was werde ich heute machen? Was hindert mich an meiner Arbeit?

Am Ende des Sprints folgt das Sprint Review. Hier wird von dem Product Owner, den Stakeholdern und dem Entwicklerteam besprochen, was innerhalb des Sprints gemacht wurde. Das ist der Zeitpunkt, auf den alle Beteiligten lange hingearbeitet haben. Ziel ist es, das Produkt zu präsentieren, sowie die Funktionalität des Zwischenproduktes zu überprüfen, Feedback einzuholen und die nächsten Schritte zu besprechen, durch die der Wert des Produktes weiter gesteigert werden kann. Im Rahmen der Rücksprache mit dem Product Owner sowie den Stakeholdern diskutiert man mögliche Anpassungen des Product Backlogs für den nächsten Sprint.

Zur Reflektion gehört auch das Sprint Retrospective mit allen Beteiligten. Es geht darum die Zusammenarbeit Revue passieren zu lassen und Optimierungspotential zu analysieren, um dies im nächsten Sprintzyklus anzuwenden. Letztendlich steht am Ende des Prozesses, als Resultat von intensiver Arbeit und Kooperation, die releasefähige Anwendersoftware, die dem Kunden übergeben werden kann.

Und was ist dann agiles Projektmanagement mit Kanban?

Eine mit Scrum vergleichbare Vorgehensweise ist Kanban. Kanban kann in das Scrum-System eingebettet werden. Es ist aber auch eigenständig lauffähig.

Bei Kanban werden die Arbeitsschritte der Programm-Applikation in kleinere Anforderungen aufgeteilt. Diese werden auf dem Kanban Board mithilfe von Tickets visualisiert. Auf dem Kanban Board werden diese Tickets anhand ihres Status kategorisiert, sodass der Bearbeitungsstatus jeder Aufgabe für alle Beteiligten übersichtlich dargestellt wird. Traditionelle Kanban Boards sind mit drei Spalten ausgestattet, wobei die erste Spalte beschreibt, welche Aufgaben noch zu erledigen sind. In der nächsten Spalte befinden sich die Aufgaben, welche gerade in Bearbeitung sind und die letzte Spalte beinhaltet abgeschlossene Aufgaben. Hier ist allerdings zu erwähnen, dass, ähnlich wie Scrum, Kanban über ein flexibles Regelwerk verfügt und individuell an das Projekt angepasst werden kann. Angestrebt ist der sogenannte „Flow“: Die Kanban Tickets wandern in Abhängigkeit von dem jeweiligen Bearbeitungsstand von der ersten Spalte in die Letzte. Auf diese Weise ist ein kontinuierlicher Fortschritt sichergestellt.

Da die Anzahl an Ticket pro Anforderung begrenzt ist, kann beispielsweise die Programmierung nur so viele Tickets bearbeiten, wie ihr durch das System zugeordnet werden. Über Pullstations müssen sich die nachfolgenden Stationen ihre Arbeit abholen, statt sie unaufgefordert zu erhalten.

Ähnlich wie Scrum, haben die Mitarbeiter viel Verantwortung inne: Sie berechnen selbständig die Warteschlangen für die Aufträge sowie die Zykluszeiten des Auftrages.

Wo gibt es aktuelle Events zum Thema Scrum und agiles Management?

Zu Scrum gibt es eine Reihe von Institutionen, zum Beispiel Scrum.org, Scruminc, Scrum Alliance und der TÜV Süd, die auf Scrum und agiles Projektmanagement aufmerksam machen. Zudem bieten diese vielseitigen Veranstaltungen an, unter anderem können Sie sich dort zu einem Professional oder Certified Scrum Master, Scrum Product Owner oder Scrum Developer ausbilden und zertifizieren lassen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.