Inspect and Adapt - Our Scrum

Hier nun Ihre Bewertungsbögen für Ihr Scrum Team. Die Original-Aussagen dies Scrum Guide 2020 sind die Grundlage für die Items *)

Der Zeitaufwand je Umfrage liegt zwischen 10 min und 30 min.

Methodischer Hintergrund: Diese Umfragen sind ein Teil unserer Sente Scrum-Diagnostik.
– In Scrum leben wir das Prinzip „Transparenz“.
– Wir verbessern uns stetig, weil wir „Beobachten“ und „Anpassungen“ vornehmen.
Diese Umfragen sind quasi die Beobachtung.
Die Umfrage-Ergebnisse helfen ihrem Scrum Master und Ihrem Team, diejenigen Anpassungen anzupacken, die den größten Value für das Team erzeugen werden.

Mit den Umfragen nehmen wir Ihre persönliche Meinung über Ihr Scrum Team auf. Sie vergeben einfach Schulnoten.

Wir haben die Anforderungen des Original Scrum Guide 2020 (deutsch) in 5 Umfragen mit 22 bis 50 Fragen aufgeteilt. Ein paar Sätze des Guides haben wir leicht abgewandelt. Dadurch können wir das unterhaltsame Bewertungs-Format anbieten und dennoch die Verständlichkeit erhalten.

Lesen Sie jetzt die Anleitung oder starten Sie direkt mit der ersten Umfrage, die sie bearbeiten möchten:

Anleitung
Umfrage I
Scrum
Framework
Umfrage II
Team
Increment
Sprint Review
Umfrage III
Product Owner
Product Backlog
Sprint Planning
Umfrage IV
Developer
Sprint Backlog
Daily Scrum
Umfrage V
Scrum Master
Sprint
Sprint Retro

Anleitung

Hinweise zur Registrierung

Wenn Sie oder Ihr Team bereits für die Teilnahme an der Umfrage bereits registriert sind, brauchen Sie nichts zu beachten. Wählen Sie aus den fünf Umfragen diejenigen aus, die Sie bearbeiten möchten.
Wenn Sie noch nicht registriert sind, können Sie die Umfrage dennoch machen. Wir holen die Registrierung nach. Die Teilnahme und die erste Übersichtsauswertung sind kostenlos. Bitte beachten Sie, dass
- wir keine Privatkunden bedienen. Bitte nutzen Sie also eine klar erkenntliche Firmen-Email-Adresse.
- wir den Registrierungsprozess manuell – also durch Menschen – durchführen. Es kann also – dauern, bis die Registrierung abgeschlossen ist.
- „wenn’s brennt“ Sie uns gerne über unsere Kontaktkanäle erreichen.
- Scrum Master oder Agile Coaches besonders günstige Konditionen für Teamumfragen und Detailauswertungen bekommen.

Zweck und Inhalt der Umfrage

Mit den Umfragen nehmen wir Ihre persönliche Meinung über Ihr Scrum Team auf.
Wählen sie die erste Umfrage, die sie bearbeiten möchten, aus den Tabs oben aus.

Wir haben die Anforderungen des Scrum Guide 2020 in 5 Umfragen mit 22 bis 50 Fragen aufgeteilt. So können sie zwischendurch „mal gwschwind“ teilnehmen oder auch die komplette Umfrage „am Stück“ machen.

Start der Umfrage

Bei jedem Fragebogen geben sie Bitte Ihre E-Mail-Adresse ein und wählen das Schulnotensystem für Ihr Land aus.

Items

Jedes Item besteht aus einer Aussage aus dem Scrum Guide. Zusätzlich haben wir fett ergänzt, was diese Aussage konkret bedeutet.

Manche Aussagen sind informativ, deshalb ist dort keine Bewertungsmöglichkeit vorgesehen.

Bewertung

Sie bewerten einfach nach den Schulnoten (Die beste Noten steht in der Auswahlliste oben. Haben Sie das richtige Land ausgewählt?)

Wenn Sie das Item nicht bewerten können, klicken sie „unbekannt“.

Kommentar (optional)

Über die Spalte „Kommentar“ haben Sie die Möglichkeit, Ihre Antwort zu erläutern. Das kann für Ihren Scrum Master hilfreich sein.

Senden

Drücken Sie am Ende des Fragebogens „Senden“.
Sie erhalten die Bestätigung, dass Ihre Antworten übertragen wurden.

Bis auf die Kommentarfelder sind alle Felder Pflichtfelder.
Sie bekommen eventuell den Hinweis, dass einige Felder noch nicht ausgefüllt sind. Scrollen Sie einfach nach oben. Die entsprechenden Felder sind markiert. Wenn alle Felder ausgefüllt sind drücken sie nochmal auf „Senden“.

Umfrage I - Scrum Framework & Events & Rollen & Artifacts

Bitte geben Sie zuerst Ihre E-Mail-Adresse ein.
Welches Schulnotensystem wollen Sie verwenden?	DEATCH

Ablauf

Bewerten Sie die Aussagen aus dem Scrum Guide in Bezug auf Ihr Team. Fragen Sie sich bei jedem Item:
- Stimmen meine Teamkollegen den Aussagen des Scrum Guide 2020 zu?
- Welche Note vergebe ich meinem Team für die Anwendung dieser Anforderung?

Sie können, Kommentare schreiben, wenn Sie ihre Bewertung erläutern möchten. Schliessen Sie Ihren Bewertungsbogen mit 'Senden' ab.

Fragebogen

