Agile Projektmanagementmethode Scrum

Scrum wird in der Softwarentwicklung, Hardwareentwicklung oder Wissenschaft erfolgreich angewandt.

Scrum in der Softwarentwicklung, Hardwareentwicklung und Wissenschaft als Projektmanagementmethode

Laut PwC interner Benchmarks (Havard Business Review, Figure 2, Seite 5) kann agiles Projektmanagement die Umsetzung eines Projektes um 18-20% beschleunigen. Die Kosten werden bis zu 29% geringer. Die Produktivität der Mitarbeiter steigert sich um 15-95%. Agile Softwareentwicklung hat einen positiven psychologischen Effekt auf die Mitarbeiter: Die Mitarbeiter fühlen sich wertgeschätzt aufgrund erhöhter Eigenverantwortlichkeit. In der Projektmanagementmethode Scrum wird auf Kommunikation und Feedback Wert gelegt, somit haben Mitarbeiter das Gefühl ernst genommen und gehört zu werden. Mitarbeiter sind bis zu 40 % zufriedener mit Ihrer Arbeit und somit auch produktiver.

Die Projektmanagmentmethode Scrum wird seit über 10 Jahren immer beliebter wie Google Trends zeigt.

Trend von Scrum bei Google Trends

Die Leitsätze des agilen Manifests (seit 2001) sind:

Leitprinzipien der Projektmanagementmethode Scrum
  • Individuen und Interaktionen sind über Prozessen und Werkzeugen. Das Ziel muss sein Teammitglieder als Individuen im kollektiv zu sehen und wahrzunehmen und die Bedürfnisse und stärken aller Teammitglieder im Team zu decken.
  • Funktionierende Software (oder auch Hardware) ist über einer umfassenden Dokumentation. Konkrete Ergebnisse haben Vorrang vor umfassender optischer Optimierungen. Funktionale Anforderungen vor Nicht-funktionaler Anforderungen.
  • Zusammenarbeit mit dem Kunden ist über den Vertragsverhandlung. Der Kunde erhält in regelmäßigen Abständen Feedback und kennt die aktuellen Projektergebnisse und Probleme.
  • Reagieren auf Veränderung sind über den Befolgen eines Plans. Es sollte nicht fest an einen Plan festgehalten werden sondern Raum für eine Plananpassung zur Verfügung stehen.

Die zwölf agilen Prinzipien (seit 2001) im agilen Projektmanagement sind.

  1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Im traditionellen Projektmanagement wird das Projekt nach einen gewissen Zeitraum ausgeliefert. Im agilen Projektmanagement wird nach oder auch während definierten Zeiträumen (Sprints; ein-vier-wöchige Arbeitszyklen) ausgeliefert.
  2. Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. Änderungen müssen begrüßt werden. Es wird nach Verbesserungspotentiale im Projekt gesucht.
  3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. Es soll funktionierende Software in regelmäßigen Abständen dem Kunden geliefert, besprochen, Feedback eingeholt und eingearbeitet werden.
  4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Jedes Teammitglied oder Abteilung hat Stärken und Schwächen welches sich ergänzen kann. Es muss die Kommunikation durch kurze Meetings gefördert werden.
  5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. Jede Person muss individuell angesprochen und im Team agieren können. Es wird ein offenes und respektvoller Umgang und Austausch angestrebt welcher die Produktivität des Einzelnen steigert.
  6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. Persönliche Gespräche werden zum Austausch des aktuellen Projektstandes bevorzugt.
  7. Funktionierende Software ist das wichtigste Fortschrittsmaß. Es sollen messbare Fortschritte und Ergebnisse für den Kunden erstellt werden.
  8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Das Scrum-Team sollte konstant mit einer Geschwindigkeit Ihren Aufgaben nachgehen können ohne sich zu verausgaben. Bei Außnahmezuständen wird der Umgang mit den Aufgaben reflektiert.
  9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Die Struktur des Projekts, Produkts oder Dienstleistung sollte kritisch betrachtet und verantwortungsvoll erstellt werden.
  10. Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell. Von jeden Serum-Mitglied sollten transparent die Aufgaben dargestellt werden die noch getan werden müssen.
  11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. Agiles Projektmanagement bedeutet, dass Teams sich selbst organisieren. Es wird über die Ergebnisse mit CEO und den Projektbeteiligten reflektiert statt konstant kontrolliert.
  12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an. Nach einen Arbeitszeitraum wird über die Probleme reflektiert und Optimierungspotentielle identifiziert.

Wie beim Scrummage im Rugby (daher kommt der Name Scrum; es besteht eine Ansammlung von Menschen welche alle gemeinsam um den Ball kämpfen) soll sich ein Team sich kontinuierlich verbessern, aus Erfahrung lernen, produktiver und effektiver werden. Das Rahmenwerk Scrum ermöglicht ein kontinuierliche Verbesserung von Teams in der Softwareentwicklung, Hardwareentwicklung und weitere nach bestimmten Regeln. Die kontinuierliche Bewältigung von Arbeit soll agile passieren. Es soll auf Anforderungen und Änderungen eines Plans sachlich konstruktiv mit Ziel zur Wertschöpfung reagiert werden. Die stetige Wertschöpfung und das Lernen passiert in Zyklen, sogenannten Sprints (Arbeitszeiträumen von ein-vier Wochen). Am Ende jedes Sprints nach einem Ereignis wie eine Retroperspective wird zur Reflexion des Vergangenen Fortschritts und Fehler angeregt.

Ein Artefakt in eine Werkzeug für die Erreichung eines Ziels und zur Lösung eines Problems. In Scrum gibt es drei Artefakte:

Scrum-Artefakte Product Backlog, Sprint Backlog und Inkrement

  • Product Backlog: Das Product Backlog ist eine Liste der Aufgaben, Funktionen, Anforderungen, Aktualisierungen, Optimierungen und Fehlerkorrekturen zu einem Produkt.
  • Sprint Backlog: Das Sprint Backlog enthält die Aufgaben, Funktionen, Anforderungen, Aktualisierungen, Optimierungen oder Fehlerkorrekturen zu einem Produkt für einen Zyklus oder Sprint welches flexibel gestaltet wird (bspw. wenn Aufgaben schneller bewältigt werden).
  • Inkrement: Das Inkrement sind nutzbare Funktionen eines Produkts nach einen festgelegten Zyklus wie einen Sprint. Diese Funktionen müssen Qualitätskriterien genügen welche im Definition of Done oder „fertig“ definiert sind. Die häufigen Auslieferungen im Scrum ermöglichen ein schnelles Testen und annähern und die Kundenbedürfnisse.

Scrum-Meetings in Projektmanagementmethode Scrum

Während eines Zyklus oder Sprints existieren verschiedene Meeetings:

  • Vor einem Sprint findet eine Sprint-Planning statt, das heißt es wird definiert, welche Aufgaben während eines Sprints vom Sprint-Team bewältigt werden. Das Meeting wird vom Scrum-Master geleitet. Es wird das Inkrement definiert.
  • Vor und während des Scrums findet ein Product Backlog Refinment Meeting oder Product Backlog Grooming statt. Es werden Aufgaben und Aufwände von den Entwicklern geschätzt. Es sollte nicht länger als 10 % der Entwicklungszeit in Anspruch nehmen. Verantwortlicher für die Schätzung der Aufgaben sind die Entwickler. Verantwortlicher für die Ordnung (nach Story Points (werden durch Entwickler festgelegt) und Wertschöpfung (bspw. nach ROI (Return of Investment))) der Aufgabe ist der Product Owner.
  • Der Sprint ist das eigentlichen Arbeitsereignis eines Sprints. Es finden ein-vier wöchige Sprints statt. Je komplexer die Probleme sind und je mehr Unsicherheiten bei der Bewältigung der Aufgaben, zur Erreichung des Sprint-Inkrements existieren desto kürzer sollten die Sprints sein um entsprechende Nachprüfbarkeit mit den Kunden zu sichern.
  • Der Daily Scrums (tägliche Standup Mettings) ermöglichen die Überprüfung der Fortschritts des Scrum Teams. Das Daily Scrum ist ein informelles Meeting und dauert 15-Minuten und sollte im stehen stattfinden. Folgende Fragen sollten im Daily Scrum von jedem Team-Mitglied abgedeckt werden:
    • Was wurde am vorherigen Tag erledigt?
    • Was wird am heutigen Tag erledigt?
    • Auf was für Probleme, Blockaden und Hinternisse wurden gestoßen?
  • Das Sprint Review ist ein Meeting zur Begutachtung des Meetings. Das Scrum-Team diskutiert über die bewältigten Aufgaben aus dem Sprint Backlog. Der Product Owner bestimmt ob diese Inkrement released, freigeben wird. Die Dauer des Sprint Review entspricht der Dauer der Spring Wochen.
  • Die Sprint Retrospektive ermöglicht einen Rückblick auf die gemeinsame Effektivität und Produktivität und identifiziert Optimierungspotentiale.

