Une revue de sprint n’est pas une démo

Faites-vous des revues de sprint, démo ou un mix des deux? Le faites-vous de la mauvaise façon? Ne pas le savoir peut être coûteux. Par exemple: sentez-vous que vous devez sacrifier des fonctionnalités pour préparer vos revues de sprint ou vos démos? Malheureusement, plusieurs équipes Agile le font. Voici comment éviter ce piège en comprenant la différence entre ces deux événements.

Une erreur commune dans l’application de Scrum est de voir la revue de sprint en tant que démo traditionnelle. Comprendre cette problématique est important pour plusieurs raisons, et l’efficience en est la principale.

Si vous utilisez des méthodologies Scrum, vous devez absolument avoir des revues de sprint alors que, selon votre contexte, le besoin de faire des démos peut être optionnel. Ceci dit, nous passons à la grande question: quelle est la différence entre une revue de sprint et une démo? La réponse commence par la comparaison entre la raison d’être des deux événements. La revue de sprint permet à l’équipe Scrum de montrer l’avancement du sprint, et ce, des points de vue de l’utilisateur et du développeur. La démo, de son côté, a un peu plus de décorum et présente une sélection de fonctionnalités complétées. La revue de sprint se concentre seulement sur le contenu du sprint, alors qu’une démo va fréquemment démontrer des capacités touchant plusieurs fonctionnalités et groupées de façon logique (ex: cas d’utilisation complet ou toutes les fonctionnalités liées à la gestion de l’utilisateur).

Toutefois, les deux événements partagent un trait commun pouvant être à la source de la confusion, car tous deux sont une opportunité pour les parties prenantes de donner leurs commentaires, et donc d’influencer la priorisation. Ceci semble simple, mais plusieurs, dans un contexte Agile, confondent les deux événements.

Erreurs classiques face aux revues de sprint:

• Exiger des démos complètes à l’équipe de développement: ceci résulte souvent dans l’investissement des 2-3 dernières journées du sprint dans la préparation pour la “démo” de la revue de sprint.
• Ne montrer que les avancements du côté utilisateur: L’équipe de développement a souvent des avancements techniques ou, minimalement, est en mesure de faire la description les avancements utilisateurs via leur perspective. Il est important pour toute l’équipe de développement de bien comprendre l’état courant du développement.
• Ne pas faire ou ne faire qu’en partie les revues de sprint: Ceci est fréquemment le cas chez les équipes Agile juniors qui, soit ne complètent pas leur sprint (sentant le besoin de continuer de travailler) ou encore, ne sont pas encore engagées dans les méthodologies Agile (ne comprenant pas le besoin ou le but de la revue de sprint). Ne pas faire de revue de sprint retire une partie critique de la boucle Scrum. Un billet de blogue complet pourrait être écrit pour en expliquer tous les impacts.

Erreurs classiques face aux démos Agile:

• Planifier de démontrer des fonctionnalités incomplètes (non-terminées): Plusieurs raisons peuvent avoir contribué à créer une telle situation et je recommanderais de résoudre le tout. Peu importe la raison, le résultat implique un investissement d’effort pour la création de fonctionnalités de qualité “démo” plutôt que de se concentrer sur le backlog. Non dirigées par des objectifs de développement de production, les fonctionnalités de type “démo” sont souvent des hacks et des dettes technologiques qui retarderont encore plus le projet une fois la démo complétée.
• Utiliser les démos en tant qu’inspection surprise: En mode Agile/Scrum, la visibilité sur les avancements est donnée de façon systématique à chaque revue de sprint.
• Utiliser la démo pour forcer l’achèvement, l’intégration et le test des fonctionnalités: En mode Agile, ceci est fait via la définition de « terminé » de l’équipe de développement et l’exécution de bons sprints (c.à.d. histoires complétées et sans génération de dette technique).

Malgré tout, les démos ont raison d’être et elles doivent donc co-exister avec les revues de sprint. Voici maintenant des trucs et astuces pouvant aider vos prochaines revues de sprint et démo à être pertinentes, efficaces et efficientes.

Revue de sprint

• La préparation pour la revue de sprint ne devrait pas prendre plus de 15 minutes par membre de l’équipe de développement;
• Démontrez de la même façon que vous avez testé pendant le sprint;
• Restez concentrés sur les buts de la revue de sprint;

• Montrez les avancements aux utilisateurs et parties prenantes. Ceci est normalement fait par le PO;
• Partagez les avancements en développement effectués par les différents membres de l’équipe de développement;
• Recueillez les commentaires.

Démo

Visez zéro coûts de développement pour les démos. Investissez plutôt cet effort dans le développement de nouvelles fonctionnalités. Vous pouvez drastiquement réduire le coût de vos démos en appliquant les points suivants:

• Ne montrer que ce qui est terminé (c.à.d. les résultats du sprint précédent. Pas de développement en cours, incomplet ou futur);
• Les démos devraient être préparées et données par le PO, expert de domaine ou super-utilisateur, et ce, dans un environnement de qualité production.

Toutefois, si l’équipe de développement est nécessaire pour une démo, appliquez les points suivants:

• Confirmez avec les parties prenantes le nombre de démos nécessaires;
• Créez des histoires de démo dans le backlog;
• Calculez le coût des démo en estimant ces histoires en points;
• Continuez de faire la gestion du backlog par valeur d’affaires. Ceci veut dire que le PO devra possiblement faire des choix entre une histoire de démo et une histoire de fonctionnalité. Selon la situation, l’une aura plus de valeur que l’autre. Avec cette information, le PO pourra ainsi maximiser la valeur en priorisant le backlog.

Phillipe Cantin