id	Scrum Guide Aussagen	Note	Kommentar (optional)
1	Der Scrum Guide enthält die Definition von Scrum. Der Inhalt des Scrum Guides ist im Team bekannt und akzeptiert.
2	Jedes Element von Scrum dient einem bestimmten Zweck, der für den Gesamtwert und die mit Scrum erzielten Ergebnisse wesentlich ist. Die Zwecke der Elemente sind im Team bekannt und akzeptiert.
3	Den Kern oder die Grundideen von Scrum zu verändern, Elemente wegzulassen oder den Regeln von Scrum nicht zu folgen, verdeckt Probleme, begrenzt den Nutzen und macht Scrum im Zweifel sogar nutzlos. Wir verwenden Scrum im Team entsprechend Regeln aus dem Scrum Guide
4	Der Einsatz von Scrum ist besonders sinnvoll in einer stetig komplexer werdenden Welt.
5	Scrum kann in zahlreichen Bereichen komplexer Arbeit eingesetzt werden - nicht nur im Bereich der Softwareentwicklung. Unser Unternehmen setzt Scrum dort ein, wo es Sinn macht.
7	Beim Einsatz von Scrum können Muster, Prozesse und Erkenntnisse angewendet und entwickelt werden, die zum Scrum-Rahmenwerk passen, wie es in diesem Dokument (Scrum Guide) beschrieben ist. Die Tools die wir im Scrum Team einsetzen unterstützen uns in hohem Maß.
217	Ihre Beschreibung geht über den Zweck des Scrum Guides hinaus, da sie kontextabhängig sind und sich, je nachdem wie Scrum eingesetzt wird, stark unterscheiden. (Solche Taktiken für die Anwendung innerhalb des Scrum-Rahmenwerks variieren stark und werden an anderer Stelle beschrieben.)
8	Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.
9	Kurz gesagt fordert Scrum, dass ein Scrum Master ein Umfeld fördert, in dem 1. ein Product Owner die Arbeit für ein komplexes Problem in ein Product Backlog einsortiert; 2. das Scrum Team aus einer Auswahl dieser Arbeit innerhalb eines Sprints ein wertvolles Increment erzeugt; 3. das Scrum Team und dessen Stakeholder die Ergebnisse überprüfen und für den nächsten Sprint anpassen; 4. diese Schritte wiederholt werden. Bei uns im Team ...
10	Scrum ist einfach. Probiere es so aus, wie es ist, und finde heraus, ob seine Philosophie, Theorie und Struktur dabei helfen, Ziele zu erreichen und Wert zu schaffen.
11	Das Scrum-Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum-Theorie erforderlich sind. Das ist im Unternehmen allgemein bekannt.
12	Scrum baut auf der kollektiven Intelligenz der Personen auf, die es anwenden.
13	Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Regeln von Scrum ihre Beziehungen und Interaktionen. Das erlebe ich genau so in der täglichen Arbeit.
14	Innerhalb des Rahmenwerks können verschiedene Prozesse, Techniken und Methoden eingesetzt werden. Unsere Tools und Entwicklungsprozesse sind nahtlos mit Scrum verbunden.
15	Scrum umhüllt bestehende Praktiken oder macht sie überflüssig.
16	Scrum macht die relative Wirksamkeit des aktuellen Managements, der Umgebung und der Arbeitstechniken sichtbar, so dass Verbesserungen vorgenommen werden können. Das wird vom Management bei uns gefördert.
17	Scrum basiert auf Empirie und Lean Thinking.
18	Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf der Grundlage von Beobachtungen getroffen werden. Unsere Entscheidungen basieren auf praktischen Erkenntnissen - nicht auf Mutmassungen oder theoretischen Annahmen.
19	Lean Thinking reduziert Verschwendung und fokussiert auf das Wesentliche. Wir kennen die sieben Verschwendungsarten und vermeiden Verschwendung kontinuierlich und konsequent.
20	Scrum verwendet einen iterativen, inkrementellen Ansatz zur Optimierung der Vorhersagbarkeit und zur Risikokontrolle. Wir können unsere Versprechen untereinander und gegenüber den Stakholdern einhalten. Wir erkennen Risiken frühzeitig.
24	Transparenz: Der sich entwickelnde Prozess und die entstehende Arbeit müssen sowohl für diejenigen sichtbar sein, die die Arbeit ausführen, als auch für diejenigen, die die Arbeit empfangen. Wir haben ausreichende Transparenz zu allen Aspekten, die für unsere Arbeit notwendig sind.
25	Bei Scrum basieren wichtige Entscheidungen auf dem wahrgenommenen Zustand seiner drei formalen Artefakte. Unsere Entscheidungen basieren auf dem Status von den Items bei Increments, im Sprint Backlog und Producht Backlog.
26	Artefakte, die wenig transparent sind, können zu Entscheidungen führen, die den Wert mindern und das Risiko erhöhen. Unser Product Backlog, Sprint Backlog und unsere Increments sind sehr klar und verständlich aufbereitet.
27	Transparenz ermöglicht Überprüfung. Eine Überprüfung ohne Transparenz ist irreführend und verschwenderisch.
28	Überprüfung: Der Fortschritt in Richtung der vereinbarten Ziele müssen häufig und sorgfältig überprüft werden, um potenziell unerwünschte Abweichungen oder Probleme aufzudecken. Wir überprüfen - zumindest in den Dailys, Sprint Review und Sprint Retro - wo wir vom vereinbarten Ziel abweichen. Probleme können wir offen ansprechen und benennen und Lösungsansätze diskutieren.
29	Überprüfung: Die Scrum-Artefakte müssen häufig und sorgfältig überprüft werden, um potenziell unerwünschte Abweichungen oder Probleme aufzudecken. Wir überprüfen, ob unser Product Backlog, Sprint Backlog und unsere Increments den geplanten Zustand haben. Probleme können wir offen ansprechen und benennen und gemeinsam rasch lösen.
31	Überprüfung ermöglicht Anpassung. Überprüfung ohne Anpassung wird als unsinnig betrachtet.
32	Scrum Events sind darauf ausgerichtet, Veränderungen zu bewirken. Sowohl unsere Teammitglieder als auch unsere Stakeholder und unser Management begrüßen die von uns angestrebten Veränderungen.
33	Anpassung: Wenn einzelne Aspekte eines Prozesses von akzeptablen Grenzen abweichen oder wenn das resultierende Produkt nicht akzeptabel ist, müssen der angewandte Prozess oder die produzierten Ergebnisse angepasst werden. Wir haben Akzeptanzkritieren für Qualität. Wir korrigieren dabei nicht nur die Ergebnisse unserer Arbeit sondern auch - wenn nötig - den Prozess der zum nicht akzeptablen Ergebniss geführt hat.
34	Die Anpassung muss so schnell wie möglich erfolgen, um weitere Abweichungen zu minimieren. Abweichungen korrigieren wir in der Regel unverzüglich. Dort wo wir auf Dritte angewiesen sind suchen wir rasch das Gespräch, um rasche Anpassungen voranzutreiben.
35	Die Anpassung wird schwieriger, wenn die beteiligten Personen nicht bevollmächtigt (empowered) sind oder sich nicht selbst managen können. Alle Anpassungen - die unser tägliches Arbeiten in Richtung Increment, Sprint Ziel und Product Goal betreffen - können wir eigenständig im Team vornehmen.
37	Die erfolgreiche Anwendung von Scrum hängt davon ab, dass die Menschen immer besser in der Lage sind, fünf Werte zu leben: - Commitment: die vereinbarten Ziele zu erreichen und sich gegenseitig zu unterstützen - Fokus: die Arbeit des Sprint, u mden bestmöglichen Fortschritt in Richtung der Ziele - Offenheit: in Bezug auf die Arbeit und die Herausforderungen - Respekt: als fähige, unabhängige Personen - Mut: an schwierigen Problemen zu arbeiten
44	Die Entscheidungen, die getroffen werden, die Schritte, die unternommen werden, und die Art und Weise, wie Scrum angewendet wird, sollten diese Werte stärken und nicht schmälern oder untergraben. Bei unseren Entscheidungen denken wir nicht nur an die Stakeholder und das Product sondern auch an unsere Teamentwicklung aus fähigen, unabhängigen und respektierten Persönlichkeiten.
209	Das Scrum-Rahmenwerk, wie es hier beschrieben wird, ist unveränderlich. Unser Team arbeitet innerhalb des Rahmens, den der Scrum Guide vorgibt. Dinge bei denen wir vom Scrum Guide abweichen, haben wir dokumentiert, um uns auch hier die nötige Transparenz zu geben.
210	Es ist zwar möglich, nur Teile von Scrum zu implementieren, aber das Ergebnis ist nicht Scrum. Unser Scrum beinhaltet alle Elemente und Regeln des Scrum Guides.
211	Scrum existiert nur in seiner Gesamtheit und funktioniert gut als Container für andere Techniken, Methodiken und Praktiken. Wir setzen Scrum gezielt als Container für unseren Entwicklungsprozess ein.
22	Scrum kombiniert vier formale Events zur Überprüfung und Anpassung innerhalb eines umspannenden Events, des Sprints.
23	Diese Events funktionieren, weil sie die empirischen Scrum-Säulen Transparenz, Überprüfung und Anpassung implementieren.
30	Um bei der Überprüfung zu helfen, bietet Scrum einen Rhythmus in Form seiner fünf Events.
101	Jedes Event in Scrum ist eine formelle Gelegenheit, Scrum-Artefakte zu überprüfen und anzupassen.
102	Diese Events sind speziell darauf ausgelegt, die erforderliche Transparenz zu ermöglichen. Unsere Scrum Events geben uns Klarheit über unsere Zusammenarbeit, Prozesse, Arbeitsergebnisse bzw. den Wert für die Stakeholder
103	Wenn ein Event nicht wie vorgeschrieben durchgeführt wird, verpasst man die Gelegenheit, zu überprüfen und anzupassen. Unser Scrum Events entprechen den Vorgaben des Scrum Guides.
104	Events werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Meetings, die in Scrum nicht definiert sind, zu minimieren. Wir brauchen keine anderen großen Meetings - ausser den Scrum Events - um unsere Projektziele zu erreichen.
105	Optimalerweise werden alle Events zur selben Zeit und am selben Ort abgehalten, um die Komplexität zu reduzieren. Unsere Meetings sind in der Regel zur gleichen Zeit und am selben Ort.
161	Die Artefakte von Scrum repräsentieren Arbeit oder Wert. Sie sind dafür ausgelegt, die Transparenz von Schlüsselinformationen zu maximieren. So haben alle, die sie überprüfen, die gleiche Grundlage für Anpassungen. Jeder (Experte) - der unvorbereitet auf unser Product Backlog, Sprint Backlog und die Increments blickt - kann sich schnell orientieren. Die wesentlichen Informationen sind klar und vollständig vorhanden.
162	Jedes Artefakt beinhaltet ein Commitment, um sicherzustellen, dass Informationen bereitgestellt werden, welche Transparenz und Fokus verbessern, um den Fortschritt messbar zu machen:
163	Commitment: Für das Product Backlog ist es das Produkt-Ziel. Unser Team hat sich aktiv zum Product Goal committed.
164	Commitment: Für das Sprint Backlog ist es das Sprint-Ziel. Unser Team committed sich regelmäßig aktiv zum Sprint Goal.
165	Commitment: Für das Increment ist es die Definition of Done. Unser Team hat sich aktiv zu den Defintion of Done committed.
166	Diese Commitments dienen dazu, Empirie und die Scrum-Werte für das Scrum Team und seine Stakeholder zu verstärken.