Scrum ist eine agile Projektmanagementmethode neben weiteren wie Kanban. Die zeitliche Bewältigung von Aufgaben wird in Scrum in Sprints festgelegt. Bei der agilen Projektmanagementmethode Kanban wird die zeitliche Bewältigung der Aufgaben während oder nach den Arbeitszyklus festgelegt. In Scrum wird ein Scrum Board verwendet. In Kanban ein Kanban Board. In Scrum gibt es verschieden Ereignisse wie Sprint Reviews und Sprint-Planning welche stattfinden müssen. In Scrum muss ein interdisziplinäres Team vorherrschen. In Kanban können vorhandene personelle Strukturen wiederverwendet werden. Die Organisation der Aufgaben in User Stories in Sprints ermöglicht ein schnelles Feedback. Die Ereignisse in Scrum wie das Daily Scrum und das Leben der Scrum-Werte kann zu Anpassungsschwierigkeiten führen.

Beim Sprint-Planning müssen Aufgaben für alle Teilnehmer des Scrum-Teams klar definiert werden ansonsten sollten diese Aufgaben ignoriert werden bis Klarheit herrscht. Die Fülle an User Stories in eine Scrub-Backlog muss vom Scrum-Team zu bewältigen sein. Kritische Gedanken der Mitglieder des Scrum-Teams sollten für die Anpassung des Backlogs berücksichtigt werden. Die User Stories müssen nach aktuellen Projekterkenntnissen angepasst werden. Scrum-Teams können erfolgreich sein wenn Inkremente und User Stories nach der Definition of Done bewältigt wurden. Der Sprint-Backlog und das Sprint-Board muss auf Information Radiotors am Arbeitsplatz des Scrum-Teams für das Scrum-Team eingesehen werden können. Bei der Planung täglicher Aufgaben zu einer User Story sollte der Product Owner Zeiträume für regelmäßige Aufgaben miteinplanen (z.B. Beantwortung von Nutzeranfragen).

Für die Erstellung eine Scrum-Projekts bietet sich Jira Software von ATTLASIAN an.

Verwendung von Jira Software für die Erstellung eines Scrum Projekts

Es kann ein Scrum Projekt durch Create project erstellt werden.

Erstellung eines Scrum Projektes

Es sollte ein Next-gen Projekt erstellt werden da es die Komplexität der Benutzeroberfläche verringert.

Erstellung einer Next-gen Softwareprojektes

Was sind die Rollen bei der agilen Projektmanagementmethode Scrum?

Scrum-Team in der Projektmanagementmethode Scrum

Im Projektmanagement mittels Scrum gibt es drei Rollen nachdem Scrum Guide 2020:

  • Multidisziplinäre Entwickler (innen) und Entwicklungsteam (3-9 Personen) zur Weiterentwicklung des Produktes
    • Aufgaben werden aus dem Product Backlog in Iterationen bewältigt und bestimmt
    • das Team bestimmt die zu bewältigenden Aufgaben nach Ihrer Erfahrung aus anderen Sprints und den Expertisen der Entwickler
    • erzeugt eine Inkrement einer Software während eines Sprint
    • das Inkrement wird vom Stack Holder gesichtet und nächste Sprint werden vorbereitet
    • handelt selbstorganisiert (trifft eigene Entscheidungen welche Aufgabe, wie und wann erledigt wird) und handelt kollektiv, gemeinsam mit Abstimmung im Scrum-Team
    • Hierarchien werden vermieden, Entscheidungen zum Fortschritt des Projekteams werden im Scrum-Team gefällt
    • es besteht aus spezialisierten Fachpersonal verschiedener Personen
    • Es tauscht sich aktiv im Daily Scrum aus; der Product Owner schlägt Lösungsstrategien vor, wie zukünftig vorgegangen werden soll
  • Product Owner (innen) pro Entwicklungsteam
    • setzt das Scrum-Team zusammen und dient als Ansprechperson von Unternehmen, Kunden und Scrum-Team
    • tauscht sich mit den Unternehmen, Kunden und Scrum-Team (Stack Holder Management) zu den bevorstehenden und Funktionen und Anforderungen des Produktes aus
    • sortiert und pflegt die Probleme und Aufgaben in einen Product Backlog (Liste mit Aufgaben zur Erstellung eines Produktes) nach Wertschöpfungsgrad und Aufwand
    • das Scrum-Team kann Änderungsvorschläge zum Product Backlog vorschlagen und der Product-Owner kann Änderungswünsche wahrnehmen
    • periodisiert das Product Backlog d.h. der teilt auf Zeiträume von ein-vier Wochen in einen Sprint auf und reduziert oder Erweiterungen das Product Backlog je nach Kundenaufforderung
    • entscheidet ob ein Inkrement einer Software ausgeliefert wird (Release Management)
    • In einen Scrum-Team gibt es genau einen Product Owner (innen)
    • muss sich gut selbst bei allen Stack Holdern behaupten können (verhandeln, überzeugen..)
  • Scrum Master (innen)
    • hat die Aufgabe die Scrum-Regeln zu vermitteln (er ist der Ansprechpartner) und für die Umsetzung zu sorgen
    • schult agiles Arbeiten und Weiterentwicklung nachdem Scrum Guide
    • reduziert die Ablenkungen von außen
    • organisiert und optimiert die Ereignisse im Scrum
    • er unterstützt den Scrum-Product-Owner bei der Definition der User Stories
    • er unterstützt die Schaffung von Transparenz und Förderung der Kommunikation
    • er analysiert und erkennt den Wert der Erfahrungen und Erkenntnissen des Scrum-Teams und versucht mit Vorschlägen die Entwickler zu unterstützen
    • er sorgt für den Wandel von einer Befehlskultur zur selbstorganisierten Kultur
    • er sorgt dafür das die Werte von Scrum (Commitment oder Selbstverpflichtung, Fokus, Offenheit und Transparenz, Mut oder Selbstbehauptung, Respekt) im Scrum-Team gelebt werden

Die Einführung von Scrum kann mit Schwierigkeiten verbunden sein bspw. können bei etablierten, älteren und eingesessenen Unternehmen Fachabteilungen existieren die nur bedingt zusammenarbeiten (Etablierung von Silos). Scrum bedarf einer richtigen Einstellung, den Mut neue Dinge zu erstellen, zu verwerfen und experimentieren zuzulassen. Scrum ist simple, bewusst inkomplett und zielt auf die kollektive Intelligenz der Menschen ab.

Das Scrum-Team ist klein (5-9 Teilnehmer; durch die Vermeidung von sozialen Faulenzen) und ist multidisziplinär aufgebaut um ein Produkt wie ein Webseite, App oder Kühlschrank in allen Aufgabenspektren (Testing, Entwicklung der Software) entwickeln zu können. Das Scrum-Team muss an ausreichend Kompetenzen verfügen. Scrum-Teams organisieren sich eigenverantwortlich und selbstständig. Das Scrum-Team fokussiert auf ein Produktziel. Scrum-Teams müssen gut kommunizieren und sich in einen Raum befinden. Es wird versucht nach jedem Sprint, einen Zeitraum von ein-vier wöchiger Entwicklungszeit ein funktionsfähiges Inkrement (bspw. ein von Product Owner vorgegebener Funktionalität einer Software) zu erstellen welches einen überprüfbaren Wert schafft. Es gibt keine Hierarchien in einem Scrum-Team. Alle Scrum-Mitglieder arbeiten gemeinsam an einem Product-Backlog, einer Aufgabenliste mit den Funktionen der Software oder Hardware.

