easyScrum - Inspect and Adapt (english)

Here are your evaluation forms for your Scrum Team. You will read the original statements of the Scrum Guide 2020 *)

You may need 10 to 30 minutes for each questionnaire.

Methodology: The evaluation is 100% based on Scrum values and Scrum principles.
– Transparency: You check your Scrum team on every single statement of the Scrum Guide.
– Inspect: Your team gets a full picture on how it performs on every Scrum elements.
– Adapt: Your Scrum Master will discuss, which Scrum element should be improved within the next Sprints.

In a nutshell, your answers will help your Scrum Master and your team to focus on needed adjustments. This means Focus on the most valuable improvements for your team.

You will evaluate your team by giving your personal opinion about your Scrum Team. Just use ordinary school grades.

We have divided the requirements of the Original Scrum Guide 2020 into 5 surveys with 22 to 50 questions. There is some slightly modification due to better reading and understanding. You get a playful insight on the Scrum Guide and your team while still maintaining clarity.

Read the instructions now or start directly with the first form you want to edit:

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

Registration

If you or your team are already registered to take part in the survey, you don’t need to do anything. From the five surveys, select the ones you want to edit.
If you are not registered yet , you can still take the survey. We’ll catch up on the registration. Participation and the first overview evaluation are free of charge. Please notice that
- We do not serve private customers. So please use a clearly recognizable company email address.
- we carry out the registration process manually – i.e. by humans. So it may take a while for the registration to be completed.
- “If there is a fire” you can reach us via our contact channels.
- Scrum Masters or Agile Coaches receive particularly favorable conditions for team surveys and detailed evaluations.

Purpose and content of the survey

With the surveys we record your personal opinion about your Scrum Team.
Select the first survey you want to edit from the tabs above.

We have divided the Scrum Guide 2020 requirements into 5 surveys with 22 to 50 questions. This means you can take part every now and then or complete the entire survey in one go.

Start of the survey

For each questionnaire, please enter your email address and select the school grading system for your country.

Once started please be aware, that you could loose data, if you leave this website before finishing a questionnaire.

Items

Each item consists of a statement from the Scrum Guide. We have also added in bold what this statement means specifically.

Some statements are informative, which is why no evaluation option is provided.

Evaluation

You simply rate according to the school grades (The best grades are in the selection list at the top. Did you select the right country?)

If you cannot rate the item, click “unknown”.

Comment (optional)

You can use the “Comment” column to explain your answer. This can be helpful for your Scrum Master.

In fact, the comments are the most valuable information within the Restrospective.

Send

At the end of the questionnaire, press “Submit”.
You will receive confirmation that your answers have been transferred.

Except for the comment fields, all fields are mandatory.
You may receive a message that some fields are not yet filled out. Just scroll up. The corresponding fields are marked. When all fields are filled in, press “Submit” again

Part I - Scrum Framework & Events & Roles & Artifacts (english)

Please enter your email
What is your prefered Grading system (school marks)?	DEATCH

What to do

Evaluate each statements from the Scrum Guide in relation to your team. For each item, ask yourself:
- Do my teammates agree with the statements in the Scrum Guide 2020?
- What grade do I give my team on this requirement?

If you want, you can write comments to explain your rating. Complete your evaluation form with 'Submit'.

Questionaire