Umfrage II Team & Increment & Sprint Review

Bitte geben Sie zuerst Ihre E-Mail-Adresse ein.
Welches Schulnotensystem wollen Sie verwenden?	DEATCH

Ablauf

Sie können, Kommentare schreiben, wenn Sie ihre Bewertung erläutern möchten. Schliessen Sie Ihren Bewertungsbogen mit 'Senden' ab.

Fragebogen

id	Scrum Guide Aussagen	Note	Kommentar (optional)
21	Scrum setzt auf Personengruppen, die gemeinsam über alle Fähigkeiten und Fachkenntnisse verfügen, um die Arbeit zu erledigen und solche Fähigkeiten im Bedarfsfall zu teilen oder zu erwerben.
36	Von einem Scrum Team wird erwartet, dass es sich in dem Moment anpasst, in dem es durch Überprüfung etwas Neues lernt. Wir nutzen unsere Scrum Events, um unsere Zusammenarbeit, Arbeitsprozesse und Arbeitsergebnisse kritisch zu prüfen. Und: Aus diesem Wissen heraus, verändern wir gezielt, um stetig besser zu werden.
38	Das Scrum Team committet sich, seine Ziele zu erreichen und sich gegenseitig zu unterstützen. In unserem Team commiten wir uns zum Product Goal, den Sprint Goals und den jeweils gültigen Definition of Done.
39	Ein primärer Fokus liegt auf der Arbeit des Sprints, um den bestmöglichen Fortschritt in Richtung dieser Ziele zu bewirken. In unserem Team arbeiten wir fokussiert auf die Erreichung der Sprint Ziele. Unsere Events sind ebenso klar auf den jeweiligen Zweck fokussiert.
40	Das Scrum Team und dessen Stakeholder sind offen in Bezug auf die Arbeit und die Herausforderungen. In unserem Team ändern wir unsere Pläne, wenn neue Herausforderungen die bisherige Situation ändern.
41	Die Mitglieder des Scrum Teams respektieren sich gegenseitig als fähige, unabhängige Personen und werden als solche auch von den Menschen, mit denen sie zusammenarbeiten, respektiert. Jeder in unseren Team kann unabhängig und frei seine Expertise einbringen. Jeder im Team respektiert die individuellen Stärken und Schwächen der anderen Team-Mitglieder. Kurz: Wir ergänzen uns in unseren Stärken und helfen uns gegenseitig in unseren Schwächen.
42	Die Mitglieder des Scrum Teams haben den Mut, das Richtige zu tun: an schwierigen Problemen zu arbeiten. In unserem Team stellen wir uns den schwierigen Aufgaben und werden deshalb von aussen als High-Performance-Team wahrgenommen.
43	Diese Werte geben dem Scrum Team die Richtung vor, was seine Arbeit, seine Handlungen und sein Verhalten betrifft.
45	Die Mitglieder des Scrum Teams lernen und erforschen die Werte, während sie in den Events und mit den Artefakten von Scrum arbeiten. Wir kennen vielleicht nicht alle Scrum-Werte im Detail. Wir arbeiten aber dennoch ständig daran, Commitment, Fokus, Offenheit, Respekt und Mut zu trainieren
46	Wenn diese Werte durch das Scrum Team und die Menschen, mit denen es arbeitet, verkörpert werden, werden die empirischen Scrum-Säulen Transparenz, Überprüfung und Anpassung lebendig und bauen Vertrauen auf. In unserem Team ist Professionalität und Vertrauen spürbar. Auch unsere Kunden und Stakeholder wissen, dass sie sich auf uns verlassen können.
47	Der zentrale Bestandteil von Scrum ist ein kleines Team von Menschen, ein Scrum Team.
48	Das Scrum Team besteht aus einem Scrum Master, einem Product Owner und Developern.
49	Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien. Das ist bei uns der Fall.
50	Es handelt sich um eine geschlossene Einheit von Fachleuten, die sich auf ein Ziel konzentrieren, das Produkt-Ziel. Das ist bei uns der Fall.
51	Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen. In unserem Team sind wirklich alle Fähigkeiten - die wir brauchen, um "liefern zu können" - vorhanden.
213	Scrum Teams ... managen sich außerdem selbst, d.h. sie entscheiden intern, wer was wann und wie macht. Prioritäten oder Störungen die von ausserhalb unseres Teams kommen, gefährden zu keinem Zeitpunkt die Sprint Ziele.
52	Das Scrum Team ist klein genug, um flink zu bleiben und groß genug, um innerhalb eines Sprints bedeutsame Arbeit fertigzustellen, üblicherweise 10 oder weniger Personen. Das ist bei uns der Fall.
53	Im Allgemeinen haben wir (Anm. scrum.org) festgestellt, dass kleinere Teams besser kommunizieren und produktiver sind.
54	Wenn Scrum Teams zu groß werden, sollten sie in Erwägung ziehen, sich in mehrere zusammengehörende Scrum Teams zu reorganisieren, die sich alle auf dasselbe Produkt konzentrieren. Daher sollten sie sich Produkt-Ziel, Product Backlog und Product Owner teilen.
56	Das Scrum Team ist umsetzungsverantwortlich (responsible) für alle produktbezogenen Aktivitäten: Zusammenarbeit mit den Stakeholdern, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte. Wir entwickeln unser Product so, dass wir für die gesamte Lebensdauer im Blick haben. Fehlerbehebungen im Betrieb, beim Service und in der Wartung bedeuten für uns einen vernachlässigbaren Aufwand
214	Das Scrum Team ... ist von der Organisation so aufgebaut und befähigt, dass es seine Arbeit selbst steuert. Unser Team hat von der Organisation alle Kompetenzen erhalten, um eigenständig handlungsfähig zu sein.
57	Das Arbeiten in Sprints mit einer nachhaltigen Geschwindigkeit verbessert den Fokus und die Kontinuität des Scrum Teams. Wir arbeiten fokussiert und kontinuierlich auf das Sprintziel hin. Die Zahl der erledigten Items bzw. Storypoints ist beeindruckend.
58	Das gesamte Scrum Team ist ergebnisverantwortlich (accountable), in jedem Sprint ein wertvolles, nützliches Increment zu schaffen. Wir liefen in jedem Sprint ein oder mehrere - aus Sicht der Stakeholder - wertvolles, nützliches Increment.
59	Scrum definiert drei spezifische Ergebnisverantwortlichkeiten innerhalb des Scrum Teams: Developer, Product Owner und Scrum Master (Anm. Die Verantwortlicheiten werden in den drei spezifischen Umfragen vorgestellt.)
145	Zweck des Sprint Reviews ist es, das Ergebnis des Sprints zu überprüfen und künftige Anpassungen festzulegen.
146	Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholdern vor, und die Fortschritte in Richtung des Produkt-Ziels werden diskutiert. Unsere Stakeholder geben uns in dem Sprints Reviews wertvolle Impulse für die Arbeit der nächsten Sprints.
147	Während des Events überprüfen das Scrum Team und die Stakeholder, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat. Bei unseren Sprint Reviews ist das der Fall.
148	Auf der Grundlage dieser Informationen arbeiten die Teilnehmenden gemeinsam daran, was als Nächstes zu tun ist. Bei uns im Sprint Review erarbeiten wir gemeinsam mit den Stakeholdern was als Nächstes zu tun ist.
149	Auch kann das Product Backlog angepasst werden, um neue Möglichkeiten wahrzunehmen. In unseren Sprint Reviews ist das der Fall.
150	Das Sprint Review ist ein Arbeitstermin, und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken. So leben wir das in unseren Sprint Reviews.
151	Das Sprint Review ist das vorletzte Event des Sprints und ist für einen einmonatigen Sprint auf maximal vier Stunden zeitlich beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer. Die Dauer des Sprint Reviews ist genau richtig.
198	Das Sprint Review sollte niemals als Barriere zur Lieferung von Wert angesehen werden. Unsere Stakeholder und wir verstehen das Sprint Review definitiv nicht als Gate-Prozess. Wert wird bei uns in die Releases sofort eingearbeitet.
192	Ein Increment ist ein konkreter Schritt in Richtung des Produkt-Ziels.
193	Jedes Increment ist additiv zu allen vorherigen Increments und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren. Unsere Releases werden ausführlich und ausreichend getestet. Fehler und Bug sind deshalb minimal.
194	Um einen Mehrwert zu erzielen, muss das Increment verwendbar sein. Das ist bei uns der Fall.
195	Innerhalb eines Sprints kann mehr als ein Increment erstellt werden. Das ist bei uns der Fall.
196	Deren Summe wird im Sprint Review vorgestellt, womit Empirie unterstützt wird. Wir zeigen ehrlich das, was ist. Unsere Stakeholder können mit dieser Ehrlichkeit gut umgehen.
197	Ein Increment könnte jedoch auch schon vor Ende des Sprints an die Stakeholder geliefert werden. Das ist bekannt und wird auch manchmal gemacht.
199	Arbeit kann nicht als Teil eines Increments betrachtet werden, solange sie nicht der Definition of Done entspricht. Das ist bei uns der Fall.
200	Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt. Die Qualität ist bei uns ausreichend - aber nicht blockierend - in den DoD beschrieben.
201	In dem Moment, in dem ein Product-Backlog-Eintrag die Definition of Done erfüllt, wird ein Increment geboren. Das leben wir so.
202	Die Definition of Done schafft Transparenz, indem sie allen ein gemeinsames Verständnis darüber vermittelt, welche Arbeiten als Teil des Increments abgeschlossen wurden. Diese Transparenz hilft und in der täglichen Arbeit und bei Entscheidungen über das "Done". Jedes Teammitglied wäre in der Lage diese Entscheidungen eigenständig zu treffen.
203	Wenn ein Product-Backlog-Eintrag nicht der Definition of Done entspricht, kann es weder released noch beim Sprint Review präsentiert werden. Das leben wir so.
204	Stattdessen wandert es zur zukünftigen Berücksichtigung in das Product Backlog zurück. Das leben wir so.
205	Wenn die Definition of Done für ein Increment Teil der Standards der Organisation ist, müssen alle Scrum Teams diese als Mindestmaß befolgen. Das ist bei uns der Fall.
206	Wenn sie kein Organisationsstandard ist, muss das Scrum Team eine für das Produkt geeignete Definition of Done erstellen. Das leben wir so in unserem Team.
207	Die Developer müssen sich an die Definition of Done halten. Jeder unserer Developer hält sich an die DoD.
208	Wenn mehrere Scrum Teams an einem Produkt zusammenarbeiten, müssen sie eine gemeinsame Definition of Done definieren und sich alle daran halten. Das ist bei uns der Fall. Die Teams, die an einem Produkt bzw. einem System arbeiten haben die gleiche Definition of Done. Für Increments, die nur mit Hilfe andere Teams geschaffen werden können, haben wir uns zu teamübergreifenden DoD committed.

