Craig Larman in Agile & Iterative Development, A managers guide describes it thus:

Sprint Review: At the end of each iteration, there is a review meeting. (maximum of four hours) hosted by the Scrum Master.  The team, Product Owner, and other stakeholders attend. There is a demo of the product.  Goals include informing stakeholders of the system functions, design, strengths, weaknesses, effort of the team, and future trouble spots.

Feedback and brainstorming on future directions is encouraged, but no commitments are made during the meeting.  Later at the next Sprint Planning meeting, stakeholders and the team make commitments.

“Power Point” presentations are forbidden.  Preparation emphasis is on showing the product.

What is a Demo anyway?  What should we Demo?

Demo of a Balinese fire dance, Bali, Indonesia: Martin Harris

A demo has to be fully working software.  Although the team considers it ready for production and has fully tested it, its acceptable that the demo environment is scaled down in terms of moving parts and data sets.  Often there are manual test stages that follow user acceptance and such, but during this meeting we expect to get business agreement and sign-off so the environment has to be good enough to inspire confidence in the product.

Get the product owner to drive the software.  No cheating The product owner will get a better feel for it if they drive.  I have seen situations were very good software refuses to behave only when the product owner takes control!  Make sure that your demo room has a spare PC just in cases someone from the team needs to login, check logs, or re-start a service etc.  Its important not to stall on something trivial or unrelated to the demo.

Record any issues or problems.  These have two outcomes.  Either they are bad enough that the product owner will not accept the stories as finished, or if trivial the product owner may sign off a story if they are fixed in the next iteration.  The ideal is obviously to sail into the next iteration with no hangover whatsoever.  Don’t let issues slow the meeting down.  The product owner should make a decision and move on.  The scrum master documents any such issues and the outcome.  Note that the teams testers are incredibly useful in a demo, often providing usability and product usage advice.

If possible everything in an iteration should be included in the software demonstration.  If you get it right it should be possible to demonstrate every story.  If the team is in the habit of producing a definition of done for all tasks and done includes things like, documented, fully tested, deployable then preparation for the demonstration should just be a matter of updating the demonstration environment.

What a demo is not?

A demo is always actual running software, never mocked aside from test or development data.  If you can get production data then all well and good.  The product owner is always present, demonstrating to the development teams has little value.  This is a key opportunity for developers and the business to come together and feel part of the same team.  The product owner is the only person who can sign off a story.  If they are unavailable postpone.

How much does a demo cost?

Very little when measured against the return.  In an ideal project the demo environment is created off the back of a successful build possibly automated.  Its not just used for the demo, but provides a place to test.  In an integration situation its often useful to have somewhere that is guaranteed to be stable.  Its possible to share the environment over several teams as long as its stable during the demo.

What are the Benefits?

The main benefit is the team is able to demonstrate that a set of stories for an iteration is finished.  The burn down is complete.  The product owner is able to report that a key section is complete.  In some projects release to production follows soon after.  You are able to see exactly where you are after updating the backlog.

This process like no other Builds Confidence.  The confidence the team has in itself and the confidence the business has in the team to deliver.  It can not be overstated how important this is.

Sometimes this is the first time that the Team members see the product working end to end, when your working on the small parts is easy to forget where your heading.  The demo brings it all together.

Team becomes more focused on delivery.  I will paint you a picture.  Its Thursday morning, the demo is tomorrow, there is still quite a bit to do before the demo.  Nobody on the team wants to be the one, who’s key piece meant something was not ready for the demo.  By the afternoon you can feel the tension as the team readies the environment and tests everything one last time.  Teams with no demo do not have such focus.  A key part of scrum is something called cadence.  Iterations are always the same length, people get used to that, and they are marked by events.  I would say Sprint Review is the full stop marking the end of a sprint.

Its very addictive to the business.  The product owner will really start to get involved when at the end of each sprint demo after demo builds more working product.  Its a very important part of forging the teams relationship with the business.

Problems you may have with demonstrations.

Problem: We find that at the end of a sprint we have nothing that can be demonstrated!
Experiment with: Longer iterations.  Find ways to make it possible to demonstrate, look for blocks, missing environment and work hard to plug the gaps.  Its vital to demo never de-prioritize this.

Problem: We have difficulty getting the product owner to attend.
Experiment with: Shorter iterations.  Less to demo should mean shorter meetings that are easier to schedule.  Always do the demo at the same time and day.  This is also easier to plan for.

Problem: The team has no time to do demonstrations, they are busy building new functionality.
Experiment with: Plan less and schedule less stories.  Its vital to know you have actually finished an iteration.  A common scenario for teams who do not demo, is one where the project is just collecting more and more partially finished stories because of one block or another.  This can even be hidden as with no demo you have not the assurance that what you build is correct.  So you only think your complete.  There will be a price to pay later in re-work during test or worse after go-live.

Problem: We tried sprint reviews but they broke down after several chaotic attempts.
Experiment with: Create a story for Demo preparation. Have it in mind that your telling a story. Lead the product owner through the stories in a logical order that builds. See links below for more on how a review should be conducted.

Conclusion

Always hold a Sprint review with a demo.  It has hidden benefits and builds confidence in the team.  Don’t underestimate its power to motivate.  Business confidence and reporting accuracy will also improve.  Greater understanding of the product and business are other side effects.  So plan to demo now and enjoy, it can be the best part of the sprint.

Further Reading

Simple Scrum Sprint Review Note the amount of time allocated to demo in this example!

Successful Sprint Reviews Excellent work on how to make them work.