Bei der Zusammenstellung eines Scrum-Teams bleiben bestehende Positionsbezeichnungen (wie Architekt, Ingenieur oder Designer) bestehen. Die Rollen dienen zur Festlegung eines Scrum-Teams, den Rahmen eines Scrum-Projekts und zielt auf die Förderung der Effektivität und Produktivität eines Scrum-Teams ab. Ein Scrum-Team ist ein interdisziplinäres Team und ist schwierig zusammenzustellen. Je komplexer und schwieriger die Projekte sind, desto schwieriger ist es ein interdisziplinäres Team zusammenzustellen.

Wie ist die Rolle eines Entwickler bei der agilen Projektmanagementmethode Scrum definiert?

Scrum-Entwicklungsteam

Die Entwickler erstellen zu Beginn des Projektes einen Aufgabenplan, der Sprint Backlog für den Sprint sowie ein Sprintziel. Die zu bewältigenden Aufgaben werden täglich überprüft und es werden Lösungsstrategien erarbeitet. Es werden Projektergebnisse nur akzeptiert wenn der Definition von Done erfüllt ist. Die Definition eines Done zu einer Funktion sind Qualitätskriterien in einen Inkrement wie die Farbe eines Produktes oder Funktionen einer Software. Für die Zusammenarbeit zwischen den Entwicklern werden Dailys empfohlen. In den Dailys werden Schwierigkeiten besprochen und Anpassungen definiert. Jedes Team-Mitglied sollte sich beim Daily einbringen und voneinander lernen.

Wie ist die Rolle eines Product Owner bei der agilen Projektmanagementmethode Scrum definiert?

Scrum-Product-Owner

Der Produkt Owner organisiert den Aufgabenplan. Er entwickelt und kommuniziert das Produktziel. Er überwacht die Verfolgung der Ziele und der Vision. Er kommuniziert und erstellt Aufgaben im Aufgabenplan. Er setzt Prioritäten im Aufgabenplan und sorgt dafür das die Aufgaben transparent, sichtbar oder zugänglich und verstanden werden können. Die Herausforderung liegt in der Priorisierung oder der Beschreibung der Aufgaben. Dem Product Owner muss soviel Einfluss gegeben werden, sodass er autonom entscheiden kann welche Aufgaben höher und welche niedriger priorisiert werden können. Die Organisation muss die Entscheidungen des Product Owners respektieren (ob CEO oder CTO). Der Product ist das Sprachrohr zwischen Stack Holdern (ob Entwickler oder Management).

Wie ist die Rolle eines Scum Master bei der agilen Projektmanagementmethode Scrum definiert?

Scrum-Master

Der Scrum Master(in) coacht die Teammitglieder im Selbstmanagement und Effektivität der Zusammenarbeit. Sie unterstützen bei der Zielerreichung der Definition of Done den Wunschvorstellungen eines Inkrements. Der Scrum Master sorgt dafür dass, das Scrum Team ungestört seine Ziele verfolgen kann. Der Scrum Master sorgt dafür, dass die Scrum-Ereignisse positiv, produktiv und innerhalb eines Zeitfensters oder auch timebox stattfindet. Er sorgt für die effektive Definition der Produktziele und der Organisation des Product Backlog und unterstützt somit den Product Owner. Er sorgt dafür das der Aufgabenplan klar und übersichtlich ist. Er unterstützt die Planung des Produktes auf der Basis von messbaren Ergebnissen (empirischer Ansatz). Er versucht zwischen Scrum Teams und Stakeholdern zu vermitteln. Der Scrum Master berät die Organisation in der Planung und Implementation des Projektmanagements Scrum.

Was sind die Werte bei der agilen Projektmanagementmethode Scrum?

Commitment oder Selbstverpflichtung. Jedes Teammitglied bringt sich ein und bleibt stets fokussiert. Jedes Teammitglied commited oder verpflichtet sich auf das Ziel und versucht sein bestes zu geben und andere zu bei Hilfe zu unterstützen. Jedes Team-Mitglied soll Perfektion anstreben solange es handeln kann und das Ergebnis akzeptieren. Fokus. Jedes Team-Mitglied sollte sich auf Ziel fokussieren. Multi-Tasking wird vermieden. Unterbrechungen und Störungen sollten durch den Scrum Master (in) unterbunden werden. Das Scrum-Team muss sich darauf fokussieren die Aufgaben, User Stories oder Backlog Items aus dem Sprint Backlog innerhalb des Sprints zu bewältigen und ein funktionierendes Inkrement herzustellen. Der Product Owner sorgt dafür dass, das Backlog gepflegt wird und die Aufgaben konkret beschrieben und das Definition of Done (Akzeptanzkriterien eines Inkrements) definiert wird. Offenheit. Fehlschläge sollten offen kommuniziert werden und Finger-Pointing und Schuldzuweisungen vermieden werden. Konstruktive und sachliche Kritik gegenüber Lösungsprozessen wird zur Problemlösung angestrebt. Destruktive und unsachliche Kritik wird vermieden. Erfolge werden gefeiert und aus Fehlschlägen wird gelernt und darüber reflektiert. Mut oder Selbstbehauptung. Es sollte Mut und eine gesunde Art der Kommunikation angestrebt werden um neue Problemlösungen zu erarbeiten und daraus zu lernen. Reaktive geistige Haltungen wie vergleichen, konkurrieren, klagen und kritisieren sollten vermieden werden. Proaktive geistige Haltungen wie Selbstwahrnehmung, Bewusstheit (Selbstempahtie, zu Wissen was in einem vorgeht), Mut (Selbstbehauptung, Mut neue Problemlösungen zu erarbeiten und diese zu kommunizieren; Es wird versucht zu gestalten, zu verhandeln, zu überzeugen..) und Verständnis (Empathie, zu Wissen im Gegenüber vorgeht und welche Stärken und Schwächen dieser hat) sollte angestrebt werden. Der Scrum Master sollte den Mut haben die Entwickler stetig von externen Einflüssen abzuschirmen. Respekt gegenüber anderen Meinungen sollte für den konstruktiven und sachlichen Umgang mit neuen Problemlösungen vorherrschen. Es sollte Dankbarkeit gelebt werden, Stärken und Schwächen des einzelnen sollten als Chance gesehen werden, notwendige Hilfestellungen anzubieten und gemeinsam am funktionsfähigen Inkrement zu arbeiten.

Was ist ein Sprint in der agilen Projektmanagementmethode Scrum?

Ein Sprint ist ein Arbeitszeitraum für die Bewältigung der User Stories von ein-vier Wochen. Während des Sprints werden vier Ereignisse bewältigt:

  • Sprint Planning. Im Sprint Planning werden die Aufgaben oder User Stories für den Sprint festgelegt. Es wird zudem die Strategie zur Bewältigung dieser Aufgaben festgelegt.
  • Daily Scrum. Das Daily Scrum ist ein tägliches 15-minütiges Statustreffen zu den bewältigten Aufgaben im Entwickleralltag.
  • Sprint Review. Am Ende des Sprints werden die inhaltlichen Ergebnisse des Sprints besprochen.
  • Sprint Retroperspective. Es wird die Teeamzusammearbeit während des Sprints besprochen.

Was sind Scrum Ereignisse und ein Sprint bei der agilen Projektmanagementmethode Scrum?

Die Ereignisse von Scrum finden innerhalb eines Sprints statt. Eine Sprint ist eine Time-Box von ein-vier-wöchige planbare Projektzyklen. Es werden kürzere Sprints von ein-vier-wöchige Dauer vorgezogen. Bei Teams die nicht Vollzeit an einem Projekt arbeiten werden vierwöchige Sprints durchgeführt. Zu Beginn findet das Sprint-Planning mit dem Entwicklern und Product Owner statt, bei dem die Aufgaben und Prioritäten der Aufgaben für die nächsten vier Wochen im Aufgabenplan oder Back-Log geplant werden. Es können mehrere Teams an einem Back-Log oder Aufgabenplan arbeiten. Es finden täglich Daily Scrums oder Dailys statt. Daily Scrums sind kurze fünfzehn-minütige Meetings mit Statusbericht und die tägliche Aufgaben. Am Ende des Sprints findet ein Review Meeting statt. Es werden die Stack Holder eingeladen und Feedback gegeben und entschieden welche weiteren Aufgaben bewältigt werden sollten. Am Ende eines Sprints findet eine Retro-Perspektive statt beidem das Scrum-Team über den letzten Sprint reflektiert. Es werden Learnings, Fehler, Verzögerungen und Verbesserungen bei der Retro-Perspektive besprochen. Nach jedem Sprint folgt einer weiterer Sprint. Bei mehreren Teams sollte ein Sprint gleichzeitig enden. Wenn das Sprint-Ziel vom Entwicklerteam nicht erfüllt werden kann, so kann der Product-Owner den Sprint mit Abstimmung der Teams abbrechen. Burn-Down Charts ermöglichen eine Darstellung des Fortschritts des Teams innerhalb des Sprints. Während des Sprints können Anpassungen der Projektziele stattfinden.