Umfrage III Product Owner & Product Backlog & Sprint Planning

Bitte geben Sie zuerst Ihre E-Mail-Adresse ein.
Welches Schulnotensystem wollen Sie verwenden?	DEATCH

Ablauf

Sie können, Kommentare schreiben, wenn Sie ihre Bewertung erläutern möchten. Schliessen Sie Ihren Bewertungsbogen mit 'Senden' ab.

Fragebogen

id	Scrum Guide Aussagen	Note	Kommentar (optional)
66	Der Product Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt. Bei uns im Team ...
67	Wie dies geschieht, kann je nach Organisation, Scrum Team und Individuum sehr unterschiedlich sein.
68	Der Product Owner ist auch für ein effektives Product-Backlog-Management ergebnisverantwortlich, das Folgendes umfasst:
69	Product Owner: Das Produkt-Ziel zu entwickeln und explizit zu kommunizieren; Unser Product Goal ist allen Developer bekannt. Sie arbeiten auf das Product Goal hin.
70	Product Owner: die Product-Backlog-Einträge zu erstellen und klar zu kommunizieren; Die Product Backlog Items sind - nach aktuellem Stand - vollständig,klar und verständlich formuliert
71	Product Owner: die Reihenfolge der Product-Backlog-Einträge festzulegen; und Unser Product Backlog ist nach - für die Stakeholder nutzbarem - Wert sortiert
72	Product Owner: sicherzustellen, dass das Product Backlog transparent, sichtbar und verstanden ist. Die Product Backlog Items sind für die nächsten zwei Sprints klar und verständlich aufbereitet (refined)
73	Der Product Owner kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der Product Owner ergebnisverantwortlich.
75	Damit der Product Owner Erfolg haben kann, muss die gesamte Organisation seine Entscheidungen respektieren. Unser Product Owner trifft Entscheidungen in seiner Ergebnisverantwortung, die von ausserhalb des Teams respektiert werden.
77	Der Product Owner ist eine Person, kein Gremium.
78	Der Product Owner kann die Bedürfnisse vieler Stakeholder im Product Backlog berücksichtigen.
79	Diejenigen, die das Product Backlog ändern möchten, können dies tun, indem sie versuchen, den Product Owner zu überzeugen. Unser Product Backlog liegt in der alleinigen Verantwortung des Product Owners.
121	Das Sprint Planning initiiert den Sprint, indem es die für den Sprint auszuführenden Arbeiten darlegt.
122	Dieser resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum Teams erstellt. Am Ende des Sprint Planning Events kennen alle Team-Mitglieder den Arbeitsumfang für den nächsten Sprint.
123	Der Product Owner stellt sicher, dass die Teilnehmenden vorbereitet sind, die wichtigsten Product-Backlog-Einträge zu besprechen, und wie sie dem Produkt-Ziel zuzuordnen sind. Das Sprint Planning ist in der Regel durch den Product Owner so gut vorbereitet, dass die Developer die vorgestellten Items sachkundig beurteilen und den Arbeitsaufwand abschätzen können.
124	Das Scrum Team kann zu Beratungszwecken auch andere Personen zur Teilnahme am Sprint Planning einladen.
125	Das Sprint Planning behandelt die folgenden Themen: - Value: Warum ist dieser Sprint wertvoll (für den bzw. die Stakeholder ? - Machbar: Was kann in diesem Sprint abgeschlossen werden? - How: Wie wird die ausgewählte Arbeit erledigt?
126	Wertvoll: Der Product Owner schlägt vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Bei uns im Team ...
127	Wertvoll: Das gesamte Scrum Team arbeitet dann zusammen, um ein Sprint-Ziel zu definieren, das verdeutlicht, warum der Sprint für die Stakeholder wertvoll ist. Bei uns im Team ...
128	Wertvoll: Das Sprint-Ziel muss vor dem Ende des Sprint Plannings finalisiert sein. Bei uns im Team ...
129	Machbar: Im Gespräch mit dem Product Owner wählen die Developer Einträge aus dem Product Backlog aus, die in den aktuellen Sprint aufgenommen werden sollen. Bei uns im Team ...
130	Machbar: Das Scrum Team kann diese Einträge während dieses Prozesses verfeinern, was Verständnis und Vertrauen erhöht. Bei uns im Team ...
131	Machbar: Die Auswahl, wie viel innerhalb eines Sprints abgeschlossen werden kann, kann eine Herausforderung darstellen.
132	Machbar: Je mehr die Developer jedoch über ihre bisherige Leistung, ihre zukünftige Kapazität und ihre Definition of Done wissen, desto sicherer werden sie in ihren Sprint-Vorhersagen sein. Die Abschätzungen sind in unserem Team recht gut. Wir erreichen regelmäßig unsere (herausfordenden) Sprintziele
133	How: Für jeden ausgewählten Product-Backlog-Eintrag planen die Developer die notwendige Arbeit, um ein Increment zu erstellen, das der Definition of Done entspricht.
134	How: Dies geschieht oft durch Zerlegung von Product-Backlog-Einträgen in kleinere Arbeitseinheiten von einem Tag oder weniger. Wie dies geschieht, liegt im alleinigen Ermessen der Developer. Unsere Developer ...
135	How: Niemand sonst sagt ihnen (den Developern), wie sie Product-Backlog-Einträge in Increments von Wert umwandeln sollen. Die Developer planen vollkommen eigenständig
136	Das Sprint-Ziel, die für den Sprint ausgewählten Product-Backlog-Einträge und der Plan für deren Lieferung werden zusammenfassend als Sprint Backlog bezeichnet.
137	Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist das Event in der Regel kürzer.
167	Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden.
168	Es ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird.
169	Product-Backlog-Einträge, die durch das Scrum Team innerhalb eines Sprints abgeschlossen (Done) werden können, gelten als bereit für die Auswahl in einem Sprint-Planning-Event.
170	Diesen Transparenzgrad erlangen sie in der Regel durch Refinement-Aktivitäten.
171	Das Refinement des Product Backlogs ist der Vorgang, durch den Product-Backlog-Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden.
172	Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld.
173	Die Developer, die die Arbeit erledigen werden, sind für die Größenbestimmung umsetzungsverantwortlich.
174	Der Product Owner kann die Developer beeinflussen, indem er dabei unterstützt, die Product-Backlog-Einträge zu verstehen und Kompromisse einzugehen.
175	Das Produkt-Ziel beschreibt einen zukünftigen Zustand des Produkts, welches dem Scrum Team als Planungsziel dienen kann.
176	Das Produkt-Ziel befindet sich im Product Backlog.
177	Der Rest des Product Backlogs entsteht, um zu definieren, „was“ das Produkt-Ziel erfüllt.
178	Ein Produkt ist ein Instrument, um Wert zu liefern.
179	Es hat klare Grenzen, bekannte Stakeholder, eindeutig definierte Benutzer oder Kunden.
180	Ein Produkt kann eine Dienstleistung, ein physisches Produkt oder etwas Abstrakteres sein.
181	Das Produkt-Ziel ist das langfristige Ziel für das Scrum Team.
182	Das Scrum Team muss eine Zielvorgabe erfüllen (oder aufgeben), bevor es die nächste angeht.
76	Product Owner: Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs sowie durch das überprüfbare Increment beim Sprint Review, sichtbar.

Umfrage IIII Developer & Sprint Backlog & Daily Scrum

Bitte geben Sie zuerst Ihre E-Mail-Adresse ein.
Welches Schulnotensystem wollen Sie verwenden?	DEATCH

Ablauf

Sie können, Kommentare schreiben, wenn Sie ihre Bewertung erläutern möchten. Schliessen Sie Ihren Bewertungsbogen mit 'Senden' ab.

Fragebogen

id	Scrum Guide Aussagen	Note	Kommentar (optional)
6	Wir verwenden das Wort „Developer” in Scrum nicht, um jemanden auszuschließen, sondern um zu vereinfachen: Wer auch immer vom Einsatz von Scrum profitiert, soll sich angesprochen fühlen. (Anm. Developer sind also nicht nur SW-Entwickler, sondern jeder der an der Erstellung eines Increments unmittelbar beteiligt ist.)
212	Developer sind (im Scrum Verständnis) Entwickler, Forscher, Analysten, Wissenschaftler ... und andere Spezialisten wie zum Beispiel Tester, Handwerker, Planer, Verwaltungsangestellte, Verkäufer, Marketingexperten und viele andere. Das wird bei uns so gelebt.
60	Developer sind jene Personen im Scrum Team, die sich der Aufgabe verschrieben haben, jeden Sprint jeden Aspekt eines nutzbaren Increments zu schaffen. Unsere Developer denken und handeln genau so.
61	Die spezifischen Fähigkeiten, die von den Developern benötigt werden, sind oft breit gefächert und variieren je nach Arbeitskontext. In unserem Scrum-Team sind alle Fähigkeiten vorhanden, um die Arbeit - ohne Verzögerungen - zu erledigen.
215	Developer sind jedoch immer ergebnisverantwortlich für:
62	Developer erstellen einen Plan für den Sprint: Das Sprint Backlog; Jeder unserer Developer fühlt sich in hohem Maß für die Erstellung des Sprint Backlogs verantwortlich.
63	Developer bringen Qualität durch die Einhaltung einer Definition of Done ein; Unsere Developer halten die Definition of Done ein. Sie entwickeln die Definition of Done weiter, entflechten komplizierte DoD. Sie sorgen so letztlich für einen leichten, verständlichen Qualitäts-Maßstab.
64	Developer passen täglich ihren Plan zur Erreichung des Sprint-Ziels an; Unsere Developer prüfen täglich, was sie ändern müssen, um das Sprint-Ziel zu erreichen. Sie passen sich demensprechend an.
65	Developer verstehen sich als Profis und Experten. Jeder trägt Verantwortung für das Team und das Erreichen der Ziele. Unsere Developer sprechen eigenverantwortlich Ihre Team-Kollegen (und Dritte) zur Problemlösung an. Sie diskutieren - ohne große Zeitverzögerungen die - Problembeschreibungen und Lösungsideen auf fachlicher Ebene.
138	Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung des Sprint-Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren. Wir nutzen das Daily gezielt, um neue Erkenntnise in unsere Arbeit einfliessen zu lassen und uns selbst im Blick auf das Sprintziel und die geplanten Increments zu überprüfen.
139	Das Daily Scrum ist ein 15-minütiges Event für die Developer im Scrum Team. Wir überschreiten die Zeidauer der Dailys nicht. Das liegt daran, dass wir uns konzentrieren und fokusieren: auf die Aufgaben des heutigen Tags, die Vorstellung relevanter Erkenntnisse und die Klärung von Fragen, um Hindernisse aus dem Weg zu räumen.
140	Um die Komplexität zu reduzieren, wird es an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichen Ort abgehalten. Das ist bei uns der Fall.
141	Falls der Product Owner oder der Scrum Master aktiv an Einträgen des Sprint Backlogs arbeitet, nimmt er als Developer teil. Das ist bei uns der Fall.
142	Die Developer können Struktur und Techniken beliebig wählen, solange ihr Daily Scrum sich auf den Fortschritt in Richtung des Sprint-Ziels fokussiert und einen umsetzbaren Plan für den nächsten Arbeitstag erstellt. Das schafft Fokus und fördert Selbstmanagement. In unseren Dailys sind wir auf das Sprint-Ziel fokussiert. Wir wissen stets genau, was wir an diesem Arbeitstag zu tun haben. Die Daily-Struktur, das Board und Moderationsform unterstützen uns dabei in hohem Maß.
143	Daily Scrums verbessern die Kommunikation, identifizieren Hindernisse, fördern die schnelle Entscheidungsfindung und eliminieren konsequent die Notwendigkeit für andere Meetings. Das ist bei uns der Fall.
144	Das Daily Scrum ist nicht die einzige Gelegenheit, bei der die Developer ihren Plan anpassen dürfen. Sie treffen sich oftmals während des Tages für detailliertere Diskussionen zur Anpassung oder Neuplanung der restlichen Arbeit des Sprints. Das ist bei uns der Fall.
183	Das Sprint Backlog besteht aus dem Sprint-Ziel (Wofür), den für den Sprint ausgewählten Product-Backlog-Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie). Das ist bei uns der Fall
184	Das Sprint Backlog ist ein Plan von und für die Developer. Es ist ein deutlich sichtbares Echtzeitbild der Arbeit, welche die Developer während des Sprints zur Erreichung des Sprint-Ziels ausführen wollen. Das ist bei uns der Fall.
185	Folglich wird das Sprint Backlog während des gesamten Sprints immer dann aktualisiert, wenn mehr gelernt wurde. Es sollte genügend Details beinhalten, damit sie ihren Fortschritt im Daily Scrum überprüfen können. Im Sprint Backlog (und Board) haben wir stets die notwendige Transparenz um, zu sehen wo wir bei der Zielerreichung stehen.
186	Das Sprint-Ziel ist die einzige Zielsetzung für den Sprint. Das ist bei uns der Fall. Wir geben uns zwar mehrere Increment-Ziele, commiten uns dann aber auf ein einziges konkretes Ziel.
187	Obwohl das Sprint-Ziel ein Commitment der Developer ist, bietet es Flexibilität in Bezug auf die genaue Arbeit, die erforderlich ist, um es zu erreichen. Das ist bei uns der Fall.
188	Das Sprint-Ziel schafft auch Kohärenz und Fokus und ermutigt somit das Scrum Team, zusammen statt in separaten Initiativen zu arbeiten. Das ist bei uns der Fall.
189	Das Sprint-Ziel wird während des Sprint-Planning-Events erstellt und dann zum Sprint Backlog hinzugefügt. Das ist bei uns der Fall.
190	Während die Developer innerhalb des Sprints arbeiten, behalten sie das Sprint-Ziel im Gedächtnis. Jeder Developer kennt in der Regel das Sprint-Ziel und die geplanten Increments im Sprint.
191	Wenn sich herausstellt, dass die Arbeit von ihren Erwartungen abweicht, arbeiten sie mit dem Product Owner zusammen, um den Umfang des Sprint Backlogs innerhalb des Sprints zu verhandeln, ohne das Sprint-Ziel zu beeinflussen. Das ist bei uns der Fall.

