SCRUM Quiz

Nein, Scrum ist ein Framework, in dem Menschen komplexe Probleme lösen und gleichzeitig wertvolle Produkte liefern können.

Das Scrum-Framework besteht aus Scrum-Teams und den dazugehörigen Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente innerhalb des Frameworks dient einem bestimmten Zweck und ist wesentlich für den Erfolg und die Nutzung von Scrum. Die Regeln von Scrum binden die Ereignisse, Rollen und Artefakte zusammen und regeln die Beziehungen und Interaktionen zwischen ihnen.

Jede Komponente innerhalb des SCRUM Frameworks dient einem bestimmten Zweck und ist wesentlich für den Erfolg und die Nutzung von SCRUM.

Scrum basiert auf der empirischen Prozesskontrolltheorie oder Empirie. Der Empirismus behauptet, dass Wissen aus Erfahrung kommt und Entscheidungen auf der Grundlage dessen trifft, was bekannt ist.

Scrum-Anwender sollten häufig Scrum-Artefakte inspizieren, um unerwünschte Abweichungen zu erkennen. Diese Untersuchung sollte nicht so häufig sein, dass die Inspektion der Arbeit im Wege steht. Hilfreich bei derartigen Untersuchungen kann externe, professionelle SCRUM Unterstützung sein.

Wird bei einer SCRUM Prozessanalyse festgestellt, dass ein oder mehrere Aspekte eines Prozesses außerhalb akzeptabler Grenzen liegen und das resultierende Produkt nicht akzeptabel ist, muss der Prozess oder das zu verarbeitende Material angepasst werden. Eine Anpassung muss so schnell wie möglich vorgenommen werden, um weitere Abweichungen zu

Das Sprint Backlog macht alle Arbeiten sichtbar, die das Entwicklungsteam als notwendig erachtet, um das Sprintziel zu erreichen. Um eine kontinuierliche Verbesserung zu gewährleisten, umfasst es mindestens eine Prozessverbesserung mit hoher Priorität, die in der vorangegangenen Retrospektive identifiziert wurde.

Wenn die Definition of done für ein Inkrement Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, müssen sich alle Scrum Teams mindestens daran halten. Wenn „done“ für ein Inkrement keine Konvention der Entwicklungsorganisation ist, muss das Entwicklungsteam des Scrum-Teams eine produktgerechte Definition von „done“ definieren. Wenn mehrere Scrum Teams an der System- oder Produktfreigabe arbeiten, müssen die Entwicklungsteams aller Scrum Teams gemeinsam die Definition von „Fertig“ definieren.

Das Inkrement ist die Summe aller während des Sprints abgeschlossenen Product Backlog Items und der Wert der Inkremente aller vorherigen Sprints.

Der Product Backlog ist eine geordnete Liste mit allem, was im Produkt benötigt wird und ist die einzige Quelle für die Anforderungen, die an das Produkt gestellt werden.

Das Sprintziel ist eine Zielsetzung für den Sprint, die durch die Implementierung von Product Backlog erreicht werden kann. Es zeigt dem Team eine Richtung auf, wohin die Reise geht und warum das Inkrement entwickelt wird.

Während des Sprints:

• Es werden keine Änderungen vorgenommen, die das Sprintziel gefährden würden;
• Qualitätsziele sinken nicht
• Der Umfang kann zwischen dem Product Owner und dem Entwicklungsteam geklärt und neu verhandelt werden

Wenn ein Sprint abgebrochen wird, werden alle abgeschlossenen und „Done“ Product Backlog Items überprüft. Wenn ein Teil der Arbeit potenziell freigabefähig ist, akzeptiert der Product Owner sie in der Regel. Alle unvollständigen Product Backlog Items werden neu geschätzt und auf den Product Backlog zurückgesetzt.

Der Scrum Guide erkennt folgende Scrum Werte an: Engagement, Mut, Fokus, Offenheit und Respekt.

Scrum wurde entwickelt, um Software, Hardware, eingebettete Software, Netzwerke von interagierenden Funktionen, autonome Fahrzeuge, Schulen, Behörden, Marketing, die Verwaltung des Betriebs von Organisationen und fast alles, was wir in unserem täglichen Leben verwenden, als Individuen und Gesellschaften zu entwickeln.
Scrum wird weltweit in großem Umfang eingesetzt:

• Erforschung und Identifizierung tragfähiger Märkte, Technologien und Produktkapazitäten
• Produkte und Erweiterungen entwickeln
• Produkte und Erweiterungen so oft wie möglich pro Tag freigeben
• Entwicklung und Aufrechterhaltung von Cloud (online, sicher, on-demand) und anderen Betriebsumgebungen für die Produktnutzung
• Produkte erhalten und erneuern.

Wenn die Wörter „entwickeln“ und „Entwicklung“ im Scrum Guide verwendet werden, beziehen sie sich auf komplexe Arbeiten, einschließlich Software- und Hardware-Entwicklung, Entwicklung und Freigabe von Produkten und Erweiterungen, Entwicklung und Aufrechterhaltung von Produktbetriebsumgebungen, Forschung und Identifizierung lebensfähiger Märkte und Technologien und noch mehr.

Der Sprint wird nur dann abgebrochen, wenn das Sprintziel veraltet ist. Wenn einige Arbeiten nicht erledigt werden konnten, sollte der Sprint Backlog zwischen dem Product Owner und dem Entwicklungsteam neu verhandelt werden.

Der Cone of Uncertainty beschreibt den Verlauf von Unsicherheiten in einem Projekt

Wenn die Definition of done für ein Inkrement Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, müssen sich alle Scrum Teams mindestens daran halten. Wenn „done“ für ein Inkrement keine Konvention der Entwicklungsorganisation ist, muss das Entwicklungsteam des Scrum-Teams eine produktgerechte Definition von „done“ definieren. Wenn mehrere Scrum Teams an der System- oder Produktfreigabe arbeiten, müssen die Entwicklungsteams aller Scrum Teams gemeinsam die Definition of done definieren.

Während jeder Sprint Retrospektive plant das Scrum Team Wege zur Steigerung der Produktqualität, indem es die Definition of Done entsprechend anpasst

Es ist verboten. Der Zweck eines jeden Sprints ist es, Inkremente potentiell freizugebender Funktionalität zu liefern, die der aktuellen Definition des Scrum Teams von „Done“ entsprechen.

• DoD wird verwendet, um zu beurteilen, wann die Arbeiten am Produkt abgeschlossen sind.
• DoD leitet das Entwicklungsteam bei der Ermittlung der Anzahl der Produkte, die es während einer Sprint-Planung auswählen kann.
• DoD sorgt für Transparenz der Artefakte

Scrum basiert auf der empirischen Prozesskontrolltheorie oder Empirie. Der Empirismus behauptet, dass Wissen aus Erfahrung kommt und Entscheidungen auf der Grundlage dessen trifft, was bekannt ist. Drei Säulen unterstützen jede Umsetzung der empirischen Prozesskontrolle: Transparenz, Kontrolle und Anpassung.

Nachdem das Entwicklungsteam die Product Backlog Items, die es im Sprint erledigen will, geplant hat, erstellt das Scrum Team ein Sprintziel.

Wenn die Definition of done für ein Inkrement Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, müssen sich alle Scrum Teams mindestens daran halten. Wenn „done“ für ein Inkrement keine Konvention der Entwicklungsorganisation ist, muss das Entwicklungsteam des Scrum-Teams eine produktgerechte Definition von „done“ definieren. Wenn mehrere Scrum Teams an der System- oder Produktfreigabe arbeiten, müssen die Entwicklungsteams aller Scrum Teams gemeinsam die Definition von „Fertig“ definieren.

Nein. Scrum verbietet weder dem Product Owner noch dem Scrum Master die Entwicklungsarbeit. Es ist jedoch nicht die beste Vorgehensweise, da sie zu einem Interessenkonflikt führen könnte.

Falsch. Seine primäre Aufgabe ist es sich um das Team zu kümmern.Dennoch kümmert er sich auch darum, dass alle Stakeholder außerhalb des Teams Prozesse und Workflows des SCRUM Teams verstehen. Er beschützt sein Team.

Der Scrum Master dient dem Entwicklungsteam in mehrfacher Hinsicht, unter anderem:

• Coaching des Entwicklungsteams in Selbstorganisation und Crossfunktionalität
• Unterstützung des Entwicklungsteams bei der Entwicklung hochwertiger Produkte
• Beseitigung von Hindernissen für den Fortschritt des Entwicklungsteams
• Coaching des Entwicklungsteams in organisatorischen Umgebungen, in denen Scrum noch nicht vollständig eingeführt und verstanden ist.

Das Scrum Team besteht aus einem Product Owner, dem Entwicklungsteam und einem Scrum Master.

Scrum Teams sind selbstorganisierend und funktionsübergreifend. Selbstorganisierende Teams wählen selbst, wie sie ihre Arbeit am besten erledigen, anstatt von anderen außerhalb des Teams geleitet zu werden. Funktionsübergreifende Teams verfügen über alle erforderlichen Kompetenzen, um die Arbeit ohne Abhängigkeit von anderen, die nicht Teil des Teams sind, durchzuführen.

Entwicklungsteams haben die folgenden Eigenschaften:

• Sie sind selbstorganisierend. Niemand (nicht einmal der Scrum Master) sagt dem Entwicklungsteam, wie man den Product Backlog in Inkremente potenziell releasefähiger Funktionalität umwandeln kann
• Entwicklungsteams sind funktionsübergreifend und verfügen über alle notwendigen Fähigkeiten, um ein Produkt zu entwickeln;
• Scrum erkennt keine Titel für andere Mitglieder des Entwicklungsteams als den Entwickler an, unabhängig davon, welche Arbeit von der Person ausgeführt wird; es gibt keine Ausnahmen von dieser Regel;
• Scrum erkennt keine Subteams im Entwicklungsteam, unabhängig von bestimmten Bereichen, die angesprochen werden müssen, wie Tests oder Geschäftsanalysen; es gibt keine Ausnahmen von dieser Regel; und,
• Einzelne Mitglieder des Entwicklungsteams können über spezielle Fähigkeiten und Schwerpunkte verfügen, aber die Verantwortung liegt beim gesamten Entwicklungsteam.

• „Produktwertmaximierer“
• Lead Facilitator für die Einbindung wichtiger Stakeholder
• Produkt-Marktplatz-Experte

Das Teammodell in Scrum ist darauf ausgelegt, Flexibilität, Kreativität und Produktivität zu optimieren.

Der Product Owner ist eine Person, kein Komitee, aber der Product Owner kann die Wünsche eines Ausschusses im Product Backlog vertreten.

Die Anzahl der Personen in einem Entwicklungsteam sollte zwischen 3 und 9 liegen. Jedes Team sollte funktionsübergreifend und selbstorganisiert sein.
Die optimale Größe des Entwicklungsteams ist klein genug, um beweglich zu bleiben und groß genug, um wichtige Arbeiten innerhalb eines Sprints zu erledigen. Weniger als drei Mitglieder des Entwicklungsteams verringern die Interaktion und führen zu geringeren Produktivitätsgewinnen. Mehr als neun Mitglieder erfordern zu viel Koordination. Die Rollen Product Owner und Scrum Master sind in dieser Anzahl nicht enthalten, es sei denn, sie führen auch die Arbeit des Sprint Backlogs aus.

Der Scrum Master dient dem Product Owner in mehrfacher Hinsicht, unter anderem:

• Sicherstellen, dass Ziele, Umfang und Produktbereich von jedem im Scrum Team so gut wie möglich verstanden werden;
• Finden von Techniken für ein effektives Product Backlog Management;
• Dem Scrum Team zu helfen, den Bedarf an klaren und prägnanten Product Backlog Items zu verstehen;
• Verstehen der Produktplanung in einem empirischen Umfeld;
• Sicherstellen, dass der Product Owner weiß, wie er den Product Backlog wertschöpfend gestalten kann;
• Verstehen und Üben von Beweglichkeit;
• Moderation von Scrum-Ereignissen nach Wunsch oder Bedarf.

Der Scrum Master dient dem Entwicklungsteam in mehrfacher Hinsicht, unter anderem:

• Coaching des Entwicklungsteams in Selbstorganisation und Crossfunktionalität;
• Unterstützung des Entwicklungsteams bei der Entwicklung hochwertiger Produkte;
• Beseitigung von Hindernissen für den Fortschritt des Entwicklungsteams;
• Erleichterung von Scrum-Ereignissen nach Wunsch oder Bedarf; und,
• Coaching des Entwicklungsteams in organisatorischen Umgebungen, in denen Scrum noch nicht vollständig eingeführt und verstanden ist.

Der Scrum Master dient der Organisation in mehrfacher Hinsicht, unter anderem:

• Führung und Coaching der Organisation bei der Einführung von Scrum;
• Planung von Scrum-Implementierungen innerhalb der Organisation;
• Den Mitarbeitern und Stakeholdern helfen, Scrum und die empirische Produktentwicklung zu verstehen und umzusetzen;
• Verursachen von Veränderungen, die die Produktivität des Scrum Teams erhöhen; und,
• Zusammenarbeit mit anderen Scrum Masters, um die Effektivität der Anwendung von Scrum in der Organisation zu erhöhen.

Nur das Entwicklungsteam kann seinen Sprint Backlog während eines Sprints ändern. Der Sprint Backlog ist ein gut sichtbares „Echtzeit-Bild“ der Arbeit, die das Entwicklungsteam während des Sprints durchführen will, und gehört ausschließlich dem Entwicklungsteam.

Der Scrum Master ist verantwortlich für die Förderung und Unterstützung von Scrum im Sinne des Scrum Guide. Scrum Masters tun dies, indem sie jedem helfen, Scrum-Theorie, Praktiken, Regeln und Werte zu verstehen.

Leider nein. Der SCRUM Master ist für die Durchführung und auch die Vorbereitung der Retrospektive verantwortlich. Am besten nochmal den Abschnitt zur Retrospektive durchlesen

Leider nein. Der Team ist für die Durchführung des Daily Stand Ups verantwortlich. Am besten nochmal den Abschnitt zur Retrospektive durchlesen

Ein Sprint beginnt mit Sprint Planning, dann gibt es mehrere Daily Scrum Meetings, gefolgt von Sprint Review und dann Sprint Retrospektive.

Nur der Product Owner hat das Recht, den Sprint abzubrechen.

Die Struktur des Daily Scrum wird vom Entwicklungsteam festgelegt und kann auf unterschiedliche Weise durchgeführt werden, wenn es sich auf den Fortschritt in Richtung Sprint-Ziel konzentriert. Einige Entwicklungsteams werden Fragen verwenden, andere werden eher diskussionsbasiert sein. Anbei ein Beispiel:
– Was habe ich gestern getan, das dem Entwicklungsteam geholfen hat, das Sprintziel zu erreichen?
– Was werde ich heute tun, um dem Entwicklungsteam zu helfen, das Sprintziel zu erreichen?
– Sehe ich ein Hindernis, das mich oder das Entwicklungsteam daran hindert, das Sprintziel zu erreichen?

Die im Sprint auszuführenden Arbeiten werden bei der Sprintplanung geplant. Dieser Plan entsteht durch die gemeinsame Arbeit des gesamten Scrum Teams.

Die Sprintplanung ist auf maximal acht Stunden für einen einmonatigen Sprint ausgelegt.

Scrum erlaubt zusätzliche Meetings, wenn sie das Erreichen des Sprint-Ziels erleichtern.

Die im Sprint auszuführenden Arbeiten werden bei der Sprintplanung geplant. Dieser Plan entsteht durch die gemeinsame Arbeit des gesamten Scrum Teams.

• Das Entwicklungsteam kann andere Personen zum Sprint-Planning einladen, um technische oder fachliche Beratung zu leisten.
• Der Product Owner ist für die Einladung der Stakeholder zum Sprint Review Meeting verantwortlich.

Die Stakeholder dürfen nur am Sprint Review Meeting teilnehmen. Jedes Mitglied des Scrum-Teams kann jedoch jederzeit mit ihnen interagieren.

Falsch. Scrum erfordert keine abgestimmten Sprints für mehrere Teams.

Das Daily Scrum ist ein internes Meeting für das Entwicklungsteam. Wenn andere anwesend sind, sorgt der Scrum Master dafür, dass die Besprechung nicht gestört wird.

Die Sprintplanung ist auf maximal acht Stunden für einen einmonatigen Sprint ausgelegt. Für kürzere Sprints ist die Veranstaltung in der Regel kürzer.

Sprint Planning beantwortet die folgenden Fragen:

• Was kann als Inkrement aus dem bevorstehenden Sprint geliefert werden?
• Welche Arbeit ist erforderlich, um das Inkrement zu erreichen?

Der Input für die Sprintplanung ist dasProduct Backlog, das neueste Produkt Increment, die Kapazität des Entwicklungsteams während des Sprints und die bisherige Leistung des Entwicklungsteams.

Das Entwicklungsteam kann auch andere Personen einladen, um technische oder fachliche Beratung zu leisten.

Das Daily Scrum hat ein 15-minütiges Zeitfenster unabhängig der Größe des Entwicklungsteams

Anders als der Sprint selbst, der einen Rahmen für alle anderen Meetings ist, ist jedes Meeting in Scrum eine formale Gelegenheit, etwas zu inspizieren und anzupassen. Diese Ereignisse sind speziell auf kritische Transparenz und Kontrolle ausgelegt.

Der Scrum Master

• stellt sicher, dass das Entwicklungsteam das Meeting hat, aber das Entwicklungsteam ist für die Durchführung des Daily Scrum verantwortlich.
• Lehrt das Entwicklungsteam, das Daily Scrum innerhalb der 15-Minuten-Zeitbox zu halten.
• Wenn andere beim Daily Scrum anwesend sind, stellt er sicher, dass sie das Meeting nicht stören.

Das Ergebnis des Sprint Reviews ist ein überarbeiteter Product Backlog, der die wahrscheinlichen Product Backlog Items für den nächsten Sprint definiert. Der Product Backlog kann auch insgesamt an neue Gegebenheiten angepasst werden.

Beim Sprint Review arbeiten das Scrum Team und die Stakeholder zusammen, was im Sprint erreicht wurde. Basierend darauf und auf allen Änderungen am Product Backlog während des Sprints arbeiten die Teilnehmer gemeinsam an den nächsten Schritten zur Optimierung des Produktes.

Die Retrospektive ist eine Gelegenheit für das Scrum Team, sich selbst zu inspizieren und einen Verbesserungsplan für den nächsten Sprint zu erstellen.

Der Zweck der Sprint Retrospektive ist es:

• Überprüfung, wie der letzte Sprint in Bezug auf Personen, Beziehungen, Prozesse und Werkzeuge verlief.
• Identifizierung der wichtigen Items, die gut gelaufen sind und mögliche Verbesserungen.
• Erstellen Sie einen Plan für die Umsetzung von Verbesserungen in der Arbeitsweise des Scrum Teams

Das Entwicklungsteam modifiziert den Sprint Backlog während des gesamten Sprints. Während des Sprintverlaufs erfährt das Team mehr über die genauen Umsetzungen, die erforderlich sind und erweitert das Sprint-Backlog um neue Items.

