Agile Softwareentwicklung mit Scrum

Ein Überblick über den vorherrschenden Ansatz zur Entwicklung moderner Softwaresysteme und -anwendungen, warum er so beliebt ist und wann er verwendet werden sollte und wann nicht.

Agile • UPDATED ON August 28, 2023

John Adam

Author

Translated by:

Patrick Böllhoff

Das Scrum-Framework ist der beliebteste Ansatz der allgemeinen agilen Methodik, die die Softwareentwicklung in den letzten zwei Jahrzehnten maßgeblich geprägt hat. Aufgrund der starken Zersplitterung des Marktes sind verlässliche Statistiken nur schwer zu bekommen, doch ist bekannt, dass die große Mehrheit der Softwareentwicklungsteams einen Projektmanagementansatz verwendet, der als eine Form von „Agile“ beschrieben wird.

Der kürzlich erschienene 15. „State of Agile“-Bericht ergab, dass 94 % der Unternehmen, für die die 1382 internationalen Befragten arbeiteten, „Agile“ eingeführt haben. Von denen die eine Variante der agilen Methodik auf Teamebene anwandten, gaben 66 % an, dass sie dies mit Hilfe eines Scrum-Frameworks taten.

Damit ist Agile mit Scrum der im Jahre 2021 mit Abstand am häufigsten verwendete Ansatz für die Softwareentwicklung. Die Bedeutung des Scrum Frameworks für die moderne Softwareentwicklung wird noch deutlicher, wenn man bedenkt, dass weitere 15 % der Befragten andere enge Ableitungen von Scrum verfolgen.

9 % gaben an, dass ihr Team nach „ScrumBan“ arbeitet, einem Mischkonzept, das Scrum- und Kanban-Elemente miteinander verbindet. Und weitere 6 % Scrum/XP, eine Kombination aus Scrum und „Extreme Programming“ (XP).

Wenn Sie nur einen Ansatz für den Softwareentwicklungsprozess und das Projektmanagement wählen dürften mit dem Sie sich vertraut machen sollten, dann wäre es der Scrum-Ansatz. Scrum ist ein hervorragender Einstieg in die Theorie der agilen Softwareentwicklung und die speziellen Prozesse und Schritte, die von den verschiedenen Frameworks eingeführt werden, die unter den Oberbegriff der agilen Methodik fallen.

Wie ist das Scrum Framework in die agile Methodik einzuordnen?

Kurz gesagt, der Unterschied zwischen einer Methodik und einem Framework liegt in ihrem Abstraktionsgrad von der eigentlichen Tätigkeit. Deren Aufgabe besteht darin die Softwareentwicklung optimal zu planen und zu verwalten.

Wir könnten den Unterschied zwischen einer Methodik und einem Framework erkunden und diskutieren. Ob „Agile“ technisch gesehen wirklich eine Methodik ist oder Scrum ein Framework, sei dahingestellt. Das sollte den Akademikern sowie den Leuten, die ihre Bücher darüber verkaufen müssen überlassen werden.

Die „Agile Alliance“ definiert den agilen Ansatz zur Softwareentwicklung wie folgt:

„… ein Oberbegriff für eine Reihe von Frameworks und Praktiken, die auf den Werten und Prinzipien basieren, die im Manifesto für Agile Softwareentwicklung und den dahinter stehenden 12 Grundprinzipien zum Ausdruck kommen.“

Das ist die allgemein anerkannte Definition in der Community der Softwareentwickler. Die agile Softwareentwicklung weist über alle Implementierungsrahmen hinweg vier grundlegende Charakteristiken auf:

Das Team

Agile konzentriert sich auf das Softwareentwicklungsteam als autonome Einheit, deren Ziel die Erstellung eines leistungsstarken Softwaresystems ist.

Periodische Entwicklung

Softwaresysteme werden auf der Grundlage von Benutzerdaten und Feedback ständig verbessert, und nicht als “ Fertigprodukte “ freigegeben, deren Erfolg davon abhängt, dass in einer einmaligen Planungs- und Analysephase keine falschen Annahmen getroffen werden.

