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.

AgileUPDATED ON Oktober 14, 2021

Author

Translated by:

Agile software development with Scrum blog cover image

Das Scrum-Framework ist der beliebteste Ansatz der allgemeinen agilen Methodik, die die Softwareentwicklung in den letzten zwei Jahrzehnten dominiert hat. Aufgrund der starken Zersplitterung des Marktes sind verlässliche Statistiken schwer zu bekommen, doch die große Mehrheit der Softwareentwicklungsteams verwendet einen Projektmanagementansatz, 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 der Mehrheit, die eine Variante der agilen Methodik auf Teamebene anwandte, gaben 66 % an, dass sie dies mit Hilfe eines Scrum-Frameworks taten.

Infographic showing the relative popularity of different Agile frameworks with Scrum the must commonly used

Damit ist Agile mit Scrum der mit Abstand am häufigsten verwendete Ansatz für die Softwareentwicklung im Jahre 2021. 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 könnten, um ein Verständnis dafür zu entwickeln, dann wäre es das Scrum-Framework. Daher ist Scrum 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.

Können wir Ihnen bei Ihrem nächsten agilen Softwareentwicklungsprojekt helfen?

Flexible Modelle für Ihre Bedürfnisse!

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. Ihre Aufgabe ist es, 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. Ich überlasse das den Akademikern und den Leuten, die damit ihre Bücher verkaufen müssen.

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

„…ist 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 die 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. Es 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 des 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 bekannten Artikel The New New Product Development Game von Hirotaka Takeuchi und Ikujiru Nonaka aus dem Jahr 1986 inspiriert wurden, der in der Harvard Business Review veröffentlicht wurde. In dem klassischen Artikel wurde ein neuer ganzheitlicher Ansatz für die Innovation beschrieben, der mit dem Rugby-Sport verglichen wurde, bei dem das gesamte Team „versucht, als Einheit über die Distanz zu gehen und dabei 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 of a rugby scrum showing the relationship to teamwork in a software development Scrum Team

Photo credits: Quino AI

Scrum ist somit sechs Jahre älter als das Agile Manifesto. Das Agile Manifesto, das für die Softwareentwicklungsbranche im 21. Jahrhundert das Äquivalent zu den Zehn Geboten geworden ist, wurde 2001 veröffentlicht. 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 den 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 Entwicklungsteams sein, das das Product Backlog ausführt, indem er z. B. ein leitender Entwickler ist. Oft sind sie aber auch der PO des Projekts 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

T 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 Engpässe oder Blockaden zu beseitigen, die ihre Arbeit behindern. 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 und sicherzustellen, dass dieser gut umgesetzt wird. 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, sowie für alle anderen logistischen Anforderungen ist der Scrum Master 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, außerdem entwickeln sich derzeit schnell neue verteilte Scrum-Praktiken.

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, indem sie sich gegenseitig zu erfolgreichen individuellen und gemeinsamen Ergebnissen verhelfen.

Wann funktioniert IT-Outsourcing?

(Und wann nicht?)

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). Mehr 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 fertiggestellt werden können, wird er zu einer stufenweisen Phase, in der nachfolgende Sprints zu einer Wiederholungsphase oder einem „Release“ in der 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.

Infographic of the Scrum process as an Agile software development methodology

Scrum ceremonies and 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-Ereignisse und Zeremonien sind:

Sprint Planning

Dasa Sprint-Planning ist ein gemeinschaftliches Ereignis, 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 insists:

„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 einen Plan verwaltet, wie z.B. ein Projektmanager. 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 ergibt. Das Daily Scrum soll die Kommunikation im Team straff und transparent halten, Fortschrittsblocker identifizieren, damit sie beseitigt werden können, und 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 auch 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, 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 versehen wurden, und die im Sprint Planning bestätigt wurden.

Sprint Backlog

Das Sprint Backlog besteht aus den Elementen mit den höchsten Prioritäten aus dem Product Backlog, die für die Fertigstellung innerhalb des aktuellen Sprints ausgewählt wurden. Die Elemente im Sprint Backlog sollten mit dem Sprint Ziel übereinstimmen, die Frage beantworten, warum sie dort sind und mit einem umsetzbaren Plan untermauert werden, wie sie geliefert werden sollen.

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, wenn neue Erkenntnisse gewonnen werden, und 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, wenn sie bereit sind, der ausgelieferten Software einen Mehrwert zu verleihen.

Fazit

Sie sollten nun einen guten theoretischen Überblick über die agile Softwareentwicklung mit Scrum haben und verstehen. Sie wissen nun, warum Scrum als eines der effektivsten 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 stätigen 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!

K&C - Seit mehr als 20 Jahren entwickeln wir attraktive Technologie-Lösungen. Dürfen wir Ihr Wettbewerbsvorteil sein?

Kontaktieren Sie uns, um Ihre Wünsche oder Ihr nächstes Projekt zu diskutieren.