Was ist Sprint Planning bei der agilen Projektmanagementmethode Scrum?

Im Back-Log Rooming oder Planungsmeeting haben die Entwickler mit dem Product Owner festgelegt welche Aufgaben in den Aufgabenplan oder Back-Log aufgenommen werden. Das Sprint Planning findet zu Beginn eines Sprints statt bei dem das Scrum Team zusammenkommen. Der Product Owner hat den Aufgabenplan oder Back-Log bereits vor dem Meeting vorbereitet. Es wird geklärt welche Aufgaben während des Sprints bearbeitet werden können. Es wird geklärt wie die Aufgaben bewältigt werden. Es wird geklärt welche Wertschöpfung durch den Sprint ermöglicht werden kann (bspw. zu vorherigen Sprints). Die Summe der Aufgaben wird von den Entwicklern und dem Product Owner festgelegt. Es wird die Definition of Done des Inkrements festgelegt welches im Review Meeting gesichtet wird. Ein Sprint Planning ist getimeboxed – Ein Sprint Planning darf maximal 8 Stunden bei einen vier-wöchigen Sprint dauern. Bei kürzen Sprints sollte das Sprint-Planning pro Woche Sprint-Dauer eine Stunde betragen. Ein Sprint Backlog kann auch nachdem Sprint Planning im späteren Projektablauf aktualisiert werden

Der Scrum Master organisiert den Raum für das Treffen und lädt den Product Owner und das Entwicklungsteam ein. Der Scrum Master moderiert das Treffen wobei der Product Owner die Hauptverantwortung für die Besprechung hat. Der Product Owner muss die zu besprechenden User Stories vorbereitet haben. Das Entwicklungsteam kann über Story Points den Aufwand der User Stories bestimmen und sortieren. Mehr Story Points bedeuten mehr Aufwand. Das Ziel des Treffens ist es eine klare Vorstellung vom Inkrement (potentiell auszuliefernde Funktionen der Software oder Hardware), den übergreifenden Ziel des Sprints zu haben.

Was ist ein Backlog Grooming oder Backlog Refignment oder Backlog Pflege bei der agilen Projektmanagementmethode Scrum?

In diesen inoffiziellen Scrum-Ereignis passt der Product-Owner mit dem Entwicklungsteam das Scrum Product Backlog an. Folgende Kriterien können für die Pflege des Product Backlogs folgen:

  • Neue User Stories werden ins Backlog aufgenommen
  • User Stories welche eine höhere Wertschöpfung bewirken werden neu priorisiert (Aktualisierung der Position der User Story im Backlog)
  • User Stories welche einen höheren Aufwand bedeuten werden aktualisiert (Aktualisierung von Story Points)
  • User Stories welche keine Wertschöpfung bewirken werden entfernt

Das Team soll ein-zweiwöchentlich mit einen zeitlichen Umfang von 90 Minuten durchgeführt werden. Das Backlog Grooming sollte regelmäßig stattfinden. å

Was ist der Daily Scrum bei der agilen Projektmanagementmethode Scrum?

Der Daily Scrum oder Daily ist ein Treffen das maximal fünfzehn Minuten lang ist und fokussiert auf den Progress des nächsten Tages. Es findet im stehen statt. Daily Scrum ermöglicht eine Fokussierung auf die aktuellen Ziele und das Self-Management. Der Daily Scrum fördert die Transparenz. Das Daily Scrum ist bewusst kurz gehalten. Die Entwickler können nachdem Daily Scrum weitere Details zu den Tagesaufgaben klären. Das Daily Scrum sollte zur selben Zeit am selben Ort stattfinden. Das Daily Scrum ist wichtiges Meeting für die Abstimmung im Team. Ein Born-Down Charts hilft zur Reflexion des aktuellen Projektstatus und der Planung neuer Aufgaben.

Das Daily Scrum sollte nicht als Ort der Rechenschaft gesehen werden sondern als transparente Besprechung der Probleme auf die im Vortag gestoßen wurden. Folgende drei Fragen sollten bearbeitet werden:

  • Welche Aufgaben wurden gestern bewältigt?
  • Welche Aufgaben wurden heute bewältigt?
  • Welche Probleme hat die Bewältigung der Aufgaben verzögert?

Die Transparenz sorgt dafür das Problem erkannt und gemeinschaftlich an Problemlösungen gearbeitet werden kann. Störungen sollten insbesondere mittels Scrum-Master vermieden werden. Im Daily Stream befinden sich wunschgemäß komplette Entwicklungsteams. Der Product Owner kann sich über den aktuellen Zustand informieren. Auch Stack Holder sind erwünscht. Das Daily Scrum sollte zur gleichen Zeit stattfinden. Gelöste Problem und Erfolge sollten von allen Projektbeteiligten wahrgenommen und gefeiert werden.

Was ist der Sprint Review bei der agilen Projektmanagementmethode Scrum?

Das Sprint Review ermöglicht das Review eines Inkrements das während eines Sprints erstellt wurde. Im Sprint Review werden Stack Holder eingeladen und das echte Produkt dem Kunden für das Feedback zur Verfügung gestellt. Das Feedback hilft zur Produktverbesserung. Das Sprint Review hat eine maximale Länge von vier Stunden bei einen vier-wöchigen Sprint.

In einer informellen Atmosphäre werden die Ergebnisse, bewältigten User Stories oder Aufgaben vorgestellt, getestet und besprochen. Jede Aufgabe ist dann bewältigt wenn eine klare Definition of Done für eine Aufgabe existiert und diese erfüllt ist. Der Product Owner und die Entwicklungsabteilung überprüft und feiert die bewältigten Aufgaben. Sprint Reviews werden durch den Scrum Master am Ende des Sprints, am Freitag organisiert.

Was ist der Sprint Retrospective Meeting bei der agilen Projektmanagementmethode Scrum?

Das Sprint Retroperspective Meeting ist das letzte Ereignis während eines Sprints. Die Sprint Retroperspective ist timeboxed auf drei Stunden bei vier-wöchigen Sprint. Im Sprint Retroperspective Meeting gehören die Identifikation von Verbesserungsmöglichkeiten und die Reflexion des Sprint Verlaufs. Die Reflexion wird im Team erarbeitet. Verschiedene Reflexions- und Feedbackmethoden können angebracht werden um Problemen auf den Grund zu gehen. Es wird reflektiert wie die Zusammenarbeit, das Endergebnis und die Verwendung der Tools war. Im Sprint Retroperspective werden folgende Fragen geklärt:

  • Welche Arbeitsabläufe haben gut funktioniert?
  • Welche Arbeitsabläufe verliefen nicht reibungslos?
  • Was haben wir bei der Durchführung der Arbeitsabläufe gelernt?
  • Welche Wissenslücken sind im Team vorhanden?

Es wird aus den Antworten verstanden welche Arbeitsabläufe verbessert werden sollen und wie diese verbessert werden können. Es wird ein Plan zur Analyse und Optimierung von Arbeitsabläufen erarbeitet. Nach diesen Treffen kann die Effektivität, der Ablauf und der zukünftige Ablauf des Treffens Sprint Retroperspective reflektiert werden.

Was sind Scrum Artefakte bei der agilen Projektmanagementmethode Scrum?

In der Sprint Retroperspective oder Sprint Retroperspektive werden die Arbeitsabläufe, der Verwendung von Tools, Kommunikationsprobleme analysiert und Optimierungspotentiale identifiziert. Der Scrum Master organisiert das Treffen und lädt Product Owner und Entwicklungsteam ein. Es werden Verbesserungsvorschläge für das Team und jede individuelle Teammitglied herausgearbeitet. Die Timebox für die Retrospektive sollte bei einen vier-wöchigen Sprint drei Stunden lang sein.