Stufenweise Entwicklung

Jede nachfolgende Version eines Softwaresystems, die mit einem öffentlich oder im Beta-Stadium getesteten MVP beginnt, ist nutzbar und baut auf der vorherigen Version auf, indem sie für den Benutzer sichtbare Funktionen hinzufügt.

Kontrolle der Varianten (Versionen)

Die Nachverfolgung und Verwaltung von Änderungen am Softwarecode. Software-Tools zur Versionskontrolle werden verwendet, um jede Änderung am Code in einer speziellen Datenbank zu dokumentieren. Wenn ein Entwickler einen Fehler macht, kann er auf die Datenbank zugreifen, den Code mit älteren Versionen vergleichen und ihn korrigieren, ohne andere Mitarbeiter bei ihrer Arbeit zu stören.

Scrum hingegen beschreibt unter dem Oberbegriff der 4 Werte, 12 Prinzipien und 4 Grundlagen der Methodik eines agilen Softwareentwicklungsteam:

• was wird umgesetzt
• in welcher Reihenfolge
• durch wen
• und wie

Scrum ist flexibel und vermeidet aktiv strenge Vorschreibungen, ist aber in seinem Abstraktionsgrad näher an der praktischen Ausführung einer Softwareanwendung. Scrum definiert bestimmte Aspekte des Softwareentwicklungsprozesses, darunter die Rollen des Teams, die Phasen des Entwicklungslebenszyklus, die Einteilung der Entwicklungszyklen in stufenweise „Sprints“ und eine Handvoll festgelegter Praktiken, wie z. B. tägliche Stand-up-Meetings.

Eine kurze Geschichte zum Scrum Frameworks

Das Scrum Framework wurde erstmals 1995 in Ken Schwabers Dokument The Scrum Development Process beschrieben und feierte sein öffentliches Debüt auf der Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) Conference ‘95 in Austin, Texas, wo es von dem Autor Jeff Sutherland mitpräsentiert wurde.

Sutherland hatte zusammen mit seinen Kollegen Jeff McKenna und John Scumniotales bereits ein Scrum-Framework für Softwareentwicklungsteams bei der Easel Corporation eingeführt, einem erfolgreichen Softwareentwicklungsunternehmen, das Mitte der 1990er Jahre von VMARK übernommen wurde.

Der Scrum Master beschreibt, wie die drei Kollegen der Easel Corp. durch den im Jahre 1986 in der Harvard Business Review veröffentlichten Artikel The New New Product Development Game von Hirotaka Takeuchi und Ikujiru Nonaka inspiriert wurden. In dem klassischen Artikel wurde ein neuer ganzheitlicher Ansatz zur Innovation skizziert. Er verglich ihn mit dem Rugby-Sport, bei dem die gesamte Mannschaft „versucht, als Einheit auf die Distanz zu gehen und den Ball vor und zurück zu spielen„.

Der Name Scrum (engl. für Gedränge) leitet sich von der Spielweise im Rugby ab, bei der die gesamte Mannschaft ihre Kräfte bündelt, um Boden zu gewinnen.

Photo credits: Quino AI

Scrum ist somit sechs Jahre älter als das Agile Manifesto. Das 2001 veröffentlichte Agile Manifest, ist für die Softwareentwicklungsbranche des 21. Jahrhundert zum Äquivalent der Zehn Geboten geworden. Dies geschah, nachdem Sutherland und Schwaber mit fünfzehn weiteren Kollegen zu einer Arbeitstagung in Snowbird, Utah, zusammengekommen waren.

In den 25 Jahren seit der Veröffentlichung von Schwabers Arbeit über Scrum und 20 Jahren seit der Erstellung des Agile Manifestos haben Schwaber und Sutherland das Scrum-Framework erfolgreich als die vorherrschende Methode zur Erstellung von Software durch hochleistungsfähige Teams popularisiert.

Mike Cohns Weiterentwicklung von Scrum durch die Verwendung von User Stories als Werkzeug zur Beschreibung von kundenorientierten Arbeitszielen und Story Points als Maßstab für die Arbeitsgeschwindigkeit und -qualität des Teams wurde 2012 eingeführt und hat seitdem einen großen Einfluss darauf, wie das Framework eingesetzt wird.

