Scrum Organizational Self-Assessment

This self-assessment measures how effectively Scrum is working in your organization across six key areas: leadership, team dynamics, product ownership, process, and outcomes.

Be honest—there are no right or wrong answers. Your results will highlight strengths and growth opportunities.

Results are emailed to you. Check the box if you’d like an Advisor to follow up about your results.

Scrum Organizational Self-Assessment

Updates

First Name

Last Name

What role(s) best describe(s) what you do on a regular basis?

Scrum Master

Developer

Manager/Org leader

Agile Coach

Product Owner

Other

Please tell us what you do

I would like to set up a time to discuss the results

Purpose & Outcomes

The team’s work clearly links to measurable business outcomes.

Team members and stakeholders can explain how their work contributes to customer satisfaction, revenue, or efficiency. Success is measured in terms of outcomes, not just output or activity.

Always

Usually

Sometimes

Rarely

Never

All stakeholders understand the Product Goal.

There is a clear, shared understanding of the long-term goal guiding the Scrum Team’s efforts. Stakeholders know why the goal exists, what success looks like, and how progress is measured.

Always

Usually

Sometimes

Rarely

Never

All stakeholders and Scrum Team members understand the Product Goal.

There is a clear, shared understanding of the long-term goal guiding the Scrum Team’s efforts. Stakeholders and Scrum Team members know why the goal exists, what success looks like, and how progress is measured.

Always

Usually

Sometimes

Rarely

Never

A Sprint Goal exists every Sprint and guides Daily Scrum discussions.

Progress toward the Sprint Goal is discussed in the Daily Scrum by the developers of the Scrum team. When decisions arise—such as whether to add new work or change scope—people refer to the Sprint Goal to stay aligned on what matters. Work unrelated to the goal is rare or explicitly postponed.

Always

Usually

Sometimes

Rarely

Never

Empirical Process Control

All key artifacts (Product Backlog, Sprint Backlog, Increment) are transparent and up to date.
Everyone can see what work is in-flight, what’s planned next, and what’s already finished. Product Backlogs are refined and clearly communicate the Product Owners intent to the stakeholders and the rest of the Scrum Team. Product Increments are considered "Done" when they meet a shared standard of quality and completeness.

Always

Usually

Sometimes

Rarely

Never

All Scrum Events inspect and adapt.
The Developers of the Scrum team hold a Daily Scrum each day to measure progress toward the Sprint Goal. The entire Scrum Team holds Sprint Reviews and Retrospectives each Sprint. These events stick to their respective tkmeboxes and they lead to meaningful discussion, adaptations, and transparent follow-up actions.

Always

Usually

Sometimes

Rarely

Never

Data and feedback drive meaningful adjustments to Product Backlog and process.
Decisions are based on evidence such as (but not limited to) usage, views, velocity, throughput, cycle time, or customer feedback. Measures and metrics are used to learn, not to punish or micromanage.

Always

Usually

Sometimes

Rarely

Never

Experiments are used to improve outcomes.
The team and leadership regularly test new ideas or approaches, observe results, and adapt. There’s psychological safety to try things that might fail. There are safety nets put into place to catch mistakes before they're catastrophic.

Always

Usually

Sometimes

Rarely

Never

Role Clarity & Accountability

The Product Owner is accountable for maximizing value and ordering the backlog.
The Product Owner is a single person who actively manages the Product Backlog to reflect business needs and stakeholder feedback in order to maximize the value created by the Scrum Team. They are respected and empowered to fulfill this accountability. Other roles don’t bypass or override this accountability.

Always

Usually

Sometimes

Rarely

Never

Scrum Teams self-manage how work gets done within the Sprint.
Internally, the Scrum Team decides who does what, when and how. Developers plan their own work, give estimates, and adapt their plan as needed in order to achieve the Sprint Goal and deliver a usable Increment of value. The Scrum team is trusted to do this and doesn't require external management to do so.

Always

Usually

Sometimes

Rarely

Never

The Scrum Master serves the Scrum Team, the Product Owner, and the rest of the organization.
The Scrum Master isn’t just scheduling meetings. They actively coach and cause the removal of impediments beyond the team’s ability to do it themselves. They help improve team dynamics, teach/coach Scrum principles, and work with the organization to to improve business agility.

Always

Usually

Sometimes

Rarely

Never

Management supports & respects the Scrum accountabilities and empowers those who fulfill them.

The Product Owner determines what to build and prioritizes the backlog, while the Developers decide how to create usable increments of value within each Sprint that achieve the Sprint Goal. The Scrum Master ensures that Scrum is properly understood and applied, and helps facilitate the removal of any impediments that may hinder progress.

Always

Usually

Sometimes

Rarely

Never

Flow & Delivery

Sprint Goals are realistic, respected, and met.
The team plans achievable Sprint Goals and delivers a Done and usable Increment that satisfies the Sprint Goal. If not, root causes are inspected and adjustments are made.

Always

Usually

Sometimes

Rarely

Never

The team regularly delivers a working increment that meets the Sprint Goal with minimal carry over
When unfinished work is carried over, it’s rare and only after achieving both the Sprint Goal and a usable product increment.
If either is missed, the team inspects the causes and adapts its planning or execution.

Always

Usually

Sometimes

Rarely

Never

Technical debt is visible, prioritized, and addressed regularly.
The team discusses technical debt* openly, tracks it, and allocates time to reduce it rather than hiding it behind deadlines.

*Technical debt: the extra effort required later because something was done faster or cheaper today.

Always

Usually

Sometimes

Rarely

Never

A releasable and usable Increment of value is available at least once per Sprint.
All work as part of the increment meets the Definition of Done. The product or solution could be given to customers at any time without any extra work aside from the act of releasing it.

Always

Usually

Sometimes

Rarely

Never

Culture & Collaboration

The team feels psychologically safe to surface issues and give feedback.
People can admit mistakes or raise concerns without fear. Leaders respond constructively, focusing on solutions rather than blame.

Always

Usually

Sometimes

Rarely

Never

Stakeholders attend Sprint Reviews and contribute feedback, shaping the direction of the product or solution.
Business representatives engage with the team at Sprint Reviews, ask hard questions, and influence future backlog items. Their feedback helps to reduce costs of building the wrong thing and helps find ways to make the solutions delivered more valuable than without their regular feedback.

Always

Usually

Sometimes

Rarely

Never

Conflicts are resolved constructively and promptly.
Disagreements are discussed openly and resolved quickly, not ignored or left to fester.

Always

Usually

Sometimes

Rarely

Never

Continuous improvement ideas from Sprint Retrospectives are implemented.
Action items from Retrospectives are visible and tracked. The team follows through, and improvements become part of how they work.

Always

Usually

Sometimes

Rarely

Never

Organizational Support

Leaders support focus by working with the Product Owner to manage change.
When new priorities emerge, managers coordinate with the Product Owner so the team stays focused on the current Sprint Goal and adjustments happen through transparent backlog updates.

Always

Usually

Sometimes

Rarely

Never

Dependencies between teams are actively managed and reduced.
Cross-team dependencies are identified early and minimized through design choices, clear interfaces, or re-structuring teams.

Always

Usually

Sometimes

Rarely

Never

Career paths and evaluations reward learning, adaptability, and team outcomes.
Performance reviews and incentives focus on team success, collaboration, and improvement, not individual heroics or output metrics.

Always

Usually

Sometimes

Rarely

Never

Leaders model empirical decision-making.
They expose plans and results, gather input across the organization, and adapt strategies to improve outcomes.

Always

Usually

Sometimes

Rarely

Never