id	Scrum Guide Aussagen	Note	Kommentar (optional)
1	The Scrum Guide contains the definition of Scrum The content of the Scrum Guide is known and accepted within the team.
2	Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum The purposes of the elements are known and accepted within the team.
3	Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless We use Scrum in the team according to the rules in the Scrum Guide
4	We follow the growing use of Scrum within an ever-growing complex world
5	We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots Our company uses Scrum where it makes sense.
7	As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses Such tactics for using within the Scrum framework vary widely and are described elsewhere The tools we use in the Scrum Team support us to a large extent.
217
8	Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems
9	In a nutshell, Scrum requires a Scrum Master to foster an environment where: . A Product Owner orders the work for a complex problem into a Product Backlog .The Scrum Team turns a selection of the work into an Increment of value during a Sprint .The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint . Repeat With us in the team...
10	Scrum is simple Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value
11	The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory This is well known in the company.
12	Scrum is built upon by the collective intelligence of the people using it
13	Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions That's exactly what I experience in my daily work.
14	Various processes, techniques and methods can be employed within the framework Our tools and development processes are seamlessly connected to Scrum.
15	Scrum wraps around existing practices or renders them unnecessary
16	Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made This is encouraged by our management.
17	Scrum is founded on empiricism and lean thinking
18	Empiricism asserts that knowledge comes from experience and making decisions based on what is observed Our decisions are based on practical knowledge - not on guesswork or theoretical assumptions.
19	Lean thinking reduces waste and focuses on the essentials We know the seven types of waste and avoid waste continuously and consistently.
20	Scrum employs an iterative, incremental approach to optimize predictability and to control risk We can keep our promises to each other and to stakeholders. We recognize risks at an early stage.
24	Transparency The emergent process and work must be visible to those performing the work as well as those receiving the work We have sufficient transparency on all aspects that are necessary for our work.
25	With Scrum, important decisions are based on the perceived state of its three formal artifacts Our decisions are based on the status of items in Increments, Sprint Backlog and Product Backlog.
26	Artifacts that have low transparency can lead to decisions that diminish value and increase risk Our product backlog, sprint backlog and our increments are very clear and understandable.
27	Transparency enables inspection Inspection without transparency is misleading and wasteful
28	Inspection We check - at least in the Dailys, Sprint Review and Sprint Retro - where we deviate from the agreed target. We can openly address and name problems and discuss possible solutions.
29	The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems We check that our product backlog, sprint backlog and our increments are in the planned state. We can address and name problems openly and solve them quickly together.
31	Inspection enables adaptation Inspection without adaptation is considered pointless
32	Scrum events are designed to provoke change Our team members as well as our stakeholders and our management welcome the changes we are striving for.
33	Adaptation: If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted We have acceptance criteria for quality. We not only correct the results of our work but also - if necessary - the process that led to the unacceptable result.
34	The adjustment must be made as soon as possible to minimize further deviation We usually correct deviations immediately. Where we are dependent on third parties, we quickly seek dialogue in order to press ahead with rapid adjustments.
35	Adaptation becomes more difficult when the people involved are not empowered or self-managing We can make all adjustments - that affect our daily work towards increment, sprint goal and product goal - independently in the team.
37	Successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage
44	The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them When making our decisions, we think not only of the stakeholders and the product, but also of our team development of capable, independent and respected individuals.
209	The Scrum framework, as outlined herein, is immutable "Our team works within the framework set by the Scrum Guide.
210	While implementing only parts of Scrum is possible, the result is not Scrum Our Scrum includes all elements and rules of the Scrum Guide.
211	Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices We use Scrum specifically as a container for our development process.
22	Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint
23	These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation
30	To help with inspection, Scrum provides cadence in the form of its five events
101	Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts
102	These events are specifically designed to enable the transparency required Our Scrum events give us clarity about our cooperation, processes, work results and the value for the stakeholders
103	Failure to operate any events as prescribed results in lost opportunities to inspect and adapt Our Scrum Events correspond to the specifications of the Scrum Guide.
104	Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum We don't need any other big meetings - apart from the Scrum events - to achieve our project goals.
105	Optimally, all events are held at the same time and place to reduce complexity Our meetings are usually at the same time and place.
161	Scrum’s artifacts represent work or value They are designed to maximize transparency of key information Thus, everyone inspecting them has the same basis for adaptation Anyone (expert) - who looks unprepared at our product backlog, sprint backlog and the increments - can quickly orientate themselves. The essential information is clear and complete.
162	Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
163	For the Product Backlog it is the Product Goal Our team is actively committed to the Product Goal.
164	For the Sprint Backlog it is the Sprint Goal Things where we deviate from the Scrum Guide
165	For the Increment it is the Definition of Done Our team is actively committed to the Definition of Done.
166	These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders

Part II - Team & Increment & Sprint Review (english)