Ein Scrum-Team besteht aus 3 definierten Positionen

Es gibt nur drei Teamfunktionen, die durch das Scrum Framework definiert werden:

• Product Owner
• Scrum Master
• Development Team

Product Owner

Der Product Owner (PO), der immer aus einer Person besteht, ist der Botschafter oder Verfechter des letztendlichen Softwareprodukts. Er ist die Person mit der größten Autorität innerhalb des Scrum-Teams und -Frameworks und trägt letztendlich die Verantwortung für die Qualität der entwickelten Software.

Der PO vertritt auch den internen bzw. externen Kunden, der die Software finanziert oder für den sie entwickelt wird, sowie andere Interessenvertreter wie z. B. den Endnutzer. Das bedeutet, dass ein guter Product Owner ein tiefes Verständnis der Geschäfts-, Kunden- und Marktanforderungen hat.

So können sie das Product Backlog effektiv erstellen und managen, indem sie es Schrittweise in Sprints organisieren. Wenn jemand im Team Änderungen am Product Backlog, an den Funktionen oder an der Prioritätenfolge vornehmen möchte, ist der PO die Person, die er überzeugen muss.

Je nach Organisation und Projekt kann ein Product Owner auch Teil des Product Backlog ausführenden Entwicklungsteams sein, indem er z.B. die Rolle eines leitenden Entwicklers übernimmt. Oft sind sie jedoch als PO des Projekts tätig und delegieren das Product Backlog an das Entwicklungsteam.

Der Product Owner ist auch dafür verantwortlich, den Zeitpunkt zu bestimmen, an dem das Produkt einen MVP (Minimum Viable Product) repräsentiert, der als erste funktionierende Version ausgeliefert werden kann.

Scrum Master

Der Scrum Master ist eher ein Moderator und Vermittler als ein traditioneller Projektmanager. Seine Führungsrolle und Verantwortlichkeiten sind zwischen dem Product Owner, dem Scrum Master und dem Entwicklungsteam aufgeteilt.

Die Rolle des Scrum Masters besteht darin, den Fokus und die Motivation des Teams aufrechtzuerhalten und Arbeitshemmende Engpässe oder Blockaden zu beseitigen. Wenn zum Beispiel ein Mitglied des Entwicklungsteams immer wieder abberufen wird, um bei einem anderen Projekt zu helfen, wird vom Scrum Master erwartet, dass er einspringt und eine Lösung vermittelt.

Der Scrum Master ist auch für die Umsetzung des Scrum-Frameworks und der agilen Philosophie verantwortlich und hilft dabei, den Product Owner, das Entwicklungsteam und den Projektsponsor in Bezug auf den Scrum-Prozess zu coachen sowie deren erfolgreiche Umsetztung sicherzustellen. Wenn für eine Sprint-Review-Sitzung ein Besprechungsraum mit einem Projektor benötigt wird, ist der Scrum Master dafür verantwortlich, dass ein solcher zur Verfügung steht, dementsprechend ist der Scrum Master auch für alle anderen logistischen Anforderungen verantwortlich.

Development Team

Scrum-Entwicklungsteams sind eine eng zusammengeschlossene Gruppe von in der Regel nicht mehr als sieben Mitgliedern. Traditionell sieht das Scrum Framework vor, dass die Mitglieder eines Entwicklungsteams physisch zusammenarbeiten. Das kann im neuen Zeitalter der zunehmenden räumlichen Trennung oft unpraktisch sein, wobei sich außerdem auch schnell neue verteilte Scrum-Praktiken entwickeln.

Die Mitglieder des Entwicklungsteams verfügen über verschiedene Fähigkeiten, die zusammen das erforderliche Fachwissen für den Aufbau des angestrebten Softwaresystems liefern. Es gibt Front-End-Entwickler, Back-End-Entwickler und jetzt oft auch DevOps-Ingenieure mit Erfahrung in den Programmiersprachen, Frameworks, Tools und Technologien, auf denen das Produkt aufgebaut werden soll.

