(English follows)

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

—

 

 

A Sprint Review Is Not A Demo

Do you do Sprint Reviews, demos or a mix of the two? Are you doing it wrong? Not knowing can be costly. For example, do feel that you have to sacrifice features to prepare for your demos or Sprint Reviews? Sadly, many Agile teams do. Let’s see how we can avoid that by understanding the difference between those two events.

A common error when applying Scrum is to treat the Sprint Review as a traditional demo. Understanding this as problematic is important for many reasons, efficiency being the main one.

If you are using Scrum methodologies, you absolutely need Sprint Reviews while, depending on your context, you may or may not need demos. This being said, we get to our burning question: What is the difference between a Sprint Review and a demo? The answer starts by comparing the reasoning behind each event. The Sprint Review enables the Scrum Team to show the advancements of the sprint, both from the user’s perspective and from the developer’s perspective. The demo, on the other hand, has more formality and presents a selection of working capabilities. The Sprint Review focuses only on the sprint content while a demo can, and often does, demonstrate capabilities across many features logically grouped (ex: end to end use case or all features related to user management).

Yet, both meetings share a common trait, which might be the source of the confusion, as they both are opportunities for stakeholders to give their feedback and thus influence prioritization. It sounds simple and yet many, in an Agile context, are confusing both events.

Classic mistakes when approaching Sprint Reviews:

• Demanding full demos to the Dev. Team: This often results in the investment of the last 2-3 days of the sprint in preparation for the Sprint Review “demo”.
• Only showing the user-facing advancements: The Dev. Team often has technical advancements or, minimally, can also describe the user-facing advancement from their point of view. It is important for the whole Dev. Team to understand the current state of development.
• Not having Sprint Reviews or skipping Sprint Reviews: This often happens with junior Agile teams which are, either not closing clean sprints (feeling the need to keep on working), or not engaged yet in the Agile methodologies (not understanding the need or goal of the Sprint Review). Failing to do Sprint Reviews removes a critical piece of the Scrum loop. It would take an entire blog post to explain all the impacts.

Classic mistakes when approaching demos in Agile:

• Planning to demonstrate features that are not completed (not DONE): Many reasons may have contributed to create such a situation and I would recommend resolving this. Nevertheless, the result implies investing effort on the creation of demo-quality features instead of staying focused on the backlog. Not driven by production development objectives, those demo-quality features are often hacks and technological debts that will set the project backward further than before the demo.
• Using the demo as a surprise inspection: In Agile/Scrum, visibility on the advancements is systematically done at each Sprint Review.
• Using the demo to force completion, integration and testing of features: In Agile, this is handled by the Development Team’s Definition of Done and the execution of clean sprints (i.e. closing stories and not generating technical debts).

All that being said, demos have a reason to be and they must coexist with the Sprint Reviews. Let’s look at some tips and tricks to make your next Sprint Review and demo relevant, effective and efficient.

Sprint Review

• Preparation for the Sprint Review should not take more than 15 minutes per Dev. Team member.
• Demonstrate the same way you have tested during the sprint.

Focus on the goals of the sprint review

• Show advancements to the users & stakeholders. This is normally done by the PO.
• Share development advancements done by the different Dev. Team members.
• Get feedback.

Demo

Aim for zero development effort cost. Invest this effort in the development of new features instead. You can drastically lower the cost of demos by doing the following:

• Only demo what is DONE (i.e. The results of previous sprints. Not ongoing, incomplete or future developments).
• Demos should be prepared and given by the PO, a domain expert or super-user in a production-like environment.

Still, if the Dev. Team is needed for a demo, do the following:

• Confirm how many demos the stakeholders needs.
• Create demo stories in the backlog.
• Calculate the cost of a demo by estimating the demo stories in points.
• Continue to manage the whole backlog by business value. This means the PO may have to choose between a feature story and a demo story. Depending on the situation, one will have more value than the other. With all this information, the PO will then be able to maximize the value by prioritizing the backlog.

 

Phillipe Cantin