Please enter your email
What is your prefered Grading system (school marks)?	DEATCH

What to do

If you want, you can write comments to explain your rating. Complete your evaluation form with 'Submit'.

Questionaire

id	Scrum Guide Aussagen	Note	Kommentar (optional)
21	Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed
36	A Scrum Team is expected to adapt the moment it learns anything new through inspection We use our Scrum events to critically examine our collaboration, work processes and work results. And: Based on this knowledge, we make targeted changes in order to constantly improve.
38	The Scrum Team commits to achieving its goals and to supporting each other Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. In our team we commit ourselves to the product goal, the sprint goals and the applicable definition of done.
39	A Scrum Team's focus is on the work of the Sprint to make the best possible progress toward these goals. The In our team, we work focused on achieving the sprint goals. Our events are also clearly focused on the respective purpose.
40	The Scrum Team and its stakeholders are open about the work and the challenges In our team we change our plans when new challenges change the previous situation.
41	Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work Everyone in our team can contribute their expertise independently and freely. Everyone on the team respects the individual strengths and weaknesses of other team members. In short: We complement each other in our strengths and help each other in our weaknesses.
42	The Scrum Team members have the courage to do the right thing, to work on tough problems In our team, we face the difficult tasks and are therefore perceived from the outside as a high-performance team.
43	These values give direction to the Scrum Team with regard to their work, actions, and behavior
45	The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts We may not know all Scrum values in detail. However, we are constantly working on training commitment, focus, openness, respect and courage
46	When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust Professionalism and trust can be felt in our team. Our customers and stakeholders also know that they can rely on us.
47	The fundamental unit of Scrum is a small team of people, a Scrum Team
48	The Scrum Team consists of one Scrum Master, one Product Owner, and Developers
49	Within a Scrum Team, there are no sub-teams or hierarchies That is the case with us.
50	Scrum Team: It is a cohesive unit of professionals focused on one objective at a time, the Product Goal That is the case with us.
51	Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how Our team really has all the skills we need to 'deliver'.
213	´Scrum Teams are also self-managing, meaning they internally decide who does what, when, and how. Priorities or disruptions coming from outside our team never jeopardize the sprint goals.
52	The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people That is the case with us.
53	In general, we have found that smaller teams communicate better and are more productive
54	If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product
56	The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required They are structured and empowered by the organization to manage their own work We develop our product in such a way that we have the entire service life in mind. Error corrections in operation, service and maintenance mean a negligible effort for us
214	Scrum Teams are structured and empowered by the organization to manage their own work. Our team has received all the skills from the organization to be able to act independently.
57	Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency We work focused and continuously towards the sprint goal. The number of completed items and story points is impressive.
58	The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint In each sprint we ran one or more - from the stakeholders' point of view - valuable, useful increment.
59	Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master (Note. Responsible persons are presented in the three specific surveys.)
145	The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations
146	The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed In the sprint reviews, our stakeholders give us valuable input for the work of the next sprints.
147	During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment This is the case with our Sprint Reviews.
148	Based on this information, attendees collaborate on what to do next In our Sprint Review, we work out what needs to be done next together with the stakeholders.
149	The Product Backlog may also be adjusted to meet new opportunities This is the case in our Sprint Reviews.
150	The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation This is how we live it in our Sprint Reviews.
151	The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint For shorter Sprints, the event is usually shorter The duration of the sprint review is just right.
198	The Sprint Review should never be considered a gate to releasing value We and our stakeholders definitely do not see the Sprint Review as a gate process. We immediately incorporate value into the releases.
192	An Increment is a concrete stepping stone toward the Product Goal
193	Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together Our releases are extensively and adequately tested. Errors and bugs are therefore minimal.
194	In order to provide value, the Increment must be usable That is the case with us.
195	Multiple Increments may be created within a Sprint That is the case with us.
196	The sum of the Increments is presented at the Sprint Review thus supporting empiricism We honestly show what is. Our stakeholders can handle this honesty well.
197	However, an Increment may be delivered to stakeholders prior to the end of the Sprint This is known and is sometimes done.
199	Work cannot be considered part of an Increment unless it meets the Definition of Done That is the case with us.
200	The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product The quality is sufficient for us - but not blocking - as described in the DoD.
201	The moment a Product Backlog item meets the Definition of Done, an Increment is born That's how we live.
202	The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment This transparency helps us in our daily work and when making decisions about the 'done'. Each team member would be able to make these decisions independently.
203	If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review That's how we live.
204	Instead, it returns to the Product Backlog for future consideration That's how we live.
205	If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum That is the case with us.
206	If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product That's how we live in our team.
207	The Developers are required to conform to the Definition of Done Each of our developers adheres to the DoD.
208	If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done That's the case with us. The teams working on a product or a system have the same definition of done. For increments that can only be created with the help of other teams, we have committed ourselves to cross-team DoD.