Das Team sollte auf die Bedürfnisse des Projekts und seine optimale Effizienz abgestimmt sein. Wenn das Softwaresystem zum Beispiel ein relativ einfaches Frontend, aber ein komplexes Backend hat, sollte das Entwicklungsteam mehr Backend- als Frontend-Entwickler haben. Wenn das Gleichgewicht nicht stimmt, behindert ein ungleichmäßiger Fortschritt der verschiedenen Komponenten den effizienten Ablauf.

Ein gutes Scrum-Entwicklungsteam organisiert sich selbst und geht an seine Projekte mit einer „Alle für einen und einer für alle“-Haltung heran. Dort sollen diese sich gegenseitig zu erfolgreichen individuellen sowie gemeinsamen Lösungen verhelfen.

Scrum-Teamgröße – wie groß darf das Team sein?

Ein Scrum-Team ist in der Regel relativ klein und besteht aus 5-9 Personen (einschließlich des Scrum Masters und des Product Owners, wenn es sich um unabhängige Rollen handelt). Zuviele Personen gelten als problematisch für das Ziel von Agile, Autonomie und Freiheit mit hoher Leistung und Qualität zu verbinden.

Größere agile Softwareentwicklungsprojekte, die mehr Mitarbeiter erfordern, aber dennoch das Scrum-Framework implementieren möchten, können dies mit einem der skalierten Scrum-Ansätze wie Large-Scale-Scrum (LeSS) oder Scrum-of-Scrums tun. Bei diesen Ansätzen wird die Arbeit auf mehrere halbautonome, aber koordinierte Scrum-Teams aufgeteilt.

Der Scrum-Prozess für die agile Softwareentwicklung

Der Scrum Framework-Prozess ist, wie alle agilen Ansätze zur Softwareentwicklung, sowohl periodisch als auch stufenweise. Das bedeutet, dass die Entwicklungsaufgaben für eine funktionierende erste Produktversion in Phasen unterteilt werden, die Scrum Sprints genannt werden.

Sprints stellen in der Regel 2-3-wöchige Arbeitszyklen dar und bilden einen Zeitrahmen, innerhalb dessen eine Reihe von Funktionen, Epics und User Stories (oder nur „Stories“) genannt, entwickelt werden. Wenn in einem einzigen Sprint nicht genügend Funktionen für einen marktfähigen MVP (Minimum Viable Product) fertiggestellt werden können, wird dieser zu einer stufenweisen Phase mit nachfolgenden Sprints, die zu einer Wiederholungsphase oder einem „Release“ (Scrum-Sprache) zusammengefasst werden.

Im Gegensatz zur herkömmlichen Methode der Softwareentwicklung nach dem Wasserfallmodell unterteilt der agile Ansatz Scrum einen streng sequenziellen Entwicklungszyklus in kleinere Zyklen. Auf jeden Zyklus folgt eine Überprüfung der freigegebenen Software durch das Entwicklungsteam, den Endnutzer und andere Beteiligte, inklusive des Softwareeigentümers, die Informationen für die nachfolgenden Zyklen liefern.

Das bedeutet, dass Änderungen an der Anforderungs- und Funktionsliste (und ihrer Prioritätsreihenfolge) vorgenommen werden können, was beim Wasserfallmodell nicht möglich ist. Hier wird die gesamte Planung in der anfänglichen Entwicklungsphase abgeschlossen und fixiert, sodass am Ende ein „fertiges“ Produkt herauskommt. Die Agilität des Scrum-Frameworks trägt dazu bei, dass das Endprodukt die Anforderungen des Kunden oder Benutzers bestmöglich erfüllt.

Scrum Zeremonien und Events

Scrum ist ein Framework, weil es einerseits dem Scrum-Team viel Raum für eigene Entscheidungen lässt, um die Prozesse an die Anforderungen des Projekts anzupassen, und andererseits auf einer Struktur besteht, innerhalb derer sich Freiheit und Interpretation befinden müssen. Das Scrum Framework besteht aus mehreren vorgesehenen Ereignissen und einer kleinen Anzahl von festen Regeln.

