La démonstration lors de la revue de sprint

La revue de sprint commence par une démonstration du produit partiel réalisé lors du sprint.

Quelques commentaires suite aux démos de Wilos et Icescrum auxquelles j'ai participé hier en tant que directeur de produit :

  • le public n'apprécie pas d'attendre plusieurs minutes avant le début réel de la démo. L'installation et le raccordement au vidéo-projecteur doivent être rapides ou préparés avant
  • il convient de préciser le contexte de l'installation (serveur, en local ?) et décrire les données de test éventuellement utilisées pour la démo
  • il n'est pas utile de faire de présentation sous forme de diaporama avant la démo
  • la démonstration ne s'adresse pas uniquement au directeur de produit. L'objectif est d'être compris également par le public non averti (intervenants extérieurs qui ont parfois une connaissance limitée du projet)
  • quand ça plante ou que ça ne se passe pas comme prévu, il vaut mieux le dire explicitement. Le but est la transparence, pas l'attente d'un jugement
  • la démonstration est l'aboutissement d'un travail collectif, c'est une bonne chose que cela se voit, en faisant participer plusieurs personnes de l'équipe
  • quand on tombe sur un bug pas la peine de répéter "ça marchait il y a 10 minutes je ne comprends pas"
  • ça ne sert à rien d'essayer de justifier un incident dans le déroulement de la démo en évoquant des problèmes de gestion de configuration, ça fera l'objet de la rétrospective
  • lorsqu'on saisit des valeurs, il vaut mieux prendre des valeurs parlantes plutôt que valeur1, valeur2...
  • il ne faut pas montrer des fonctionnalités qui ne marchent qu'à moitié
  • il ne faut pas aller trop vite dans la démonstration d'une fonctionnalité avec des clics trop rapides. Toute l'assemblée doit bien comprendre ce qui est montré
  • les fonctionnalités doivent être présentées une à une en se référant au backlog : l'objectif de la démonstration est de définir les éléments du backlog qui sont achevés