iteration, the team comes together and shows off their work. They demonstrate what they've completed and show it to other teams, their ProductOwner, and sometimes end users. This is a chan"> Iteration Demo
GROWS logo

Iteration Demo

At the end of each iteration, the team comes together and shows off their work. They demonstrate what they’ve completed and show it to other teams, their ProductOwner, and sometimes end users. This is a chance to talk about what they’ve done and get real feedback on their work.

Pain Points

  • There’s no clear finish line for an iteration. They begin to run together and the project begins to resemble a death march project
  • There’s no set time for the team to show their work to the product developer or other members of the company
  • Teams feel unappreciated because no-one else understands their work or what they’re doing
  • Teams think other teams aren’t doing anything, or anything useful


The iteration demo can be a real morale booster. It’s a chance to come together not to work, but to celebrate! Look at what we’ve done. See how it works. What did you do?

Without a meeting to review the work, the reviews either don’t happen, or they become messy ad hoc events where some work is seen and appreciated and other work is missed. Work slips under the radar and either isn’t used (as others don’t realize it’s be done) or isn’t appreciated.

All people need their work to be meaningful and appreciated. The demo provides an opportunity to show others your work and see it appreciated.


✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment


  1. Collect a list of the work accepted by the team into the current iteration
  2. Schedule time with the entire team
  3. If you’re at a small company, invite everyone
  4. If you’re at a larger company, invite lots of people, especially to key demos
  5. Explain to the team ahead of time what the demo will be and who will be attending


  1. Have each developer or tester show the story they worked on and explain what the story means, what it’s for, and so on
  2. Then show the work
  3. If the work is “plumbing work” (an API, lower level code, etc) then provide a test that uses the new work and show the test runner

Evaluate Feedback

  1. Ask people who attended the demo what they thought about the demo and the team. Did this provide a better insight into what the team is doing?
  2. Does this change what the product developer asks for in the next iteration?
  3. Does it change what stories the team accepts?

What Does it Look like?

The ScrumMaster schedules 30 minutes to show off the last iteration’s work. They walk around and talk to a few of the sales team, several members of customer support, and a few executives. They tell them a bit about what will be in the demo and encourage them to attend. Hint at food bribes that might be provided.

On the day of demo, everyone gathers around the projector in the middle of the work area. The TeamLead kicks off the meeting with an overview of what the team accomplished. Perhaps they highlight what percentage of the accepted work was completed. Then they hand the meeting over to the first team member. They bring up the story on the big screen, showing both the story, the completion criteria, and any notes. Then they switch over to the live software, walking the team through the code for the first time. A few questions about work flow and perhaps usability come from customer service. Sales wants to know which release this will be in.

This continues until each story has been reviewed and the work shown. The meeting is wrapped up with a round of applause and everyone grabs one more cookie before returning to their work. A few people linger to discuss how this or that new feature might used by a certain customer persona.

Warning Signs

  • The same person talks at the demo every time and shows everyone else’s work
  • No one shows up for the demos except the person who’s running the demo
  • The product developer skips the demo
  • No-one outside of your team attends the demo
  • The team demos from slides or video instead of showing their work live
  • A team consistently has nothing to show

Growth Path

Try attending other teams demos and see how they’re presenting their work. Try to make the demo a fun event… provide donuts or other treats.

If another team is consuming your work (or you theirs), make a point of attending each other’s demos and see what’s coming down the pipeline.

Use key demos as a communication tool. Reach out to users and invite them to attend, in person or virtually, for sneak peak into what might be in the next version of the product

How To Fail Spectacularly

  • Trying to do a demo from slides/Powerpoint… does your code not work?
  • Trying to “pass” on doing a demo week after week after week. Is your team not doing any meaningful work? If not, perhaps you should be rejecting more stories during the planning meeting.
  • Schedule demos at 6 pm on a Friday, then insisting everyone attend. Start late, and to be consistent, end even later. Then wonder why no one likes demos.

←Prev (Deep Product Discovery)(Two Sets of Eyes) Next→

Follow @growsmethod on Twitter, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method™. We will not use your email for any other purpose.