Agile : Rendre sa review efficace

//Agile : Rendre sa review efficace

Agile : Rendre sa review efficace

La Review a pour but de présenter au client le résultat du travail réalisé au cours du Sprint. Elle vient clôturer et formaliser les travaux réalisés au cours du Sprint et précède la rétro que nous verrons dans un prochain article. Elle réunit l’ensemble de la Dev Team, les utilisateurs clés du livrable, le PO et le Scrumaster afin de récupérer un maximum de feedbacks.

Comment se déroule cette Review et comment la rendre pertinente ? Nous vous donnons quelques pistes pour une réunion efficace.

Déroulement de la Sprint Review

Comme expliqué dans l’introduction la présentation de la Review est indispensable. Cette réunion « commerciale » permet d’exposer le travail réalisé par la Dev Team durant le Sprint, de montrer les améliorations effectuées sur le produit au client. Le Product Owner et le Scrum Master détaillent le travail réalisé par l’équipe.

Présentation des nouvelles fonctionnalités du produit

Chaque User Story est présentée par un des membres de l’équipe (soit par la personne qui l’a prise en charge ou par un autre membre qui jouera le rôle de présentateur). La présentation orale est souvent appuyée par un PowerPoint, avec une mise en avant du contexte, des critères d’amélioration, et de ce que cela apporte au client. Le Powerpoint doit rester simple, concis et efficace pour ne pas détourner l’attention que porte l’interlocuteur à l’auditoire.

Chaque membre est invité à faire la démonstration de l’une ou l’autre fonctionnalité présentée. Il est important qu’au fur-et-à-mesure des Sprints, tous les membres de l’équipe participent à cet exercice oral.

Enfin, un feeback client est essentiel pour entendre les points positifs et négatifs de la Review mais également pour connaître les différents axes que l’équipe doit améliorer lors de la prochaine Review.

Autres points d’attention

Une fois toutes les nouveautés présentées, l’équipe annonce quelques indicateurs révélateurs du Sprint passé : les Impediments rencontrés, les absences et nouveaux arrivants dans l’équipe, mais aussi le Burndown chart (graphique qui représente les user stories réalisées lors du Sprint) : qui est un bon indicateur de vélocité du sprint, pour expliquer et justifier les craintes de glissements de plannings éventuels aux clients.

Une fois la réunion terminée, la présentation est envoyée au client et à l’équipe de développement.

Quelques conseils pour une bonne Review

Le Scrum Master et le Product Owner doivent timeboxer chaque présentation. Ces présentations sont limitées selon leur complexité de 5 à 15 min en comptant les retours clients. Le but ici, est de montrer la fonction au client et de ne pas perdre l’attention de l’auditoire. Il convient de donner une réunion complète et d’éviter tout superflu.

Il faut porter une attention particulière au support de présentation. Il doit être uniformément rédigé, doit respecter la charte établie au préalable, doit être vulgarisé au maximum (notamment pour les aspects techniques) et doit être suffisamment renseigné. Chaque Slide doit être complétée et doit comprendre à la fois des indications textuelles mais également visuelles (capture d’écran, schéma, pictogramme, etc.).

En cas de problème au cours d’une des démonstrations, le Scrum Master peut intervenir et soutenir le présentateur, afin de garder une présentation fluide. N’oublions pas que c’est premièrement un travail d’équipe.

Conclusion

La Sprint Review peut être plus qu’une simple réunion et peut devenir un véritable échange avec les clients. La démonstration doit se faire de manière pédagogique tout en étant transparente sur les difficultés rencontrées. En effet, la Sprint Review est l’occasion d’échanger de manière totalement transparente avec le client (l’un des 3 piliers du Scrum). Plus le client se sent impliqué, meilleur est son ressenti à la fin du Sprint. C’est le moment pour récolter les feedbacks clients et repérer les forces et faiblesses du Sprint, en vue de débattre lors de la Rétro, prochaine étape de notre série Agile.

 

2018-12-20T09:59:35+01:00