Sprint Demo Assessment

Every question on the Sprint Demo Assessment maps to a specific habit that separates teams who use the demo to validate real value with stakeholders from teams who use it to narrate a status report. Below is a breakdown of each scored question: what it measures, why it matters, and concrete steps to improve if your team scored low.

Score Interpretation

How to read your total maturity score (0 to 100).

1-20: Struggling. The demo is not functioning as a feedback event. Stakeholders are largely absent, little working product is shown, and nothing from the session changes what the team builds next.

21-40: Developing. The team is holding demos, but they lean on slides and narration. The audience is thin, questions are few, and feedback rarely reaches the backlog.

41-60: Norming. The demo runs consistently and shows real work. Stakeholders attend, but the session is still more presentation than conversation and value is assumed rather than confirmed.

61-80: Performing. The demo is working. Working software is shown, the right people are in the room, and feedback is captured. Explicit value validation is usually the next gain.

81-100: Thriving. The demo is a genuine inspect and adapt point. Stakeholders engage, the team shows live product, feedback lands in the backlog, and the team leaves knowing whether the work delivered value.

Team Size

What is the number of team members including the Scrum Master, Product Owner, and Tech Lead?

Why it matters: A team of six to nine can produce a coherent increment and show it in a single sitting. Smaller teams often finish too little to justify pulling stakeholders together every sprint. Larger teams tend to demo disconnected slices from several parallel workstreams, which leaves the audience without a clear picture of what was actually delivered.

To improve your score: If you are consistently under six, consider running a joint demo with a closely related team so stakeholders see a complete slice of value rather than a fragment. If you are at thirteen or more, you probably have multiple products inside one team. Split by product or value stream and give each its own demo and its own audience.

Attendance

How many people were in attendance?

Why it matters: The demo is the one event where the audience should be larger than the team. Attendance is a direct proxy for stakeholder interest, and a thin room usually means the invite list is too narrow, the work has not felt relevant to the business, or the demo has a reputation for running long and showing little.

To improve your score: Build a standing invite list that includes business stakeholders, the people who support the product in production, and the adjacent teams that depend on you. Send a short agenda in advance naming exactly what will be shown, and finish on time every time. Attendance follows usefulness, so the fastest way to fill the room is to make the half hour worth spending.

Team Role Coverage

Who was present?

Why it matters: The Product Owner is the person who accepts or rejects the increment, so their absence turns the demo into a showcase with no decision attached to it. The Scrum Master keeps the session moving and captures feedback so nothing is lost. The Tech Lead answers the hard technical questions stakeholders raise in the moment. Having the whole team present also spreads ownership of the increment beyond whoever happened to build it.

To improve your score: Treat the Product Owner as required and move the session rather than running without them. Have the Scrum Master confirm attendance the day before. Let each team member present the piece they built instead of routing everything through one presenter, which builds presentation skill across the team and gives stakeholders direct access to the people doing the work.

Facilitation Ownership

Who facilitated?

Why it matters: Someone has to own the flow of the session. Opening it, framing the sprint goal, moving between presenters, protecting the timebox, and capturing feedback are all real work. When the Scrum Master carries it, presenters can concentrate on their demo and the Product Owner can concentrate on reading stakeholder reaction. When nobody owns it, demos start late, wander, and end without a summary of what was decided.

To improve your score: Make the Scrum Master the standing facilitator. Have them open with the sprint goal and what the team committed to, introduce each presenter by name and item, keep a running feedback list visible on screen, and close by stating what was accepted, what was not, and what happens next. Publish that closing summary to the invite list the same day.

Cameras On

Were cameras on?

Why it matters: Stakeholder reaction is the output of this event. Facial expressions tell you whether what you built landed, and you lose that signal entirely when the room is dark. Demos held with cameras off also make it easy for stakeholders to half attend, which means the feedback you needed in the session arrives days later as a change request instead.

To improve your score: Ask presenters and stakeholders to turn cameras on and explain the reason, which is that the team needs to read the reaction and not only hear the words. Pause deliberately after each item and look at faces before moving on. In-person demos satisfy this criterion automatically.

Duration

How long did the meeting last?