Das Product Backlog (Aufgabenplan des gesamten Produktes) mit dem erreichbaren Product Goal oder Produktziel. Sprint Backlog (Aufgabenplan während des Sprints) mit dem Sprint Ziel. Das Inkrement ist das Ergebnis eins Sprints und muss den Qualitätskriterien des Definition of Done folgen. Die Artefakte schaffen Transparenz sodass die Projektteilnehmer (Stack Holder und Entwickler) verstehen welche Ziele für das Produkt, den Sprint und das Inkrement gelten.

Was ist ein Product Backlog bei der agilen Projektmanagementmethode Scrum?

Ein Produkt kann ein Service, Produkt oder Software sein. Das Produkt Backlog ist die Liste der Funktionen und User Stories eines Produktes. Die Funktionsliste wird häufig mit Trello oder Jira gepflegt. Die wertvollsten Funktionen des Product Backlogs werden sortiert. Die wichtigste Funktion liegt oben und wird als wichtigste Funktion definiert. Im Refignment Meeting wird der Umfang der Funktionalitäten geschätzt. In den Refignment Meetings werden die Funktionen vom Product Owner mit den Entwickler definiert und erkannt. Ein Refignment Meeting darf nicht mehr als 10 % der Entwicklungszeit entsprechen. Der Product Owner pflegt das Product Backlog.

Das erste oder initiale Product Backlog, die Aufgabenliste ist beim Beginn der Erstellung umfangreich. Der Product Owner muss bei der Definition der User Stories eine Vision zum Produkt haben. Bei der Erstellung der User Stories wird das Entwicklungsteam und deren Expertise benötigt. Er muss die Produktlinie und Roadmap der Produkte und des Produkts des Unternehmens kennen. Das erste funktionsfähige Produkt und vom Kunden akzeptierte Produkt ist Minimum Viable Product (MVP) woraufhin Feedback für die Weiterentwicklung gegeben werden kann. Stackholder wie Kunden oder Käufer können und sollen die Anforderungen mit definieren und Feedback geben.

Der Product Backlog ist eine Liste von Funktionen des Produktes, Services oder Hardware. Die Funktionen einer Software oder Hardware werden in einen „Requirements Workshop“ mittels Kreativitätstechniken ermittelt. Der Product Owner baut den Product Backlog auf in denen sich die Aufgaben sogenannte Product Backlogs Items (PBI’s) befinden. Die Funktionen können in einer Exceltabelle oder in Tools wie Jira dokumentiert werden. Mit Jira ist es möglich das Produkt Backlog zu teilen oder Sortierungen vorzunehmen. Viele Scrum Teams verwenden Sticky Notes auf denen Anforderungen geschrieben. Auf die Rückseite einer Sticky Note ist es möglich Akzeptanzkriterien einer Funktion zu beschreiben. Durch das haptische, der Flexibilität im Umgang und das hängen der Stick Note an eine Wand wird der Dialog und die Kommunikation gefördert. Der Product Owner nimmt die Priorisierungen der Anforderungen vor. Die Anforderungen welche wichtig und umgesetzte werden sollen, stehen oben und sind gut definiert, strukturiert und können in einen Sprint von maximal vier Wochen bearbeitet werden.

Ein Product Backlog sollte nach DEEP gestaltet sein. Detailed oder Detailliert. Die Aufgaben und User Stories im Product Backlog sind ausführlich formuliert und erfüllen die Qualitätskriterien der Definition of Ready und weitere individuelle Qualitätskriterien für eine User Story. Das Product Backlog sollte ein Fülle von Aufgaben für die nächsten 1-2 Sprints haben. Emergent oder entstehend. Das Product Backlog und die User Stories können abgeändert, erweitert oder entfernt werden (agiler Ansatz). Estimated oder abschätzend. Der Aufwand sollte abgeschätzt werden können sodass die Ressourcen für einen Sprint und die Umsetzung geplant werden können. Prioritized oder priorisiert. Die User Story muss nach für den Kunden wichtigen Funktionen sortiert werden können. Eine Priorisierung muss nach Wertschöpfung, Komplexität (Unbekannte früh begegnen), Umsetzbarkeit (Einträge müssen mit der vorhanden Expertise umgesetzt werden können), Unabhängigkeit (User Stories müssen für sich alleinstehend sein). Der Product Owner erstellt und pflegt mit dem Scrum Master und Entwicklungsteam das Product Backlog.

In Jira sieht das Backlog folgendermaßen aus; Eine Story kann durch Create Issue erstellt werden:

Product Backlog in Jira

Was ist eine User Story bei der agilen Projektmanagementmethode Scrum?

Die Anforderungen werden am besten als User Storys definiert. Sie werden in der Sprache des Kunden beschrieben. Es werden die Erwartungen des Kunden an das Produkt, den Service oder den Prozess beschrieben. Beispielsweise kann ein Nutzer über eine Suchmaske die Produktliste durchsuchen und bekommt ein Ergebnis. Technische Details und Prozesse werden weggelassen. In einer guten User Story muss das Wer, Was und das Warum geklärt werden. User Story’s werden über ein Template beschrieben: Als ein <Typ von Nutzer (Kunde, Nutzer); Wer>, möchte ich <ein Ziel (Funktion, Anforderung); Was> so dass / damit <Nutzen (Grund); Warum>. In einer User Story muss das Ziel klar kommuniziert sein. Als ein Nutzer, möchte dieser nach einer Kunden-ID suchen damit ein Kunde schneller gefunden werden kann. Diese Darstellung hilft den Stack Holdern das Bedürfnis des Kunden besser zu verstehen. Die User Story wird nach Priorität und Story Point sortiert. Die Priorität ist die Wichtigkeit und Wertschöpfung einer User Story und der Story Point der Aufwand zur Umsetzung einer User Story. Sollten User Stories umfangreicher sein so können Sie unterteilt und einen Epic zugeordnet werden. Sollte eine User Story noch umfangreicher werden so wird ein Theme definiert.

In Jira kann die Epic-Version folgendermaßen aktiviert und mit Create Epic erstellt werden.

Aktivierung einer Epic in Jira

Eine User Story kann einen Epic sodann folgendermaßen zugeordnet werden.

Eine technische Aufgabenbeschreibung könnte wie lauten: Implementation einer Möglichkeit zur Verteilung von E-Mails an verschiedene Empfänger. Mit der Sprachschablone würde Sie folgendermaßen in eine User Story überführt werden. Der Nutzer der App/Software für berufliche Zwecke, möchte die Möglichkeit haben, seine E-Mails an verschieden Empfänger zu versenden, damit er die E-Mail nur einmal formulieren muss und diese direkt weiteren Empfänger zukommen lassen kann (ohne diesen Vorgang mehrfach zu wiederholen und somit Arbeit und Zeit einsparen (Automatisierung);Ist optional; je nach Kontext).

Jede User Story ist erst abgeschlossen wenn es den Qualitätskriterien der Definition of Done genügt zum Beispiel:

  • Code erstellt?
  • Softwaredokumentation erstellt?
  • Bedienungsanleitung erstellt?
  • Tests erstellt und bestanden (z.B. Code Coverage)?

Eine User Story muss nach den INVEST Kriterien aufgebaut sein. Independent oder Unabhängig. Jede User Story muss klar von einer anderen User Story abgrenzbar sein. Negotiable oder Verhandelbar. Die User Story muss verhandelt und angepasst werden können solange Sie im Product Backlog ist. Valuable oder Wertschöpfend. User Stories müssen einen Mehrwert für den Nutzer generieren. Estimable oder Einschätzbar. Der Aufwand der User Story muss beim Sprint-Planning klar bestimmt werden können. Small oder Sizable oder Klein. Eine User Story muss innerhalb eines Sprints umgesetzt werden können, ansonsten sollte es als Epic definiert werden. Testable oder testbar. Die User Story muss getestet werden können.

