# How to run a sprint review when the client is the stakeholder

> For freelance developers and small agencies who demo work to a client at the end of each sprint or milestone on Google Meet or Microsoft Teams: a 45-minute agenda, how to demo so the feedback is usable, how to sort what the client says into accepted work, changes and new requests, and what to send after. Ends with how TrackHeros records a review.

Canonical: https://trackheros.com/blog/sprint-review-with-a-client/  
Author: Sami Kanafani  
Updated: 2026-10-22

**In short:** A sprint review with a client shows working software against the plan, then sorts every reaction into accepted, a change to this work, a new request or an open question. Each becomes a decision or an action with an owner and a date, read back before the call ends. TrackHeros records reviews on Google Meet and Microsoft Teams and writes the decisions and action items from what was said.

A sprint review with a client is the meeting at the end of a sprint or milestone where you show working software and the client decides whether it does what they need. This guide is for freelance developers and small agencies whose client is the stakeholder, on Google Meet or Microsoft Teams. It covers a 45-minute agenda, how to demo so the feedback is useful, how to turn reactions into decisions and action items, and what to send afterwards.

## How is a sprint review with a client different from an internal one?

The person watching is paying, and their reaction counts as acceptance. An internal review is a team checking its own work; a client review is where work is accepted or sent back, and where new requests most often appear.

Three things follow from that. The client does not read your board, so they react to what they see on screen, not to ticket titles. Their words carry weight later: "yes, that's fine" is acceptance whether or not anyone wrote it down. And every "could it also" is a potential change to scope, said in a friendly voice at the moment you are most inclined to agree.

So the job of a client sprint review is narrow: get a clear verdict on each piece of work, and catch new requests before they become assumed.

## What is a good sprint review agenda?

Five blocks, 45 minutes for a two-week sprint. Put the list of stories you will show in the invitation, so the client knows what they are being asked to accept.

| Time      | Block                           | What comes out of it                               |
| --------- | ------------------------------- | -------------------------------------------------- |
| 0:00–0:05 | Goal restated                   | What was planned, what is being shown, what is not |
| 0:05–0:25 | Demo, story by story            | A verdict on each story                            |
| 0:25–0:35 | Feedback sorted                 | Each reaction in one of four bins (see below)      |
| 0:35–0:40 | Next sprint priorities          | The client ranks what comes next                   |
| 0:40–0:45 | Decisions and actions read back | Owner and date for each action, said aloud         |

Say what is not being shown at the start. "The PDF export slipped to next sprint; I'll show the CSV export instead" is a sentence the client should hear from you, not discover by asking.

## How do you demo so the feedback is useful?

Show the work the way the client's users will meet it, and ask for a verdict after each piece. A demo that runs straight through and ends with "any thoughts?" collects politeness, not feedback.

- **Use staging and realistic data.** Not your laptop, and not a list of records called "test 1" and "test 2". Clients judge what they see, and fake data hides real problems.
- **Narrate the user's goal, not your implementation.** "Priya runs the month-end invoices. She needs last month's unpaid ones as a file her accountant can open." Then show it.
- **Say aloud what you click and what appears.** "I'm filtering to October, unpaid only, and exporting." Anyone who listens to the recording later, or reads notes written from it, gets what was on screen as well as what was said.
- **Ask a closed question after each story.** "Does this do what you need for the month-end run?" gets a yes, a no or a specific change. "What do you think?" gets "looks great".
- **Let the client drive if you can.** If they can open staging on their own machine and try the flow while you watch, they find the thing they would actually do on Monday.
- **Have a fallback.** If staging breaks mid-demo, a short screen recording made the day before saves the meeting.

## How do you turn client feedback into decisions and actions?

Sort every reaction into one of four bins before the call ends, and write each one down in the form it belongs in.

| What the client says                              | Bin                 | What you write                                                                           |
| ------------------------------------------------- | ------------------- | ---------------------------------------------------------------------------------------- |
| "Yes, that's what we need."                       | Accepted            | Decision: CSV export accepted as demonstrated, 22 October, by Priya                      |
| "The dates should be day, month, year."           | Change to this work | Action: I will change the export date format by Friday 23 October                        |
| "Could it also email the file to our accountant?" | New request         | Request: email export to accountant, exact words, estimate to follow; not in this sprint |
| "I'm not sure about the column order."            | Open question       | Open: column order. Priya to check with the accountant by Tuesday 27 October             |