Part III - Product Owner & Product Backlog & Sprint Planning (english)

Please enter your email
What is your prefered Grading system (school marks)?	DEATCH

What to do

If you want, you can write comments to explain your rating. Complete your evaluation form with 'Submit'.

Questionaire

id	Scrum Guide Aussagen	Note	Kommentar (optional)
66	The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team With us in the team...
67	How this is done may vary widely across organizations, Scrum Teams, and individuals
68	The Product Owner is also accountable for effective Product Backlog management, which includes:
69	Developing and explicitly communicating the Product Goal; Our product goal is known to all developers. You work towards the product goal.
70	Creating and clearly communicating Product Backlog items; According to the current status, the product backlog items are complete, clear and understandable
71	Ordering Product Backlog items; and, Our product backlog is sorted by value - usable by stakeholders
72	Ensuring that the Product Backlog is transparent, visible and understood The product backlog items are prepared clearly and understandably for the next two sprints (refined)
73	The Product Owner may do the above work or may delegate the responsibility to others
75	For Product Owners to succeed, the entire organization must respect their decisions Our product owner makes decisions in his responsibility for results, which are respected from outside the team.
76	These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review
77	The Product Owner is one person, not a committee
78	The Product Owner may represent the needs of many stakeholders in the Product Backlog
79	Those wanting to change the Product Backlog can do so by trying to convince the Product Owner Our Product Backlog is the sole responsibility of the Product Owner.
123	The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal The sprint planning is usually so well prepared by the product owner that the developers can expertly assess the items presented and estimate the amount of work involved.
126	The Product Owner proposes how the product could increase its value and utility in the current Sprint With us in the team...
121	Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint
122	This resulting plan is created by the collaborative work of the entire Scrum Team At the end of the Sprint Planning Event, all team members know the scope of work for the next Sprint.
124	The Scrum Team may also invite other people to attend Sprint Planning to provide advice
125	Sprint Planning addresses the following topics:
127	The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders With us in the team...
128	The Sprint Goal must be finalized prior to the end of Sprint Planning With us in the team...
129	Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint With us in the team...
130	The Scrum Team may refine these items during this process, which increases understanding and confidence With us in the team...
131	Selecting how much can be completed within a Sprint may be challenging
132	However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts The estimates are quite good in our team. We regularly achieve our (challenging) sprint goals
133	For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done
134	This is often done by decomposing Product Backlog items into smaller work items of one day or less Our developers...
135	No one else tells them how to turn Product Backlog items into Increments of value The developers plan completely independent
136	The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog
137	Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint For shorter Sprints, the event is usually shorter
167	The Product Backlog is an emergent, ordered list of what is needed to improve the product
168	It is the single source of work undertaken by the Scrum Team
169	Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event
170	They usually acquire this degree of transparency after refining activities
171	Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items
172	This is an ongoing activity to add details, such as a description, order, and size Attributes often vary with the domain of work
173	The Developers who will be doing the work are responsible for the sizing
174	The Product Owner may influence the Developers by helping them understand and select trade-offs
175	The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against
176	The Product Goal is in the Product Backlog
177	The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal
178	A product is a vehicle to deliver value
179	It has a clear boundary, known stakeholders, well-defined users or customers
180	A product could be a service, a physical product, or something more abstract
181	The Product Goal is the long-term objective for the Scrum Team
182	They must fulfill (or abandon) one objective before taking on the next