Die Definition of Ready einer User Story definiert die Qualitätskriterien zur Beschreibung der User Story bevor diese im Sprint umgesetzt werden kann. Die Qualitätskriterien zur Beschreibung der User ist branchenabhängig und Scrum-Team abhängig. Das INVEST Akronyme kann herangezogen werden um Definition of Ready Qualitätskriterien zu definieren. Eine User Story ist unabhängig von anderen User Stories, Scrum-Teams oder weiteren Faktoren. Die User Story muss verhandelbar zwischen Entwicklungsteam oder Product Owner sein. Die Bewältigung der User Story muss einen Mehrwert erzeugen. Der Aufwand zur Umsetzung der User Story ist einschätzbar. Die User Story muss für Umsetzung in einen Sprint eine geeigneten Umfang und Größe haben. Die User Story muss testbar sein sodass die Definition of Done erfüllt werden kann.

Wenn die User Story zu komplex erscheint, können User Stories unterteilt werden. Die komplexe User Story ist dann die Epic welche den User Stories zugeordnet wird. Eine Epic kann eine Verallgemeinerung von User Stories sein welches sich auf einzelne Nutzer bspw. von Betriebssystemen beziehen. Die Epic wird als User Story beschrieben welche einen generellen Nutzer beschreibt. Jede User Story muss der Definition of Done genügen.

Eine User Story kann eine User Story über Create Issue erzeugt werden. Es ist zudem möglich nicht nur eine Story sondern auch eine Task oder ein Bug zu erstellen.

Erstellung einer User Story in Jira

Nach der Erstellung der User Story kann Sie einen Sprint zugeordnet werden.

Zuordnung einer User Story Sprint in Jira

Sodann kan der Sprint gestartet werden und die Sprintdauer als auch das Sprintziel definiert werden.

Definition eines Spring Ziels in Jira

Was ist die Definition of Done bei der agilen Projektmanagementmethode Scrum?

Die Definition of Done werden Erwartungen und Qualitätskriterien für eine User Story festgelegt sodass Sie als abgeschlossen gilt. Die Definition of Done ist branchenabhänig und Scrum-Team abhängig. Die Definition of Done wird im Sprint-Planning Meeting besprochen. Die Qualitätskriterien einer Definition of Done können den Code, Dokumentation, Bedienungsanleitungen oder Tests betreffen. Sie können die Punkte, die angesprochenen Funktionen der User Story betreffen, die Erstellung, Überprüfung und Freigabe von Dokumenten oder die Freigabe der Produkte an Endnutzer oder Kunden. Die Definition of Done kann individuell für jeder User Story durch Akzeptanzkriterien erweitert werden.

Was ist ein Sprint Backlog bei der agilen Projektmanagementmethode Scrum?

Der Sprint Backlog spiegelt den aktuellen Projektstand während eines Sprints wieder. Das Sprint Backlog beinhaltet den Ablaufplan und das Ziel des Sprints. Das Ziel muss genau definiert werden zum Beispiel die Erstellung eines QR Codes oder die Implementation eines Bezahlservices. Es müssen die Aufgaben oder Funktionen zur Erreichung des Ziels definiert werden. Das Sprint Backlog wird aktiv bearbeitet und Karten werden während des Sprints in verschiedene Spalten geschoben zum Beispiel Doing und Done. Es kann direkt eingesehen werden. In der Sprint-Planning stellt der Product Owner das Sprint Backlog vor. Jede User Story enthält Aufgaben die zur Bewältigung der User Story notwendig ist. Ein Scrum Board ermöglicht die Aufgaben zu einer User Story zu organisieren. Es kann drei Spalten enthalten wie TO DO, DOING ODER IN PROGRESS und DONE. Aufgaben werden für einen Tag geplant. Sollte eine Aufgabe mehr als einen Tag in der DOING verweilen (aufgrund zu hoher Komplexität, Blockaden oder des Umfang) muss das Scrum-Team eine Lösung erarbeiten. Hierbei können die Aufgaben weiter unterteilt werden. Das Sprint Backlog ist kein unveränderliches Scrum-Artefakt, Dokument oder Liste wenn auch die Erreichung der Fertigstellung des Inkrements nach einen Sprint erreicht werden sollte.

Scrum-Board in Jira mit TO DO – IN PROGRESS – DONE

Im Sprint Backlog haben Sie die Liste von Funktionen oder Features die im kommenden Sprint umgesetzt werden sollen. Die Entwickler dürfen entscheiden welche Features Sie im kommenden Spring umsetzen wollen. Die Funktionen oder User Stories werden in Tasks oder Aufgaben aufgeteilt welche täglich bewältigt werden können und befinden sich auch im Sprint Backlog. Der Sprint Backlog gehört den Entwicklern. Die Entwickler dürfen bestimmen welche weiteren Aufgaben während des Sprints hinzugefügt oder entfernt werden können. Im Sprint Back Log befindet sich ein Product Backlog Item oder User Story und wird aufgeteilt in Aufgaben (Tasks) welche von einen Entwickler gestartet (Started Tasks) und bewältigt werden können (Done).

Die Product Backlog Items, Anforderungen oder User Story sind Elemente der Sprint Backlogs enthalten. Die Anforderungen können priorisiert werden. Die Funktionen sollten nach Risiken, Abhängigkeiten und Deadlines sortiert werden. Funktionen oder Anforderungen sollten nicht voneinander abhängen.

Die Organisation der Arbeit der Entwickler kommen meistens aus dem Extreme Programming. Es wird sich bei dieser Projektmanagementansatz auf die Programmierung konzentriert. Eine Methode aus dem Extrem Programming ist das Pair Programming, d.h. einer Entwickler schreibt den Code und ein anderer Entwickler kommentiert den Lösungsprozess. Das Ziel ist es sich gegenseitig zu kontrollieren um Fehler in der Software zu minimieren. Manchmal können Entwickler in dieser Form entwickelt werden. Eine andere Methode aus dem Extreme Programming ist das Continues Integration und ermöglicht es den Code jedes Teammitglieds zusammenzuführen und im Team zu testen sodass der Master Branch nicht zerstört wird. Ein Scrum Master kann diesen Entwicklungsansatz Extreme Programming vorschlagen, sodass die Arbeit zwischen den Programmierer effektiver stattfindet.

Continues Refactoring ermöglicht den Code zu vereinfachen ohne die externen Funktionen zu ändern. Es wird die Lesbarkeit, Komplexität, Wartbarkeit und Erweiterbarkeit des Codes und Systems ermöglicht. Es wird keine Perfektion beim Refactoren des Codes angestrebt sodass die Kosten dem Nutzen angemessen gegenüber stehen.

Was ist ein Inkrement bei der agilen Projektmanagementmethode Scrum?

Ein oder mehrere Inkremente sind Teile eines Produkts und müssen nach einen Sprint funktionsfähig sein. Das Inkrement muss den Kriterien der Definition of Done, dass beim Sprint Planning für das Inkrement definiert wurde, nach einen Sprint erfüllen. Nach jeden Sprint werden neue Funktionen und Verbesserungen bearbeitet sodass nach jeden Sprint ein Inkrement mit Ihren fertigen User Stories erreicht werden sollte (Ein verschleppen und nachbearbeiten von User Stories ist die Konsequenz). Für den Product Owner muss eine wertvolles Team und Inkrement nach einen Sprint das Ziel sein. Das Definition of Done zu den User Stories muss vom Product Owner klar definiert sein. Voneinander unabhängige Funktionen und User Stories sind das Ziel sodass ein klarer Resourcenplan und Aufgabenplan erstellt werden kann und Verschleppungen vermieden werden. Es können mehr Inkremente innerhalb des Sprints erstellt werden.

Die Definition of Done (DoD). Qualitätskriterien und Akzeptanzkriterien werden im Product Backlog oder auf der Sticky Note für jedes einzelnen Feature oder Funktion definiert. Die Definition of Done ist eine Definition von Qualitätskriterien und Akzeptanzkriterien welche für alle Features oder Funktionen gilt. Es wird durch DoD geregelt wie lange an einem Feature gearbeitet wird. Die Definition of Done bspw. folgende Punkte enthalten: Typ oder Häufigkeit des Testens, Häufigkeit der Integration, Dokumentationsaufwand, Perfomancevorgaben, Wartbarkeit des Codes. Das Ziel der Befolgung nach Definition of Done ist ein potentially shippable Inkrement zu erstellen.

Ein Sprint kann nach der Definition of Done folgendermaßen beendet werden:

Beendigung eines Sprints nach Absolvierung der User Stories in Jira