Umfrage V Scrum Master & Sprint Retro & Sprint

Bitte geben Sie zuerst Ihre E-Mail-Adresse ein.
Welches Schulnotensystem wollen Sie verwenden?	DEATCH

Ablauf

Sie können, Kommentare schreiben, wenn Sie ihre Bewertung erläutern möchten. Schliessen Sie Ihren Bewertungsbogen mit 'Senden' ab.

Fragebogen

id	Scrum Guide Aussagen	Note	Kommentar (optional)
80	Der Scrum Master ist ergebnisverantwortlich für die Einführung von Scrum, wie es im Scrum Guide definiert ist.
81	Der Scrum Master ... tut dies, indem er allen dabei hilft, die Scrum-Theorie und -Praxis zu verstehen, sowohl innerhalb des Scrum Teams als auch in der Organisation. Das ist bei uns der Fall.
82	Der Scrum Master ist ergebnisverantwortlich für die Effektivität des Scrum Teams. Die Effektiv in unserem Team verdient die Note:
83	Der Scrum Master tut dies, indem er das Scrum Team in die Lage versetzt, seine Praktiken innerhalb des Scrum-Rahmenwerks zu verbessern. Unser Scrum Master hilft uns, unser Scrum und unsere Methoden zu verbessern.
84	Scrum Master sind echte Führungspersönlichkeiten, die dem Scrum Team und der Gesamtorganisation dienen. Das ist bei uns der Fall.
85	Der Scrum Master dient dem Scrum Team auf unterschiedliche Weise, unter anderem dadurch,
86	Der Scrum Master coacht das Team in Selbstmanagement und interdisziplinärer Zusammenarbeit; Das ist bei uns der Fall.
87	Der Scrum Master unterstützt das Scrum Team bei der Fokussierung auf die Schaffung von hochwertigen Increments, die der Definition of Done entsprechen; Das ist bei uns der Fall.
88	Der Scrum Master bewirkt die Beseitigung von Hindernissen (impediments) für den Fortschritt des Scrum Teams zu bewirken; und Das ist bei uns der Fall.
89	Der Scrum Master stellt sicher, dass alle Events von Scrum stattfinden, positiv und produktiv sind und innerhalb der Timebox bleiben. Das ist bei uns der Fall.
90	Der Scrum Master dient dem Product Owner auf unterschiedliche Weise, unter anderem dadurch,
91	Der Scrum Master hilft dem Product Owner bei der Suche nach Techniken zur effektiven Definition des Produkt-Ziels und zum Product-Backlog-Management; Das ist bei uns der Fall.
92	Der Scrum Master unterstützt den Product Owner, weil er dem Scrum Team hilft, die Notwendigkeit klarer und prägnanter Product-Backlog-Einträge zu verstehen; Das ist bei uns der Fall.
93	Der Scrum Master hilft dem Product Owner bei der Etablierung einer empirischen Produktplanung für ein komplexes Umfeld; und Das ist bei uns der Fall.
94	Der Scrum Master fördert die Zusammenarbeit mit Stakeholdern nach Wunsch oder Bedarf des Product Owners (facilitate). Das ist bei uns der Fall.
95	Der Scrum Master dient der Organisation auf unterschiedliche Weise, unter anderem dadurch,
96	Der Scrum Master führt, schult und coacht die Organisation bei der Einführung von Scrum Das ist bei uns der Fall.
97	Der Scrum Master plant und empfiehlt Einführungen von Scrum in der Organisation; Das ist bei uns der Fall. Zusätzlich sorgt der Scrum Master dafür, dass die Projektorgansiation mit den Scrum Teams und den Unternehmensabteilungen reibungsfrei verknüpft sind.
98	Der Scrum Master unterstützt Mitarbeitende und Stakeholder beim Verständnis und bei der Umsetzung eines empirischen Ansatzes für komplexe Arbeit; und Das ist bei uns der Fall.
99	Der Scrum Master beseitigt Barrieren zwischen Stakeholdern und Scrum Teams. Das ist bei uns der Fall.
100	Der Sprint ist ein Container für alle anderen Events.
106	Sprints sind der Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden. In unseren Sprint erzeugen wir echten Mehrwert für unsere Kunden und Nutzer.
107	Es sind Events mit fester Länge von einem Monat oder weniger, um Konsistenz zu schaffen.
108	Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints.
109	Alle Arbeiten, die notwendig sind, um das Produkt-Ziel zu erreichen, einschließlich Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective, finden innerhalb der Sprints statt. Unsere Team lebt das.
110	Während des Sprints: werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden würden; Daran halten wir uns im Team ...
111	Während des Sprints nimmt die Qualität nicht ab; In unseren Sprints ist das der Fall ...
112	Während des Sprints wird das Product Backlog nach Bedarf verfeinert; In unseren Sprints ist das der Fall.
113	Während des Sprints kann der Scope (Inhalt und Umfang) geklärt und mit dem Product Owner neu vereinbart werden, sobald mehr Erkenntnisse vorliegen. In unseren Sprints ist das der Fall.
114	Sprints ermöglichen Vorhersagbarkeit, indem sie mindestens jeden Kalendermonat eine Überprüfung und Anpassung der Fortschritte in Richtung eines Produkt-Ziels gewährleisten. In unseren Sprints ist das der Fall. Wir nutzen hierfür Review, Retro, Backlog Refinements.
115	Wenn der Horizont eines Sprints zu lang ist, kann das Sprint-Ziel hinfällig werden, die Komplexität kann steigen und das Risiko kann zunehmen.
116	Kürzere Sprints können eingesetzt werden, um mehr Lernzyklen zu generieren und das Risiko von Kosten und Aufwand auf einen kleineren Zeitrahmen zu begrenzen.
117	Jeder Sprint kann als ein kurzes Projekt betrachtet werden. Das sehen wir im Team genau so.
118	Es gibt verschiedene Vorgehensweisen, um den Fortschritt vorherzusagen, wie Burn-Down-Charts, Burn-Up-Charts oder Cumulative-Flow-Diagramme. Diese haben sich zwar als nützlich erwiesen, ersetzen jedoch nicht die Bedeutung der Empirie. In unserem Team ist der Fortschritt hin zu den Zielen wichtiger als die Tools.
119	In komplexen Umgebungen ist unbekannt, was passieren wird. Nur was bereits geschehen ist, kann für eine vorausschauende Entscheidungsfindung genutzt werden.
120	Ein Sprint könnte abgebrochen werden, wenn das Sprint-Ziel obsolet wird. Nur der Product Owner hat die Befugnis, den Sprint abzubrechen. In unseren Sprints wäre das möglich.
152	Der Zweck der Sprint Retrospective ist es, Wege zur Steigerung von Qualität und Effektivität zu planen.
153	Das Scrum Team überprüft (in der Retro), wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und seine Definition of Done verlief. Die überprüften Elemente variieren oft je nach Arbeitsdomäne. In unseren Retros ist das der Fall.
154	Annahmen, die das Team in die Irre geführt haben, werden (in der Retro) identifiziert und ihre Ursprünge erforscht. In unseren Retros ist das der Fall.
155	Das Scrum Team bespricht (in der Retro), was während des Sprints gut gelaufen ist, auf welche Probleme es gestoßen ist und wie diese Probleme gelöst wurden (oder auch nicht). In unseren Retros ist das der Fall.
156	Das Scrum Team identifiziert (in der Retro) die hilfreichsten Änderungen, um seine Effektivität zu verbessern. In unseren Retros ist das der Fall.
157	Die wirkungsvollsten Verbesserungen (aus der Retro) werden so schnell wie möglich in Angriff genommen. In unseren Retros ist das der Fall.
158	Die wirkungsvollsten Verbesserungen: Sie können sogar in das Sprint Backlog für den nächsten Sprint aufgenommen werden. In unseren Retros ist das bei Bedarf der Fall.
159	Die Sprint Retrospective schließt den Sprint ab.
160	Retro: Sie ist für einen einmonatigen Sprint auf maximal drei Stunden beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer.

Wie gehts weiter?

Sie können auch gerne noch die anderen Fragebögen durcharbeiten.

Ihr Scrum Master bekommt die Ergebnisse der Umfragen. Anhand dieser Ergebnisse erkennt er, wo Impediments schlummern und kann gemeinsam mit den anderen Team-Mitgliedern – zum Beispiel in der nächsten Retrospektive -Lösungen erarbeiten .

Inspect and Adapt – Our Scrum

Anleitung

Hinweise zur Registrierung

Zweck und Inhalt der Umfrage

Start der Umfrage

Items

Bewertung

Kommentar (optional)

Senden

Umfrage I - Scrum Framework & Events & Rollen & Artifacts

Ablauf

Fragebogen

Umfrage II Team & Increment & Sprint Review

Ablauf

Fragebogen

Umfrage III Product Owner & Product Backlog & Sprint Planning

Ablauf

Fragebogen

Umfrage IIII Developer & Sprint Backlog & Daily Scrum

Ablauf

Fragebogen

Umfrage V Scrum Master & Sprint Retro & Sprint

Ablauf

Fragebogen

Wie gehts weiter?

Kontaktieren Sie uns:

Sente Storys

Wichtige Links