Why it matters: Thirty to sixty minutes is enough to show a sprint of work, take real questions, and reach a decision. Under thirty minutes usually means the team is showing very little or skipping the discussion that makes the event worth holding. Beyond an hour, stakeholders start dropping off and the last presenters demo to an empty room.

To improve your score: Timebox each item to five minutes with a hard stop and rehearse against the clock. Cut the setup narration and start from a working screen. Move deep technical discussion to a follow-up with the two people who actually care about it. If the increment will not fit inside an hour, you are probably demoing tasks rather than outcomes.

Feedback Captured in the Backlog

Were items added to the team’s backlog based on feedback?

Why it matters: Feedback that is not written down did not happen. When stakeholders raise a change and nothing enters the backlog, they learn that the demo is theater and they stop investing attention in it. Captured feedback is what closes the loop and turns the session into a real inspect and adapt point instead of a presentation with applause at the end.

To improve your score: Have the Scrum Master log feedback live in the backlog during the session, on the shared screen, so stakeholders watch their input land. Restate each item back to the person who raised it to confirm you captured the intent rather than the words. Review those items in the next refinement session and tell stakeholders what was prioritized and what was not.

Presenter Preparation

Did the presenters seem prepared?

Why it matters: Unprepared demos burn stakeholder goodwill quickly. Hunting for environments, logging in, and explaining why something is not working consumes the time you needed for feedback and signals that the team does not value the audience. Preparation is also what allows a presenter to frame the business problem before showing a screen, which is the difference between a demo and a tour of a user interface.

To improve your score: Run a fifteen minute dry run the day before with real data loaded and the environment already open. Assign each presenter a specific item and have them write one sentence naming the user problem it solves. Keep a short recording as a fallback for anything that depends on a fragile environment. Decide in advance what you will not show.

Stakeholder Audience

Other than the team, who was present?

Why it matters: The mix of people in the room determines the quality of the feedback you get. Business stakeholders tell you whether the work solves the problem they brought you. Leadership sees where the investment is going and why it takes the time it does. Other teams catch dependencies and integration issues before they turn into incidents. A demo attended only by the team is a rehearsal.

To improve your score: Map who consumes or depends on your product and invite them by name rather than through a group alias. Add the teams immediately upstream and downstream of you. If business stakeholders are not showing up, ask them directly what would make the session worth their time and change the demo accordingly. Lead with the item that matters most to whoever you are trying to bring back.

Working Software Shown

Were in-progress diagrams, visuals, or working software presented?

Why it matters: The point of a demo is evidence. Working software, real screens, and concrete visuals give stakeholders something specific to react to, which produces feedback you can act on. Spoken descriptions of finished work produce agreement without shared understanding, and that gap reappears later as rework nobody planned for.

To improve your score: Show the real thing in a real environment even when it is partial and rough. For work with no user interface, show the API response, the dashboard, the log output, or the architecture diagram that changed. If an item cannot be shown in any visible form, that is worth questioning before you call it done.

Slides Versus Live Product

Was a slide presentation primarily used for presenting content?

Why it matters: Slides hide the state of the product. A deck describes work that is nearly finished in exactly the same way it describes work that is shipped and running, and stakeholders have no way to tell the two apart. Teams that lean on slides usually do so because the increment is not actually demonstrable, and that is the real problem worth surfacing.

To improve your score: Limit slides to one opening frame carrying the sprint goal and the agenda, then move to the product for everything else. If the team cannot demo without a deck, examine your definition of done and how work is being sliced. Vertical slices that cross the full stack are demonstrable at the end of a sprint. Horizontal layers are not.

Value Validation

Did the team explicitly ask stakeholders whether the demoed work delivers real business value, and receive a clear response?

Why it matters: Silence at the end of a demo is not approval, it is politeness. Without an explicit ask, teams read the absence of objections as confirmation that the work matters and keep building in the same direction for another sprint. Asking directly is what converts the demo from a showcase into a validation point, and a clear no is worth far more than a vague yes.

To improve your score: After each item, ask a direct question. Does this solve the problem you brought us, and would you use it as it stands today? Name the person you are asking instead of addressing the room, because rooms do not answer. Push for specifics when the response is soft. Record the answer next to the item in the backlog, and when the answer is no, treat it as a signal to change direction now rather than at the end of the quarter.