Was ist ein agile Testing bei der agilen Projektmanagementmethode Scrum?

Es soll während der Entwicklung dauerhaft getestet werden. Bspw. soll im Laufe der Nacht getestet werden. Zudem gibt es den Entwickleransatz des Test Driven Development. Es wird ein Test für eine Funktion beschrieben sodann wird die Entwicklung des Codes vollzogen. Nach der Entwicklung kann verstanden werden ob der Test funktioniert hat und Änderungen vollzogen werden sollen. Es sollte zudem versucht werden die Code Coverage so groß wie möglich zu halten. Ein User Acceptance Test ermöglicht ein Testen der Software mit dem Kunden sodass ein hohe Zufriedenheit beim Kunden erzeugt werden kann.

Was ist ein agile Planning bei der agilen Projektmanagementmethode Scrum?

Die Planning Onion oder die Planungszwiebel hilft für die Entscheidungsfindung während der Scrum Prints. Die Planungszwiebel setzt sich zusammen aus Strategy, Portfolio, Product, Release, Sprint und Daily. Die kleinste Planungseinheit ist das Daily Scrum, die Planung der Tagesaufgaben um zu einen Gesamtprodukt zu kommen.

Was ist ein Release bei der agilen Projektmanagementmethode Scrum?

Ein Release Planning wird durch den Product Owner durchgeführt. Der Product Owner spricht mit dem Kunden ab wann ein Release stattfindet. In der der Regel wird alle drei Monate ein Release entwickelt. Ein Release Planning enthält die Funktionen welche innerhalb von drei Monaten bis zu einen Jahr implementiert werden. Ein Release ist eine Zusammenfassung von mehreren Sprints. Es kann jedoch auch sein, dass während des Sprints released wird. Ein Release Planning sollte flexibel gestaltet sein, sodass die Wünsche des Kunden nach aktuellen Projektergebnissen angepasst werden.

Der Marketingabteilung kann durch den Release Plan mitgeteilt werden, wann welche Funktionen zu welchen Zeitpunkt released werden können. Ein zu hoher Detailgrad sollte vermieden werden, da die Entwickler die Freiheit haben sollten auch Funktionen wegzulassen. Beim Sprint Planning wird sich auf ein Sprint Ziel geeinigt. Der Product Owner kann während das Sprints das Sprint Ziel mit Absprache des Kunden ändern. Dieses Vorgehen soll vermieden werden.

Wie werden agile Schätzungen oder Estimations und Story Points bei der agilen Projektmanagementmethode Scrum vorgenommen?

Die Entwickler nehmen Schätzungen vor, weil Sie am meisten Einblick und Verständnis zu den angestrebten Aufgaben haben. Schätzungen werden in Rooming Sessions vorgenommen. Ein Product Owner raumt diese Schätzung an. Der Scrum Master organisiert das Meeting. Die Rooming Session soll maximal 10 % der Entwicklerzeit in Anspruch nehmen. Schätzungen sind eine ungefähre Angabe in Stunden. Die Schätzungen werden im Laufe der Sprints nachkorrigiert und die Schätzungen werden optimiert.

Schätzungen müssen trainiert werden. Es wird eine Referenzstory oder Aufgabenbereich herangezogen. Man nimmt sich eine einfach zu umsetzende Story die für jeden klar, einfach und bekannt ist. Durch Triangulation – Planning Poker wird eine Schätzung vorgenommen. Jeder Entwickler macht eine Schätzung zur Referenzstory und bestimmt eine Zahl auf wie hoch er den Aufwand schätzt. Nachdem jeder geschätzt hat, wird die höchste und niedrigste Schätzung diskutiert. Sodann folgt eine Einigung auf eine Zahl oder Kategorie für die Anforderung. Eine Fibonacci Zahl, T-Shirt Größe oder Kategorien wie Sehr leicht – Leicht – Moderat – Eher – Schwer – Sehr schwer – Extrem schwer kann verwendet werden. Es kann auch die effektive Zeit in idealen Stunden angegeben werden.

Die Planungs-Poker Treffen sollte nicht in der Sprint-Planung erfolgen. Das Planung Poker kann bei der ersten Erstellung des Backlogs erfolgen oder bei einen Backlog Grooming Treffen bei denen Anforderungen von Stack Holdern in das Projekt eingebunden werden. Es sollten alle Mitglieder des Entwicklungsteam anwesend sein. Der Scrum-Master oder der Product-Owner moderiert das Treffen und erklärt die Regeln. Der Moderator stellt jede User Story vor. Jedes Team-Mitglied legt nach seiner Einschätzung die Karte umgedreht auf den Tisch sodass andere Team-Mitglieder nicht beeinflusst werden. Es sollte eher schwieriger als leichter geschätzt werde. Nachdem das Scrum-Team den Aufwand geschätzt hat, werden die Karten gleichzeitig umgedreht. Die Spieler mit der höchsten und niedrigsten Schätzung müssen die Entscheidung begründen. Das Scrum-Team bespricht sachlich und konstruktiv von bis zu zwei Minuten die Schätzungen. Der Planning Poker wird sodann nochmals gespielt bis einen Einigung erzielt wurde. Die Schätzungen der Teilnehmer welche die Aufgaben umsetzen werden höher gewichtet. Der Planung-Poker ermöglicht eine kollektive Entscheidungsfindung zu den Aufwand der Aufgaben, Transparenz und Klarheit zu den Details der Aufgaben. Die Teilnehmer sollten mit ausreichend Energie schätzen und bei Bedarf Pausen einlegen.

Die Affinity Estimation ist Sortierung der Nutzerstories oder Aufgaben nach Größe oder Aufwand. Nach der Schätzung der User Stories werden diese in Gruppen sortiert. Die Story Points werden für die Velocity oder den Work Speed verwendet. Die durchschnittliche Anzahl der Story Points nach einen Sprint gibt Aufschluss darüber wie schnell das Team arbeitet.

Wie werden agiles Monitoring und Metrics und Story Points bei der agilen Projektmanagementmethode Scrum vorgenommen?

Es muss während des Sprints Klarheit vorherrschen, welche Ergebnisse und welcher Projektzustand gerade vorherrscht. Die Spring Goal Success Rate (high) ist die Quantität in Prozent wie häufig die eingesetzten Sprint Ziele für die Sprints erreicht wurden. Die (Escaped) Defects (sollte niedrig sein) sind unerkannte Fehler während der Testingphase welche beim Kunden gefunden werden. Die Velocity (sollte hoch und nachhaltig sein) ist die Teamgeschwindigkeit d.h. die Qualität der Ziele die während der Sprints erreicht wurden. Die Velocity sollte hoch und nachhaltig sein d.h. das Entwickler nicht stetig überfordert werden sondern eine gesundes Stresslevel erfahren. Die Satisfaktion (sollte hoch sein) Rate ist die Zufriedenheit der Entwickler oder der Kunden. Das Team member turnover (low) ist die Häufigkeit des Wechsels von Teammitgliedern welche niedrig sind. Der Burn Down Rate (sollte hoch sein) gibt Aufschluss darüber wieviele Story Points in einen Sprint oder an einen Tag umgesetzt wurden.

Was wird ein Projektstatus in der agilen Projektmanagementmethode Scrum gemessen?

Einen Born-Down-Rate kann über einen Born-Down-Chart berechnet werden. Beim Information Radiator, einer Wand kann ein Burn-Down-Bar stehen. Die Säulen symbolisieren die Größen der Product Backlogs. Bei jeden Sprint verringern sich die Story points. Bei einen Burn-up Chart werden die bearbeiten Story Points dargestellt.

Als Information Radiator kann eine Tabelle mit To Do, Doing und Done stehen. Ein CEO kann sich direkt über den aktuellen Projektzustand mittels Information Radiator informieren. Ein Information Radiator sollte einfach, wenig, aktuell und den Verlauf des aktuellen Projektes zeigen. Er sollte so gestaltet sein, dass der Information Radiator Einfluss und sichtbar für die Projektbeteiligten ist.

Der Niko-niko Calender gibt Aufschluss über die Stimmung im Team wieder.

Wie sollte ein Workspace in der agilen Projektmanagementmethode Scrum gestaltet sein?

