1. Scrum: Prüfungsvorbereitung

Prüfungsrelevantes aus Sprint 2 von Dipl.-Wirtschafts.-Ing(FH), M.Sc. Sebastian Schneider

video locked

Über den Vortrag

Der Vortrag „Prüfungsrelevantes aus Sprint 2“ von Dipl.-Wirtschafts.-Ing(FH), M.Sc. Sebastian Schneider ist Bestandteil des Kurses „Scrum: Prüfungsvorbereitung“.

Quiz zum Vortrag

  1. Die Einträge, die der Product Onwer dafür vorsieht.
  2. Die Einträge mit dem höchsten Business Value.
  3. Die Einträge mit dem höchsten Wert.
  4. Die Einträge mit der höchsten Dringlichkeit.
  1. Idealerweise wird nach jedem Sprint die Budgetierung überarbeitet, um sicherzustellen, dass der Wert geliefert wird.
  2. Für gewöhnlich jeden Tag, oft nach dem Daily Scrum (bei Bedarf mit Controlling)
  3. Scrum benötigt kein traditionelles Budgetieren mehr.
  4. Jeden Tag
  1. Wenn der Product Owner feststellt, dass es keinen Sinn mehr macht (weil das Sprint Ziel nicht mehr erreichbar ist).
  2. Wenn das Entwicklungsteam feststellt, dass zu viele technische Schulden aufgebaut wurden.
  3. Wenn der Scrum Master entscheidet, dass es keinen Sinn mehr macht, dass Sprint Ziel zu erreichen.
  4. Wenn die Lizenzen für die Software nicht vollständig vorhanden sind.
  1. Der Product Owner
  2. Das Management
  3. Der CEO
  4. Das Entwicklungsteam
  5. Der Scrum Master
  1. Meetings moderieren und Impediments beseitigen.
  2. Er sieht zu, dass keine Änderungen am Sprint Backlog gemacht werden, nachdem der Sprint gestartet ist.
  3. Er weist Aufgaben an die Entwickler zu.
  4. Die Product Backlog Einträge in eine Reihenfolge bringen.
  1. Der Product Owner und das Entwicklungsteam.
  2. Niemand
  3. Der Scrum Master
  4. Das Scrum Team
  5. Das Entwicklungsteam
  1. Adaptation
  2. Kontinuierliche Verbesserung
  3. Planung
  4. Prädiktion
  1. Falsch
  2. Richtig
  1. Ein fertiges Produktinkrement.
  2. Eine Menge an Anforderungen für den nächsten Sprint zur Umsetzung.
  3. Ein Interface-Layout.
  4. Eine Architekturbeschreibung.
  1. Gerade soviel, dass das Entwicklungsteam in der Lage ist vorherzusagen was es tun kann und mit den ersten Tages des Sprints beginnen kann.
  2. Alle potentielle Arbeit für die ausgewählten Backlog Items.
  3. Gerade soviel, dass die Architektur verstanden werden kann.
  4. Gerade soviel, dass die Architektur und das Design verstanden werden kann.
  1. Richtig
  2. Falsch
  1. Es ist der Plan für das Entwicklungsteam für den Sprint.
  2. Es wird durch den Product Owner zusammengestellt.
  3. Es wird durch den Product Owner mit Einträgen aus dem Product Backlog beladen.
  4. Jeder dieser Einträge ist in Stunden geschätzt.
  5. Jeder dieser Einträge ist in Story Points geschätzt.
  1. Es ändert sich über die Laufzeit, wenn mehr über das Projekt gelernt wurde.
  2. Es ist eine Baseline für die Anforderungen im Projekt.
  3. Es beinhaltet alle notwendigen Arbeiten für das Produkt.
  4. Es repräsentiert eine detaillierte Projektplanung, die während des Projekts unverändert bleibt.
  5. Es wird ausschließlich vom Kunden oder Auftraggeber erstellt und gepflegt.
  1. Das Entwicklungsteam
  2. Der Product Owner
  3. Die Testabteilung
  4. Der Integrator
  1. Eine Demonstration des Produktinkrements
  2. Kommunikation des Projektfortschritts
  3. Was lief gut während des Sprints?
  4. Was lief schlecht während des Sprints?
  5. Was wird im nächsten Sprint verbessert?
  1. Wenn alles getan wurde, was in der Definition of Done aufgeführt ist.
  2. Wenn der Sprint zu Ende ist.
  3. Wenn das Sprint Review fertig ist.
  4. Wenn alle Aufgaben für das Item erledigt sind.
  1. Während des Sprint Plannings
  2. Während des Sprints
  3. Es muss gar nicht erstellt werden, ist aber gute Praktik.
  4. Zu Beginn des Projektes
  5. Zu Beginn des Sprint Plannings
  1. ...die Transparenz zu erhöhen.
  2. ...dem Entwicklungsteam zu helfen, wie viele Items es für den Sprint auswählen kann.
  3. ...ein gemeinsame Verständnis zu generieren, was für jedes Product Backlog Item zu tun ist.
  4. ...das Ziel des Sprints zu beschreiben.
  5. ...die Akzeptanzkriterien genauer zu definieren.
  1. Die Product Backlog Einträge kommen wieder auf das Product Backlog (der Product Owner kann sie erneut priorisieren).
  2. Der Sprint wird erweitert.
  3. Die Product Backlog Einträge werden im nächsten Sprint abgearbeitet.
  4. Der Sprint wird abgebrochen.
  1. Falsch
  2. Richtig
  1. Sie existieren nicht als Rolle im Scrum-Framework.
  2. Sie übernehmen die finale Qualitätssicherung.
  3. Sie verifizieren die vom Entwicklungsteam produzierten Ergebnisse.
  4. Sie überprüfen Hypothesen über den Fortschritt des Projekts.
  5. Sie revidieren Code als Teil des Entwicklungsteams.
  1. Die Definition of Done wird verbessert und konkreter.
  2. Die Definition of Done wird um Akzeptanzkriterien erweitert.
  3. Die Definition of Done bleibt über das Projekt konstant.
  4. Die Definition of Done entwickelt sich zu einem konkreten Produktmerkmal.
  5. Die Definition of Done überträgt die Verantwortung auf einzelne Teammitglieder.
  1. Sprint Planning
  2. Backlog Refinement
  3. Sprint Retrospektive
  4. Daily Scrum
  5. Sprint Review
  1. Das Entwicklungsteam
  2. In Scrum brauchen wir die Arbeit nicht mehr zu schätzen, es wird nur von Sprint zu Sprint geplant.
  3. Der Product Owner
  4. Der Scrum Master
  5. Der Product Owner und das Entwicklungsteam
  1. Richtig
  2. Falsch
  1. Am Ende eines jeden Sprints.
  2. Zwischen zwei Sprints.
  3. Wenn der Scrum Master verbesserungswürdige Situationen gefunden hat.
  4. Wann immer es benötigt wird.
  5. Wenn der Product Owner darum bittet.
  1. Nichts, da es keine Zeit zwischen der Retrospektive und der Planung gibt.
  2. Vorbereitungen für das Sprint Planning werden vorgenommen.
  3. Das Produkt Inkrement wird erstellt.
  4. Refactoring, wenn nötig.
  1. Richtig
  2. Falsch
  1. Richtig
  2. Falsch
  1. Falsch
  2. Richtig
  1. Gar nicht.
  2. Wenn das Sprint Ziel obsolet wird.
  3. Wenn es eine technische Abhängigkeit gibt, die nicht gelöst wurde.
  4. Wenn der Sprint keinen Sinn mehr macht.
  5. Wenn nicht mehr genug Aufgaben für den Sprint zur Verfügung stehen.
  1. Der Product Owner wählt die Einträge aus, die aus seiner Sicht für den Kunden am meisten Wert liefern.
  2. Das Product Backlog wird nach Priorität geordnet.
  3. Nach dem WSJF.
  4. Das Product Backlog wird nach dem Wunsch des Kunden sortiert.
  1. Die Entwickler selbst organisieren sich zu passenden Teams.
  2. Die disziplinarischen Vorgesetzten entscheiden, wer in welches Team kommt.
  3. Der Product Owner bestimmt, wer aus Sicht des Produktes am besten zusammen in einem Team arbeiten kann.
  4. Die Product Owner bestimmen, wer aus Sicht des Produktes am besten zusammen in einem Team arbeiten kann.
  1. ...ist verantwortlich (accountable) für die Sortierung der Backlog Items.
  2. ...kümmert sich um das Einbinden der richtigen Stakeholder.
  3. ...ist verantwortlich für das Entfernen von Hindernissen, die die Arbeit des Entwicklungsteams behindern.
  4. ...steuert aktiv die alltäglichen Aufgaben des Entwicklungsteams.
  5. ...entscheidet über die Verwendung der Technologien, die im Entwicklungsprozess verwendet werden.
  1. Sie können in der Definition of Done aufgenommen werden.
  2. Sie können als Azeptanzkriterium aufgenommen werden.
  3. Sie können im einem separaten Sprint nach der Entwicklung umgesetzt werden.
  4. Sie können durch eine andere Abteilung übernommen werden, die nicht im Sprint mitarbeitet.
  1. Es gibt keinen Sprint 0.
  2. Die Vorbereitung für das Sprint Planning.
  3. Die Vorbereitung für das Product Backlog.
  4. Die Infrastruktur wird bereitgestellt.
  1. Dem Product Owner helfen, die Einträge zu sortieren. (Coaching & Management des Scrum Prozesses)
  2. Den Kunden fragen, ob er unterstützen kann.
  3. Die Länge des Sprints ausdehnen, um mehr Zeit für den Product Owner frei zu machen, um die Einträge zu sortieren.
  4. Das Entwicklungsteam bitten die Periodisierung der Product Backlog Items vorzunehmen.
  1. Er kommuniziert und arbeiten mit den Stakeholdern.
  2. Er beantwortet Fragen des Entwicklungsteams zu den Product Backlog Einträgen.
  3. Er führt die Daily Scrums durch.
  4. Er priorisiert die Aufgaben des Entwicklungsteams.
  1. Richtig
  2. Falsch
  1. Es kann mehrere Definition of Done geben, solange sie dazu führen, dass am Ende ein potentiell auslieferbares Produktinkrement erzeugt wird.
  2. "Es sollte nur eine DoD für alle Teams geben.
  3. Jedes Team bestimmt seine DoD unabhängigngig von allen anderen.
  4. Es kann mehrere Definition of Done geben, wenn diese mit dem Kunden abgesprochen sind.

Diese Kurse könnten Sie interessieren

Scrum – Agiles Projektmanagement
Scrum – Agiles Projektmanagement
Dipl.-Wirtschafts.-Ing(FH), M.Sc. Sebastian Schneider
(5)
55,65 € mtl. 24,99 € mtl.
Sie sparen 55 %
Scrum: Prüfungsvorbereitung
Scrum: Prüfungsvorbereitung
Dipl.-Wirtschafts.-Ing(FH), M.Sc. Sebastian Schneider
(1)
6,36 € mtl. 5,99 € mtl.
Sie sparen 6 %

Dozent des Vortrages Prüfungsrelevantes aus Sprint 2

Dipl.-Wirtschafts.-Ing(FH), M.Sc. Sebastian Schneider

Dipl.-Wirtschafts.-Ing(FH), M.Sc. Sebastian Schneider

Sebastian Schneider arbeitet seit 2005 mit dem agilen Projektmanagement Framework Scrum, hat eine Vielzahl von Projekten selbst als Product Owner, Scrum Master, Agile Coach und Certified Team Coach (Scrum Alliance) begleitet und berät seit 2011 Kunden in unterschiedlichen Branchen mit Schwerpunkt Automotive. Mit dem ScrumKurs24.de stellt er eine Wissensbasis rund um Scrum zur Verfügung und hat es sich zur Aufgabe gemacht, Kunden zu befähigen Produkte zu entwickeln, die deren Kunden lieben!

Kundenrezensionen

(1)
5,0 von 5 Sternen
5 Sterne
5
4 Sterne
0
3 Sterne
0
2 Sterne
0
1  Stern
0

© 2024 Lecturio GmbH. Alle Rechte vorbehalten.

Betreuung durch Dozenten
Auch unterwegs auf Tablet und Smartphone lernen
100% Geld-zurück-Garantie