Part IIII - Developer & Sprint Backlog & Daily Scrum (english)

Please enter your email
What is your prefered Grading system (school marks)?	DEATCH

What to do

If you want, you can write comments to explain your rating. Complete your evaluation form with 'Submit'.

Questionaire

id	Scrum Guide Aussagen	Note	Kommentar (optional)
6	As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work We use the word “developers” in Scrum not to exclude, but to simplify If you get value from Scrum, consider yourself included (Note: Developers are not just SW developers, but anyone who is directly involved in creating an increment.)
212	We use the word “developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included. That's how we live it.
60	Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint Our developers think and act the same way.
61	The specific skills needed by the Developers are often broad and will vary with the domain of work Our scrum team has all the skills to get the job done - without delays.
215	However, the Developers are always accountable for:
62	Creating a plan for the Sprint, the Sprint Backlog; Each of our developers feels a high degree of responsibility for creating the sprint backlog.
63	Instilling quality by adhering to a Definition of Done; Our developers adhere to the definition of done. They further develop the definition of done, unravel complicated DoD. They ultimately ensure an easy, understandable quality standard.
64	Adapting their plan each day toward the Sprint Goal; and, Our developers check every day what they need to change to achieve the sprint goal. They adapt accordingly.
65	Holding each other accountable as professionals Our developers independently address your team colleagues (and third parties) to solve the problem. They discuss - without major delays - problem descriptions and solution ideas at a technical level.
138	The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work We use the Daily in a targeted manner to incorporate new insights into our work and to review ourselves with regard to the sprint goal and the planned increments.
139	The Daily Scrum is a 15-minute event for the Developers of the Scrum Team We don't exceed the time limit of the daily. That's because we stay focused and focused: on today's tasks, presenting relevant insights, and clarifying questions to remove roadblocks.
140	To reduce complexity, it is held at the same time and place every working day of the Sprint That is the case with us.
141	If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers That is the case with us.
142	The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work This creates focus and improves self-management In our dailys we are focused on the sprint goal. We always know exactly what we have to do that working day. The daily structure, the board and moderation support us to a great extent.
143	Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings That is the case with us.
144	The Daily Scrum is not the only time Developers are allowed to adjust their plan They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work That is the case with us.
183	The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how) That is the case with us
184	The Sprint Backlog is a plan by and for the Developers It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal That is the case with us.
185	Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned It should have enough detail that they can inspect their progress in the Daily Scrum In the sprint backlog (and board) we always have the necessary transparency to see where we stand in terms of goal achievement.
186	The Sprint Goal is the single objective for the Sprint That is the case with us. We give ourselves between
187	Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it That is the case with us.
188	The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives That is the case with us.
189	The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog That is the case with us.
190	As the Developers work during the Sprint, they keep the Sprint Goal in mind Every developer usually knows the sprint goal and the planned increments in the sprint.
191	If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal That is the case with us.

Umfrage V Scrum Master & Sprint Retro & Sprint

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)
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.

What’s next?

You are also welcome to work through the other questionnaires.

Your Scrum Master receives the results of the surveys. Based on these results, he recognizes where impediments lie and can develop solutions together with the other team members – for example in the next retrospective.

easyScrum – Inspect and Adapt (english)

Registration

Purpose and content of the survey

Start of the survey

Items

Evaluation

Comment (optional)

Send

Part I - Scrum Framework & Events & Roles & Artifacts (english)

What to do

Questionaire

Part II - Team & Increment & Sprint Review (english)

What to do

Questionaire

Part III - Product Owner & Product Backlog & Sprint Planning (english)

What to do

Questionaire

Part IIII - Developer & Sprint Backlog & Daily Scrum (english)

What to do

Questionaire

Umfrage V Scrum Master & Sprint Retro & Sprint

Ablauf

Fragebogen

What’s next?

Kontaktieren Sie uns:

Sente Storys

Wichtige Links