Die Teammitglieder insbesondere Entwickler müssen sich in einem Raum befinden (der Scrum Master muss sich nicht unbedingt im Raum befinden). Die räumliche Nähte sorgt dafür, dass die Entwickler Problemlösungsprozesse und Problemlösungen mitbekommen (Osmotic Communication). Entwickler können sich direkt unterstützen. Information Radiotor können aufgehangen werden um den aktuellen Projektstatus aufzuzeigen. Die Face-Face-Kommunikation hilft effektiver zu arbeiten. Getrennte Teams arbeiten weniger effektiv miteinander. Der Product Owner fasst den aktuellen Projektstatus für den CEO in einen Bericht zusammen.

Wie kann mit mehreren Scrum Teams und größeren Projekten in der agilen Projektmanagementmethode Scrum arbeiten?

Die Kommunikation zwischen verschiedenen Scrum Teams kann durch ein virtuelles Scrum Team oder Scrum-of-Scrums sichergestellt werden. Das Scrum-of-Scrums wird aus Teammitgliedern aus verschiedenen Scrums gebildet. Die Unterhaltungen zu den Scrums sind nicht getimeboxed.

Bei großen Projekten sollte jedes Scrum Team Aufgaben vom einen Product-Back-Log bearbeiten. Der Chief Product Owner kümmert sich um die Pflege des Product-Backlogs und reicht die Aufgaben an die Scrum Teams weiter. Jedes Team arbeitet zeitsynchron, das Sprint endet zu einen gleichen Zeitpunkt und die Meetings finden zeitsynchron statt. In jedem Team wird ein eigener Product Owner eingesetzt. Jedes Team kann einen eigenen Scrum Master haben. Es kann ein Scrum Master alle Scrum Teams betreuen. Jedes Scrum-Team muss Cross-Functional gestaltet sein (Tester, Entwickler, Softwarearchitekt in jedem Team). Es gibt einen Definition of Done welches für alle Scrum-Teams gilt.

Es gibt mehrere Möglichkeiten um Teams aufteilen. Teammitglieder eines vorhanden Teams können anderen Scrum-Team zugeteilt werden. Andererseits ist möglich mit einem Scrum-Team zu starten, Erfahrungen zu sammeln und erfahrene Teammitglieder einen Scrum Team zuzuweisen.

Bei verteilten Teams sollte ein Scrum Master dafür sorgen, dass Videokonferenzen bspw. Teams mit Personen oder Räumen aufgebaut werden. Verteilte Teams sollten einmal für ein informelles oder formelles Treffen zusammenkommen. Es sollte einmal am Tag überlappende Arbeitszeiten gefunden werden. Es kann mit niedriger Produktivität gerechnet werden.

Welchen Vertrag kann bei Projekten in der agilen Projektmanagementmethode Scrum erstellt werden?

Es können Zeiteinheiten für Zeiträume verkauft. Feste Preise können in der agilen Methode Scrum schwer gemacht werden. Es ist möglich einen Probesprint anzubieten. Ansonsten können Einblicke in vergangen Projekte und bewältigten Aufgaben in Scrums angeboten werden.

Was sind Herausforderung bei der Einführung der agilen Projektmanagementmethode Scrum?

Die Umsetzung der Selbstorganisation (z.B. Daily Scrum) kann herausfordernd sein. Entwickler und Mitarbeiter müssen im Unternehmen ihre etablierten Positionen aufgeben und die von der Projektmanagementmethode Scrum annehmen. Das kann zu Unmut, Verunsicherung und Angst führen. Pilotprojekte können dazu führen, die Projektmanagementmethode Scrum kennenzulernen. Fakten, Metriken können überzeugen sodass die Projektmanagementmethode Scrum effizienter ist als ursprüngliche Entwicklermodelle wie das Wasserfallmodell.

Die Räumlichkeiten müssen angepasst werden um Scrum Teams in einen Raum arbeiten lassen zu können. Die Räumlichkeiten müssen angepasst werden um Information Radiotors aufzuhängen. Die Marketingabteilung muss für die schnellen Releasezyklen vorbereitet werden. Das Bezahlmodell muss gegebenenfalls für die Entwickler angepasst. Die Bezahlung individueller Leistungen muss eventuell auf ein kollektives Bezahlmodell angepasst werden. Es muss eine Bereitschaft des stetigen Wachstums vorhanden sein (Inspect und Adapt). Es muss eine Kommunikationskultur vorherrschen die zur Verbesserung hinführt.

Positives Feedback zur eigenen und Fremdleistung müssen stetig, unternehmensweit gelebt werden. Der Scrum Master muss den Wandel motivieren und sich am Scrum Guide orientieren und an die Konzepte erinnern. Ereignisse wie im Sprint müssen stetig stattfinden, wenn auch Kritik oder eine Falschinterpration der Regeln vorherrscht. Der Scrum Master muss bei Konflikten als Person vermitteln

Was ist Transparenz, Inspektion und Adaption in der agilen Projetmanagementmethode Scrum?

Scrum beruht auf drei Säulen: Transparenz, Inspektion oder Adaption. Der Arbeitsprozess und die Arbeitsergebnisse müssen für alle Projektbeteiligten transparent sein sodass, das Projektrisiko reduziert werden kann. Die Inspektion von Arbeitsprozessen oder Arbeitsergebnissen ohne Transparenz ist irreführend und verschwenderisch um Möglichkeiten zur Unterstützung zu identifizieren. Bei unerwünschten Projektergebnissen muss das Scrum Team die Macht haben sich entsprechend den neuen Problemstellung und Kontext zu adaptieren (aus Problemen zu lernen) um erwünschtere Produktergebnisse zu erzielen. Stetiges Feedback von Stack Holdern ermöglicht das inspizieren und adaptieren von neuen Problemstellungen. Zum anderen können Stack Holder durch das Feedback verstehen in welche Projekte und Aufgaben Sie Ihr Geld investieren.

Die Scrum wurde auf der Basis von Empirismus & Lean Thinking konzipiert.

Was ist Empirismus bei der agilen Projektmanagementmethode Scrum?

Empirismus: Wissen kommt von Erfahrung und Entscheidungsfindung auf Basis von Beoabachtungen. Aus Erfahrung wird gelernt und das Gelernte in einer gleichen (oder wollmöglich ähnlichen) Problemsituation angewandt werden kann. Die stetige Überprüfung der erreichten Projektergebnissen und das Lernen aus unerreichten Projektergebnissen führt zu besseren Erfolg.

Was ist Lean Thinking bei der agilen Projektmanagementmethode Scrum?

Lean Thinking: Bei Lean Thinking wird auf Prozesse und Tätigkeiten fokussiert die einen Wert schaffen. Bspw. wird die Anzahl der vorhandenen Funktionen einer Software soweit reduziert, sodass Sie für den Kunden den meisten Wert schaffen.

Wie kann ich mich in der agilen Projektmanagmentmethode Scrum zertifizieren lassen?

Es gibt zwei große Zertifizierer für Scrum: scrum.org und EXIN. Scrum.org bietet nur englischsprachige Zertifizierungen an und es ist ratsam, bevor Sie die Zertifizierung absolvieren sich mindestens mit dem Assesmentcenter Scrum Open vorzubereiten.

Assesmentcenter von Scrum.org zur Vorbereitung der Scrum Master Zertfizierung

Sie absolvieren potentielle Scrum Fragen und lernen die Prüfungssituation kennen. Das Wissen was abgefragt wird, stammt aus dem Scrum Guide 2020. Die Zertifizierung ist die Professional Scrum Master I (PSM 1). Es ist zusätzlich zur Vorbereitung mit dem Scrum Open ratsam, das Assesment Center für den Scrum Product Owner Open und den Scrum Developer Open für die Vorbereitung zum PSM 1 zu absolvieren.

Ansonsten bietet sich die deutschsprachige Zertifizierung EXIN Agile Scrum FOUNDATION an, welche Sie ohne Training Center absolvieren können (für die Absolvierung des EXIN Agile Scrum MASTER welcher gleichwertig zum PSM 1 ist, benötigt ein Training Center) . Auch hier können Sie sich mit einer Beispielfragen mittels ONLINE-MUSTEREXAMEN vorbereiten.

Schulung zur Projektmanagementmethode in Scrum

Sie möchten eine Schulung zum Projektmanagementmethode in Scrum belegen? Klicken Sie hierfür nachfolgende Button: