6min read

The Project Manager’s Guide to a Perfect Demo

If you’re here just for quick tips on how to do a perfect demo—click on the link and go straight to our cheat sheet section;)

When have you attended or heard about a good Sprint review? I’m not talking about any review meeting after which all the feedback you get is “it was ok”. Sprint Demo is one of the Scrum events where the whole team makes a show. Unfortunately, most of them don’t find it super interesting, to say the least. Developers usually focus on the product’s functionality and whether it works as expected. Product owners or clients won’t attend a boring demo session that doesn’t make them care about the project’s progress.

Sounds familiar? At Polidea we believe that understanding how important the Review meeting is and how to make it more interesting for your team is key. With simple, small adjustments your team can feel more appreciated and have way more fun working.

What is a Scrum Review?

First, let me shortly describe what the Scrum Review (aka demo) is. Below you can find the Scrum workflow overview with the “Sprint Review” meeting highlighted.

Scrum workflow overview Source

So here’s the deal—according to Scrum the goal of each iteration is to produce a working increment of the product which can be demonstrated to stakeholders and be potentially releasable. It seems obvious, but some have a different approach; they say that during the first 5 Sprints a product is still in a very low stage of the development and it doesn’t support any necessary functionality. That’s wrong. Even after the first Sprint, Scrum team is able to demonstrate a potentially releasable version. It doesn’t matter that it will not include any functionality—the build is running and can be installed on clients’ device. Teams tend to forget about this, wasting time on the CI configuration. One of the key elements of the Scrum Sprint is the end of the Sprint demonstration (also known as the Sprint Review Meeting). In this article, I will call it ‘demo’.

Why do we need a demo?

Why are so many agile teams so hesitant to do demos? Why are demos so lifeless? Sometimes a demo becomes so boring that the Scrum Team decides to skip it all together. Other times, a team doesn’t have the skills to report their work to the Product Owner, as they don’t know how to “speak business”. But most often however, they simply don’t know how to perform a good demo.

In most cases a team simply doesn’t understand the reason or the background of why a demo is so important. At Polidea, the Sprint Demo is invaluable for keeping stakeholders up to date with the progress of the product development. It’s up to the stakeholders to decide when the product campaign should start and when it should be released to the market.

Everything is done to ensure the biggest profit with the developed product. Demo also allows them to give feedback and discuss with the Product Owner and the Scrum team any possible changes to the Product Backlog which would help to maximize value.

The goal of such discussions is to align the scope of the next sprint and the contents of the next sprint backlog. They will often result in stories being added further down the product backlog too.

Having regular demo meetings helps us build relationships and trust with our clients. It is also a perfect moment for a team to update each other on the current progress of a project.

Working on the demo presentation

Tips and guidelines for the perfect demo

Let’s start with a format of the sprint demo. The demo takes place at the end of the sprint and is attended by the whole Scrum team, including Product Owner and Scrum Master, as well as relevant stakeholders, management and developers from other teams. Here at Polidea we follow an “Open Demos” policy that allows any employee to attend demonstrations performed by other teams (of course after an “OK” from the PM who informed the client about it beforehand).

When an organization has more than one Scrum team working on the same project the teams should consider running their demo together. It’s not just easier to arrange it this way – it also keeps the teams abreast of what the others are working on and helps to avoid the duplication of work. However, at a certain size of the team this may not work and having only representatives from Scrum teams attending each other’s demos may be more practical.

Each Scrum team takes turns while giving an update on their progress against their sprint goal and demo the working iteration of the product that resulted from their sprint. Generally, I like to do this with the user stories organized into a logical narrative structure which shows all the items done during the Sprint. Teams usually train before the Sprint demo, to be sure all agreed and implemented items will be presented. Sometimes the team will nominate one member to present the demo and sometimes the task will be shared among the individuals demonstrating the particular parts of their work. Again, it’s a personal preference, but from my experience demos work really well when one person runs the main talk and the other one runs the demo.

Demo meeting

Does your team know how to prepare for a demo? First of all, the Sprint Demo should not take up too much of the team’s time. I’ve heard about a lot of situations where a team said they don’t do a demo, because they don’t have time. Ensuring that the Sprint Review meeting is informal—with questions, feedback and discussion welcome—allows for prep time to be kept to a minimum. Easy as that.

Your time shouldn’t be spent putting long slide decks together—the focus should be on the work and your demo should only include stories that meet the team’s definition of ‘done’.

Generally, a day before the end of the Sprint try to align a short demo run-through with your team during which they agree on the order of the stories—and make notes on anything that needs to be set up in order to make the demo flow smooth. This meeting should be kept short (15 mins is enough).

Finally, it’s important to say that a demo is not a sign-off meeting. The Product Owner should have already seen the stories and be happy with them. Participating in a discussion and offering feedback is definitely encouraged—but while this might result in some new backlog items, it shouldn’t change whether existing items are considered to be done.

Scrum workflow overview