Die zentrale Regel von Scrum ist, dass Ereignisse „zeitlich eingegrenzt“ sind – ihnen wird eine feste Dauer zugewiesen, die nach ihrem Beginn nicht mehr geändert werden kann. Wenn beispielsweise ein Sprint mit einer Dauer von zwei Wochen begonnen hat, kann er nicht mehr auf acht Arbeitstage verkürzt oder auf zwölf verlängert werden.

Die vorgeschriebenen Scrum-Events und Zeremonien sind:

Sprint Planning

Dasa Sprint-Planning ist ein gemeinschaftliches Event, an dem das gesamte Scrum-Team beteiligt ist. Sie endet mit einer Entscheidung über die Features oder Stories, die innerhalb des Sprints fertiggestellt werden sollen. Der Product Owner leitet eine Diskussion, in der die Elemente im Product Backlog und ihr Beitrag zum Produktziel priorisiert werden.

Externe Personen, die nicht Teil des Scrum-Teams sind, können zur Teilnahme zur Planung der Sprints eingeladen werden, wenn die Teammitglieder ihren Rat und Input wünschen. Das Planen der Sprints muss die folgenden Fragen beantworten:

• Warum ist dieser Sprint sinnvoll?
• Welche Elemente des Product Backlogs können in diesem Sprint abgeschlossen werden?
• Wie wird die Arbeit ausgeführt?

Sprint

Sprints bilden den Kern des agilen Scrum-Prozesses zur Softwareentwicklung und dienen dazu, die eigentliche Arbeit zu erledigen. Sie sind zeitlich begrenzt und sollten weniger als einen Monat, vorzugsweise 2-3 Wochen dauern. Nur so kann der Fokus aufrechterhalten werden, der für einen konstanten und effizienten Fortschritt auf dem Weg zum Produktziel erforderlich ist.

Scrum.org hebt hervor:

„Wenn der Zeithorizont eines Sprints zu lang ist, kann das Sprint-Ziel ungültig werden, die Komplexität kann steigen und das Risiko kann sich erhöhen.”

Sprints unterliegen folgende Regeln:

• Es werden keine Änderungen vorgenommen, die das Ziel des Sprints gefährden würden;
• Die Qualität wird nicht beeinträchtigt;
• Das Product Backlog wird nach Bedarf verfeinert; und,
• Der Aufgabenbereich kann bei Bedarf geklärt und mit dem Product Owner neu verhandelt werden, sobald neue Erkenntnisse vorliegen.

Daily Scrum

Durch seine Regelmäßigkeit ist das Daily Scrum das bekannteste Ereignis des Scrum-Prozesses und wird als „vom Entwicklungsteam für das Entwicklungsteam“ beschrieben. Der Product Owner und der Scrum Master nehmen nur dann am Daily Scrum teil, wenn sie eine Doppelrolle innehaben und ebenfalls Teil des Entwicklungsteams sind und an Teilen des Product Backlogs arbeiten.

Eine morgendliche, zeitlich begrenzte 15-minütige Besprechung, die unbedingt jeden Arbeitstag zur gleichen Zeit und möglichst am gleichen Ort stattfindet. Die Besprechung ist so konzipiert, dass der Fokus auf dem Fortschritt in Richtung des Sprint-Ziels liegt, und zwar auf eine Weise, die die Selbstorganisation und die Verantwortlichkeit der einzelnen Entwickler untereinander und gegenüber dem Entwicklungsteam als Ganzes fördert.

Der Daily Scrum zeichnet den Fortschritt im Hinblick auf das Sprint-Ziel auf, synchronisiert die Aktivitäten und erstellt einen Plan für die nächsten 24 Stunden. Der Scrum Master, auch wenn er nicht direkt als Entwickler teilnimmt, ist dafür verantwortlich, dass das Daily Scrum konsistent und effektiv innerhalb der zugewiesenen 15 Minuten stattfindet.