The difference between the second and third rows is the one that matters most. A change to this work makes what was agreed correct; you absorb it. A new request adds something that was never agreed; it gets an estimate and a place in a future sprint. Clients do not draw that line themselves, so you draw it, out loud: "The date format I'll fix this week. Emailing the accountant is new, so I'll send you an estimate." The [scope creep guide](/blog/scope-creep-starts-in-meetings/) has the phrases that signal the third row.

A reaction is not a decision until you have read it back. "So the CSV export is accepted, with the date format change. Is that right?" takes five seconds and turns a nod into a record. Decisions that matter for months belong in a [decision log](/blog/decision-log-for-client-projects/) as well as in the review notes.

## What should you write down during the review?

The verdicts and the requests, word for word; the rest can be summarised later.

- Each story's verdict: accepted, accepted with changes, or not accepted, with the reason.
- The name of the person who accepted. Acceptance from someone without the authority to give it is worth little.
- New requests in the client's exact words, with who asked.
- Bugs found live: where, what you did, what happened.
- Next sprint's priorities, in the order the client ranked them.

If you are both demonstrating and taking notes, write only the verdict column and the requests; [taking notes while running a video call](/blog/take-notes-while-running-a-video-call/) has the shorthand.

## What do you send after the sprint review?

A short recap the same day, in the email body, under a subject you reuse every sprint.

```text
Subject: Sprint 6 review: [Client] [project], 22 October

Accepted
- CSV export of unpaid invoices (with the date change below).
- Partial-payment matching, flagged for review.

Changes agreed
- Export dates as day/month/year. Me, by Friday 23 October.

New requests (estimates to follow, not in sprint 7 unless we swap)
- Email the export to the accountant. Priya, 22 October.

Open questions
- Column order in the export. Priya to confirm with the accountant
  by Tuesday 27 October.

Sprint 7, in your order
1. PDF export  2. Year-end freeze rules  3. Rounding fix

If I have any of this wrong, tell me by Monday.
```

Keep the accepted list exact. In a fixed-price engagement it may be what an invoice rests on; your contract decides that, so check how yours defines acceptance.

## How does TrackHeros handle a sprint review?

TrackHeros is an AI meeting notetaker that joins the review on Google Meet or Microsoft Teams as a visible participant and records it. The notes are written from the transcript, so what you say aloud reaches them and what you only showed on screen does not; that is one more reason to narrate the demo. The recording plays back inside the app on the meeting page.

The notes have a fixed shape: summary, decisions, discussion by topic, agenda, milestones with dates, and action items. Each action item carries the owner as heard and the due date as it was said ("by Friday"), resolved to a date. An owner whose name did not match anyone recorded in the meeting gets a "Not an attendee" chip, so a misheard name is checked before it reaches the client. Items can be edited, ticked done or deleted on the meeting page.

Across a project, open the client and ask "what did they say about the export over the last three reviews?" The answer comes only from that client's meetings, cited to who said it and when, and the citation plays the recording from that moment. Copy for email puts the notes on your clipboard for the recap; formal PDF minutes are on paid plans ([pricing](/pricing/)). Sending action items straight into an issue tracker is not available yet. More at [action items](/features/action-items/), [ask your meetings](/features/ask-your-meetings/) and [meeting minutes](/features/meeting-minutes/).

## Not yet available

- Push action items straight to Jira, ClickUp, and Linear — not yet available

## Frequently asked

**How long should a sprint review with a client be?**

About 45 minutes for a two-week sprint: five to restate the goal, twenty for the demo, ten to sort the feedback, five for next sprint's priorities and five to read back decisions and actions. Longer sprints can take an hour, but a review that runs past that is usually doing planning work as well.

**What should I do when a client asks for a new feature during the demo?**

Thank them, write down their exact words, and say it goes on the request list with an estimate to follow. Do not estimate it on the call and do not agree to fit it into the current sprint. Send the estimate in writing, with what it would displace.

**Who on the client's side should attend a sprint review?**

The person who accepts the work, always. Add the people who will use the feature if you can, because they find the real problems. If the person who accepts cannot come, move the review rather than accept by proxy: acceptance from someone without the authority to give it does not hold.

**Should I record sprint review demos?**

A recording settles later questions about what was shown and what was accepted, so it is worth asking at the start of the engagement. Rules on recording differ by country and by contract; ask the client, and say what the recording is for and how long you keep it.

---

TrackHeros is in early access: https://trackheros.com/#early-access