A perfect demo: cheat sheet

  1. Focus on the acceptance criteria. We’ve defined what ‘done’ means for the story, so focus your demo on proving that you’re actually done. Taking a separate meeting to explore with your team the definition of Done (DoD) and definition of Ready (DoR) might be very useful. A common understanding of what ‘done’ means is key to deliver what a Product Owner expects.
  2. Start with the demo in mind. Don’t wait to think about the demo until you’re done with the story. You might be able to write tests that double as demo scripts. And it’s best to plan your demo for a story while it’s fresh in your mind before you move to the next one.
  3. Prepare. Create an interesting scenario to prove that you’ve satisfied the core acceptance criteria. Create all the necessary test data. Make sure the environment for your demo will work as expected. During the demo everyone will notice how well you are prepared. It’s also good to plan the Q&A.
  4. Practice. Run through your demo script at least once. It will help the team to reduce stress and prepare for any surprises. Let your team ask questions to the main speaker. Believe it or not but this will help during the actual demo. Any points which will be noticed during the demo suppose to be discussed by the Scrum team during the retrospective. This is the right time to inspect and adapt to any changes.
  5. Tell a story. Focus your demo on a realistic user solving a real problem. The goal is not just to show that the software works, but to show that it’s valuable.
  6. Keep it short. If you work on your stories one at a time and get them accepted when they’re ready, you don’t need to exhaustively cover all your acceptance criteria in your demo. Instead, focus your demo on what’s interesting and what’s valuable about each feature.

The Sprint Demo should be the most exciting part of the Scrum process. This is when the team gets to show everyone all the value they’re delivering, which is why it’s worth investing a little time to do well. You may find that previously not interested stakeholders start showing up just for the show.

All teams are different and face different problems. This article is for those who faced similar issues as I have. Let me know what’s your experience with running the Scrum and Sprint Demos!


DariuszProject Manager


Sign in and expect sharp insights, recommendations, ebooks and fascinating project stories delivered to your inbox

The controller of the personal data that you are about to provide in the above form will be Polidea sp. z o.o. with its registered office in Warsaw at ul. Przeskok 2, 00-032 Warsaw, KRS number: 0000330954, tel.: 0048 795 536 436, email: (“Polidea”). We will process your personal data based on our legitimate interest and/or your consent. Providing your personal data is not obligatory, but necessary for Polidea to respond to you in relation to your question and/or request. If you gave us consent to call you on the telephone, you may revoke the consent at any time by contacting Polidea via telephone or email. You can find detailed information about the processing of your personal data in relation to the above contact form, including your rights relating to the processing, HERE.

Data controller:

The controller of your personal data is Polidea sp. z o.o. with its registered office in Warsaw at ul. Przeskok 2, 00-032 Warsaw, KRS number: 0000330954, tel.: [0048795536436], email: [] (“Polidea”)

Purpose and legal bases for processing:


Used abbreviations:

GDPR – Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016
on the protection of natural persons with regard to the processing of personal data and on the free movement
of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)

ARES – Polish Act on Rendering Electronic Services dated 18 July 2002

TL – Polish Telecommunications Law dated 16 July 2004

1)        sending to the given email address a newsletter including information on Polidea’s new projects, products, services, organised events and/or general insights from the mobile app business world |art. 6.1 a) GDPR, art. 10.2 ARES and art. 172.1 TL (upon your consent)

Personal data:name, email address

2)       statistical, analytical and reporting purposes |art. 6. 1 f) GDPR (based on legitimate interests pursued by Polidea, consisting in analysing the way our services are used and adjusting them to our clients’ needs, as well as developing new services)

Personal data:name, email address

Withdrawal of consent:

You may withdraw your consent to process your personal data at any time.

Withdrawal of the consent is possible solely in the scope of processing performed based on the consent. Polidea is authorised to process your personal data after you withdraw your consent if it has another legal basis for the processing, for the purposes covered by that legal basis.

Categories of recipients:

Your personal data may be shared with:

1)       authorised employees and/or contractors of Polidea

2)       persons or entities providing particular services to Polidea (accounting, legal, IT, marketing and advertising services) – in the scope required for those persons or entities to provide those services to Polidea


Retention period:

1)       For the purpose of sending newsletter to the given email address – for as long as the relevant consent is not withdrawn

2)       For statistical, analytical and reporting purposes – for as long as the relevant consent is not withdrawn

Your rights:


Used abbreviation:

GDPR – Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016
on the protection of natural persons with regard to the processing of personal data and on the free movement
of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)

According to GDPR, you have the following rights relating to the processing of your personal data, exercised by contacting Polidea via [e-mail, phone].

1)       to access to your personal data (art. 15 GDPR) by requesting sharing and/or sending a copy of all your personal data processed by Polidea

2)       to request rectification of inaccurate personal data
(art. 16 GDPR) by indicating the data requiring rectification

3)       to request erasure of your persona data (art. 17 GDPR); Polidea has the rights to refuse erasing the personal data in specific circumstances provided by law

4)       to request restriction of processing of your personal data (art. 18 GDPR) by indicating the data which should be restricted

5)       to move your personal data (art. 20 GDPR) by requesting preparation and transfer by Polidea of the personal data that you provided to Polidea to you or another controller in a structured, commonly used machine-readable format

6)       to object to processing your personal data conducted based on art. 6.1 e) or f) GDPR, on grounds relating to your particular situation (art. 21 GDPR)

7)       to lodge a complaint with a supervisory authority,
in particular in the EU member state of your habitual residence, place of work or place of the alleged infringement if you consider that the processing
of personal data relating to you infringes the GDPR
(art. 77.1 GDPR)

No obligation to provide data:

Providing your personal data is not obligatory, but necessary for Polidea to provide you the newsletter service

Refusal to provide the above data will result in inability to receive the newsletter service.


In the process of providing the newsletter service, we make decisions in an automated way, including profiling, based on the data you provide.


“Profiling” means automated processing of personal data consisting of the use of your personal data to evaluate certain personal aspects relating to you, in particular to analyze or predict aspects concerning your personal preferences and interests.


The automated decisions are taken based on the analysis of clicked and viewed content. They affect the targeting of specific newsletter content to selected users registered to receive the newsletter service, based on the anticipated interests of the recipient.