Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/fredericbarthelet/blog-theodo-article-demo


https://github.com/fredericbarthelet/blog-theodo-article-demo

Last synced: 4 months ago
JSON representation

Awesome Lists containing this project

README 

          
# How to impress your stakeholders with an outstanding demonstration



Each ceremony is a good oportunity to show off the most recent development of the product. The review is the time to make each stakeholder catch up with the latest improvements of their investment.



## What is a demonstration?



A demonstration is a privileged time shared between the scrum team and the stakeholders. It shall last no longer than 15 minutes.



It allows the stakeholders to:

* acknowledge the success of the past sprint.

* introduce the focal point of the developments to be undertaken during the next sprint. 



It is the perfect introduction to a ceremony's review.



## Prepare your demonstration



A good demonstration is a prepared demonstration.



#### What you absolutely want to avoid during your demonstration:

* A glitch

* An internet outage or a malfunctionning server: it will delay your review, and consequently will shift your ceremony's end

* Off-handed, uninterested, distracted stakeholders



In order to avoid previously mentionned situations, the following steps will maximize your chances of succes.



#### Key elements:

* **Your stakeholders**, especially your sponsor.

* **Your application running**. Don't do it on local environment (potentially not stable) or production (you can't control production data and don't want to interfere with it).

* **No source of distraction**. You need your client's focus, they don't need their computer.

* **A large screen** or a projector to display your demonstration onto.

* **To create tickets**. A member of the team should create tickets following stakeholders' comments.



#### Preparation of your demonstration



You need to:



* **know what to show:** everything developped since last demo with the stakeholders.

* **prepare your computer:** opened application and notification disabled.

* **have realistic data:** load needed data the day before.

* **rehearse:** to avoid glitches and to run it smoothly.



## Run your demonstration



### Who should present?



Anyone confident with the presented features. Ideally, a developper because he knows the application best.



--- A changer d'endroit

Alternatively, your sponsor can run the demonstration. You will ensure his full attention.



On AssuranceVie.com, we suffered from a distracted sponsor during one of our review. It led to a change of sprint goal during the sprint after the sponsor realized we were not in line with his idea of the product's priority.

Our action was to **let the sponsor run a prepared demonstration scenario** during the next review, ensuring his full attention for the rest of the review.



* When you need to fill in fake data to demonstrate your feature, **use stakeholders related fake data**. For exemple, if you need to add a new customer, act as if your new customer was your sponsor. Saying his name out loud will catch his attention.

----



### How to present ?



* The **guide line of your demonstration** is the features you identified during your preparation. 



* **Emphasize the added value of your work:** insist on the weak points the product had before the developments, and how beneficial your team is for your client's product.



* **Endorse the role of the final user of the product, act accordingly.** The persons that will use your product may not have your skills. They will feel outsided if they can't reproduce your exact gestures.



1. Do not modify the url by hand (changing an id or any other parameter).

2. Do not use your url's history. Show how to get to your demonstration from the application starting point.

3. Do not use form auto-fillers.



* **Describe what you do as you do it**. You need to present both visually and orally to maximize your sponsor's attention. **Quoi décrire en démonstration?**



* **Stay focus on your presentation.** Do not quit the demonstration. Don't excessively move your mouse or click everywhere. 



* **Increase the value of the MEP** (if any was done during the sprint) at the end of your demonstration, concluding that all features shown during the demonstration are **now in production**. The value you added is already available to your client's final user.

** GIF It's available today !**



### How to conclude?



* **Ask your sponsors if they have questions/remarks**

* **Switch back to trello to start the review**



## FAQ



#### The current development is mainly technical, I have nothing to show to my sponsor. How should I run my demonstration?



You need visual indicators to cast light on what's not visible in your application.

On InDx, a SG project, we were opening a REST API dedicated to other SG applications during 6 sprints. |We used different supports to demonstrate our work:|

* We used Postman to simulate application calls to the API and show the received answer.

* We use flowcharts with green/red indicators showing the progress of technical requirements.

* We built diagrams showing the API workflow, emphazing which part of the workflow was not developed before the sprint.