Am Ende der Sprintplanung sollte das Entwicklungsteam in der Lage sein, dem Product Owner und Scrum Master zu erklären, wie es als selbstorganisierendes Team arbeiten will, um das Sprintziel zu erreichen und den erwarteten Zuwachs zu schaffen.

Der Product Owner ist dafür verantwortlich, die wertvollsten Items an die Spitze des Product Backlogs zu stellen.

Das BurnDown-Diagramm zeigt die Entwicklung des verbleibenden Aufwands im Vergleich zur Zeit.

Der Product Owner ist die einzige Person, die für den Product Backlog verantwortlich ist. Er oder sie kann jedoch einige Arbeiten im Zusammenhang mit dem Product Backlog Management an das Entwicklungsteam delegieren.

Die Aufgabe des Scrum Masters ist es, mit dem Scrum Team und der Organisation zusammenzuarbeiten, um die Transparenz der Artefakte zu erhöhen. Diese Arbeit beinhaltet in der Regel Lernen, Überzeugen und Verändern.

Nur Mitglieder des Entwicklungsteams erstellen das Inkrement.

Der Product Owner ist die einzige Person, die für die Verwaltung des Product Backlogs verantwortlich ist.

Das Product Backlog Management umfasst:

• Eindeutige Beschreibung von Product Backlog Items
• Sortierung der Items im Product Backlog, um Ziele und Missionen bestmöglich zu erreichen
• Optimierung des Wertes der Arbeit des Entwicklungsteams
• Sicherstellen, dass der Product Backlog für alle sichtbar, transparent und klar ist und zeigt, woran das Scrum Team als nächstes arbeiten wird
• Sicherstellen, dass das Entwicklungsteam die Punkte im Product Backlog auf dem erforderlichen Niveau versteht.

Die Scrum-Artefakte sind Product Backlog, Sprint Backlog und Increment.

Der Product Owner trackt die restliche Arbeit die verbleibt – spätestens zu jedem Sprint Review. Der Product Owner vergleicht diese Restarbeitszeit mit der bei früheren Sprint Reviews verbleibenden Arbeit, um den Fortschritt bei der Fertigstellung der geplanten Arbeit bis zum gewünschten Zeitpunkt für das Ziel zu bewerten. Diese Informationen werden für alle Beteiligten transparent gemacht.

Die Verfeinerung des Product Backlogs verbraucht in der Regel nicht mehr als 10% der Kapazität des Entwicklungsteams.

Nur das Entwicklungsteam kann seinen Sprint Backlog während eines Sprints ändern. Der Sprint Backlog ist ein gut sichtbares Echtzeit-Bild der Arbeit, die das Entwicklungsteam während des Sprints durchführen will, und gehört ausschließlich dem Entwicklungsteam.

Zu jedem Zeitpunkt eines Sprints kann die im Sprint Backlog verbleibende Gesamtarbeit eingesehen werden. Das Entwicklungsteam hat seine Restarbeitszeit im Blick und auch beim Daily Scrum parat, um die Wahrscheinlichkeit, das Sprintziel zu erreichen, zu prognostizieren.

Der Product Owner ist verantwortlich für den Product Backlog, einschließlich dessen Inhalt, Verfügbarkeit und Sortierung.

Ein Product Backlog ist nie vollständig. Das frühe Stadium des Backlogs stellt nur die zunächst bekannten und am besten verstandenen Anforderungen dar. Der Product Backlog entwickelt sich mit dem Produkt und der Umgebung, in der es eingesetzt wird. Das Product Backlog ist dynamisch; esändert sich ständig, um herauszufinden, was das Produkt braucht, um angemessen, wettbewerbsfähig und nützlich zu sein. Solange ein Produkt existiert, existiert auch sein Product Backlog.

Nur das Entwicklungsteam kann seinen Sprint Backlog während eines Sprints ändern. Der Sprint Backlog ist ein gut sichtbares „Echtzeit-Bild“ der Arbeit, die das Entwicklungsteam während des Sprints durchführen will, und gehört ausschließlich dem Entwicklungsteam.