Für Scrum ist es wichtig, das Daily Scrum klar von einem traditionellen „Status-Meeting“ zu unterscheiden. Hier geben die Teammitglieder ein Update über ihren Fortschritt bezüglich der Aufgaben, an denen sie gearbeitet haben an jemanden weiter, der wie z.B. ein Projektmanager einen Plan verwaltet. Ein Daily Scrum hingegen ist darauf ausgelegt, die Selbstorganisation zu fördern, die im Mittelpunkt der agilen Denkweise steht.

Das Entwicklungsteam hat die Freiheit, über die Struktur des Daily Scrum zu entscheiden, wobei die einzige feste Regel darin besteht, dass es sich auf den Fortschritt in Richtung des Sprint Ziels konzentriert und einen umsetzbaren Plan für die Arbeit des kommenden Tages definiert. Das Daily Scrum soll die Kommunikation im Team straff und transparent halten, Fortschrittsblocker identifizieren und beseitigen, sowie dazu beitragen, dass keine weiteren Meetings notwendig sind.

Ein Daily Scrum kann oft einfach darin bestehen, dass sich jedes Mitglied des Entwicklungsteams drei Fragen stellt und diese beantwortet:

1. Was habe ich gestern gemacht?
2. Was werde ich heute tun?
3. Gibt es irgendwelche Hindernisse, die im Weg sind?

Der Scrum Master ist für die Beseitigung von Hindernissen verantwortlich.

Obwohl das Daily Scrum so konzipiert ist, dass im Laufe des Tages keine weiteren Besprechungen erforderlich sind, bedeutet das nicht, dass es nicht im Laufe des Tages ausführliche Diskussionen zwischen den Teammitgliedern geben sollte, was in der Regel der Fall ist.

Das Daily Scrum wird oft auch als „Daily Stand-Up“ bezeichnet, da das ursprüngliche Scrum-Framework vorschreibt, dass die Teilnehmer stehen müssen. Dies sorgt für ein gewisses Maß an Unbehagen, das dazu beiträgt, dass alle aufmerksam bleiben und die 15-Minuten-Frist einhalten.

Sprint Review

Beim Sprint Review geht es darum, das Team zu feiern und zu zeigen, was es geleistet hat. Das Scrum Team präsentiert sich gegenseitig die Ergebnisse ihrer Arbeit sowie allen externen Stakeholdern, die der Product Owner für sinnvoll ansieht, um sie einzubeziehen.

Die Mitglieder des Scrum-Teams und andere wichtige Stakeholder überprüfen, was während des Sprints erreicht wurde, und besprechen alle Änderungen im Projektumfeld, die eine Aktualisierung des Product Backlogs zur Folge haben können. In der Regel wird auch entschieden, welche Product Backlog-Elemente nach der Definition des Teams als „erledigt“ und „nicht erledigt“ angesehen werden.

Auf der Grundlage der im Scrum Review präsentierten und diskutierten Informationen arbeiten die Teilnehmer gemeinsam daran, was sie als nächstes tun sollten.

Das Sprint Review ist das vorletzte Ereignis eines Scrum-Entwicklungszyklus und ist auf eine maximale Dauer von 4 Stunden im Falle eines 1-monatigen Sprints festgelegt, dieses dauert in der Regel jedoch kürzer. Das Endergebnis des Reviews sollte ein aktualisiertes Product Backlog und eine vorläufige Liste der Punkte sein, die im nächsten Sprint in Angriff genommen wird.

Sprint Rückblick

Der Sprint-Rückblick ist das letzte Ereignis eines Sprint- und Scrum-Entwicklungszyklus, bei dem es darum geht, zu analysieren, was im nächsten Sprint besser gemacht werden könnte, um die Effizienz der Arbeit und die Qualität der Ergebnisse zu verbessern. Dazu werden die Variablen des vorangegangenen Sprints wie Teammitglieder, Kommunikation, Tools, Prozesse und die Definition des Teams für „erledigt“ betrachtet.

Das Team sollte sich verpflichten, im nächsten Sprint alles zu implementieren, was seiner Meinung nach für eine größere Effektivität verbessert werden könnte. Der Sprint-Rückblick ist auf maximal 3 Stunden für einen 1-monatigen Sprint begrenzt und fällt üblicherweise kürzer aus.

Scrum artifacts

Die „Artefakte“ der agilen Scrum-Softwareentwicklung sind, wie die ursprüngliche lateinische Definition des Wortes besagt, etwas Geschaffenes – entweder ein Werkzeug oder eine Inspiration. Die drei wichtigsten Scrum-Artefakte sind:

• Product Backlog
• Sprint Backlog
• Increment

Product Backlog

Das Product Backlog ist eine sich ständig weiterentwickelnde Liste aller Aufgaben, die zur Verbesserung des Softwareprodukts erledigt werden müssen, wobei die Elemente nach ihrer Priorität geordnet sind. Es dient als einzige Quelle für die Arbeit des Scrum-Teams, dessen Mitglieder niemals an etwas arbeiten sollten, das nicht im Product Backlog enthalten ist. Die Elemente im Product Backlog sollten alle einen sinnvollen Beitrag zur Erreichung des Produktziels leisten.

Die Elemente im Product Backlog und ihre Prioritätenreihenfolge können vom Scrum Team im Laufe des Prozesses agil aktualisiert werden. In jedem neuen Sprint werden jedoch die Punkte in Angriff genommen, die im vorherigen Sprint Review vorläufig mit der höchsten Priorität deklariert, und dabei im Sprint Planning bestätigt wurden.

Sprint Backlog

Das Sprint Backlog besteht aus den Elementen die im Product Backlog mit der höchsten Priorität versehen, sowie die für die Fertigstellung innerhalb des aktuellen Sprints ausgewählt wurden. Die Elemente im Sprint Backlog sollten mit dem Sprint Ziel übereinstimmen und folgende Frage zu „warum?“ sind sie dort beantworten. Außerdem sollte dies mit einem umsetzbaren Plan zur Lieferung untermauert werden.

Das Sprint Backlog ist ein Plan, der vom und für das Entwicklungsteam erstellt wird. Es zeigt ein sichtbares Echtzeitbild der Arbeit, die während des aktuellen Sprints zur Erreichung des Sprint-Ziels fertig gestellt wurde. Der Plan wird im Laufe des Sprints laufend aktualisiert, dass wenn neue Erkenntnisse gewonnen werden, sowie wenn der Fortschritt bei den täglichen Scrum-Events verfolgt wird.

Increment

Ein Scrum-Increment muss einen konkreten Schritt in Richtung des Produktziels darstellen und aus nutzbaren neuen Stories bestehen, die mit bestehenden Inkrementen zusammenarbeiten, um das Softwareprodukt zu verbessern.

Ein Sprint kann mehr als ein Inkrement enthalten, kann aber nicht ohne die Veröffentlichung eines Inkrements abgeschlossen werden. Alle Inkremente, die der formalen Beschreibung des Scrum-Teams über ihre Definition von „erledigt“ entsprechen, werden beim Sprint Review vorgestellt. Wenn ein Sprint mehrere Inkremente enthält, können und sollten die früher im Sprint abgeschlossenen Inkremente freigegeben werden sobald sie der ausgelieferten Software einen Mehrwert darbieten.

Fazit

Sie sollten nun einen guten theoretischen Überblick über die agile Softwareentwicklung mit Scrum haben und sie verstehen können. Sie wissen nun, warum Scrum als eines der effektivsten und modernsten Frameworks für leistungsstarke Softwareentwicklungsteams gilt.

K&C stellt flexibel erfahrene Scrum-Teams zur Verfügung und ergänzt Agile Scrum-Teams, um Lücken zu füllen. Diese sind auf die Bedürfnisse der Softwareentwicklungsprojekte unserer Partner zugeschnitten und stehen im stetigen Austausch mit unseren Kunden. Wenn Sie Einzelheiten mit uns besprechen oder ein vorläufiges Angebot für Ihr nächstes Projekt erhalten möchten, nehmen Sie gerne Kontakt mit uns auf!