Réussir le Sprint, c’est d’abord réussir le Sprint Planning.
Le livrable du Sprint Planning est le Backlog du Sprint, qui selon le Scrum Guide1 est un ensemble de trois topiques indissociables :
– « Why » : c’est donner du sens avec un objectif de création de valeur de Sprint
– « What » : c’est le contenu fonctionnel du Sprint et ses prérequis
– « How » : c’est le plan de travail détaillé à la journée au moins
Ça vous rappelle quelque chose ?
1/ « Why? » Alors pourquoi on fait le Sprint ?
Le Product Owner, qui a récupéré l’information auprès des Stakeholders, porte la vision du produit à partir du Backlog Produit priorisé par le sens, l’utilité et le R.O.I. Ça suppose que le Backlog Produit soit bien priorisé par la valeur avant le démarrage du Sprint Planning.
Pour le Sprint à venir, c’est toute l’équipe Scrum qui collabore de manière collégiale à la définition de l’objectif de création de valeur du Sprint.
Simon Sinek, explique comment l’action est inspirée par les grands leaders : « People don’t buy what you do; they buy why you do it »2 « Les gens n’achètent pas ce que vous faites ; mais pourquoi vous le faites ». Savoir pourquoi on fait les choses, c’est ce qu’il y a de plus compliqué.
L’objectif de Sprint qui doit être finalisé avant la fin du Sprint Planning, doit donner du sens.
L’équipe doit y investir du temps avant de remplir le Sprint Backlog.
2/ « What? » Quelle sera la réalisation de notre mêlée ?
Pour le savoir, le Product Owner parle avec la Scrum Team et déroule les tickets du Backlog Produit ordonnancés par priorité – déterminée soit par la valeur, soit par un impératif calendaire ou technique. L’équipe en fait une sélection cohérente avec sa capacité à faire et prend un engagement pour le Sprint.
Le Scrum Guide indique « The Scrum Team may refine these items during this process » ; soyons précis : si « may » implique une possibilité, ce verbe a aussi le sens de pouvoir, et ça change tout. La Scrum Team, parce qu’elle en a le pouvoir peut, si elle le veut, raffiner les tickets pendant le Sprint Planning. Vous le faites, vous ?
En tant que Scrum Master, si comme nous pendant la cérémonie vous rappelez à l’équipe qu’elle a le pouvoir et la possibilité de raffiner les tickets, vous la responsabilisez et augmentez son niveau de compréhension et de confiance.
Le Scrum Guide énonce que la sélection réalisée pendant le Sprint peut être une activité challengeante.
Pour être confiante dans son engagement, l’équipe a besoin d’avoir connaissance ;
– de ses réalisations passées : rappelez en début de cérémonie le nombre de points réalisés et la vélocité du Sprint précédent. La vélocité s’entend comme le facteur multiplicateur d’accélération entre deux Sprints qui mesure la progression des connaissances fonctionnelles, technologiques et du savoir travailler ensemble ou dit d’une autre manière, la capacité de l’équipe à se mêler,
– de la capacité à faire pour le Sprint au regard de la vélocité,
– de son alignement sur une Definition of Done écrit le Scrum Guide. Les agents conVergens observent que plus une équipe est mature dans l’agilité, plus elle augmente de façon progressive son niveau d’exigence à l’entrée du système, c’est-à-dire sa Definition of Ready.
Beaucoup de Definition of Ready sont nécessaires avant de commencer à remplir le Sprint, vous le comprenez. Travailler en amont vos prérequis vous assure la fiabilité de votre « What » avant d’attaquer le plan.
3/ « How? » C’est quoi le plan ? On commence par quoi en premier ?
C’est facile de s’emmêler les pieds dans le tapis si on n’a pas un bon plan. Chez conVergens, « on adore qu’un plan se déroule sans accrocs », alors voilà comment le travail sera réalisé.
Le Scrum Guide utilise l’adjectif « necessary » dans la phrase suivante « the Developers plan the work necessary to create an Increment that meets the Definition of Done » ; « les développeurs planifient le travail nécessaire pour développer un incrément (de produit logiciel) qui corresponde à la Definition of Done » ; parce que nécessaire prend le sens d’inévitable et de prioritaire, il y a des étapes à définir. Il s’agit donc bien d’un plan de travail à coconstruire pour créer un incrément qui corresponde à la Definition of Done.
Pour se faire, les développeurs découpent les tickets du Backlog Produit en petites tâches d’une journée de travail ou moins. Selon le Scrum Guide, la durée du Sprint Planning est « timeboxée » à un maximum de huit heures pour un Sprint d’un mois. Plus le Sprint est court, moins il y a d’éléments à l’intérieur et de temps nécessaire pour en débattre. La manière de s’organiser, selon Le Scrum Guide, est à l’entière discrétion des développeurs (c’est-à-dire selon leur jugement exclusif). Ils sont donc libres et seuls responsables. Notez-bien que ce « How » est la dernière opportunité de l’équipe Scrum pour revoir la nature de son engagement.
conVergens vous partage le retour d’expérience suivant : en fonction du besoin et du contexte, seule une équipe Scrum qui sait déjà détailler le plan d’une itération de deux semaines pourrait s’essayer à faire un plan détaillé sur trois semaines ou plus.
Nous venons de voir les trois livrables indivisibles qui constituent le Sprint Backlog. C’est l’association du « Why », du « What » et du « How » qui crée l’unité du Sprint Backlog.
Chez conVergens nous savons que l’essence de Scrum est là, dans la capacité à faire un, à se mêler, y compris dans les processus et les livrables.
Caroline Saigne et John Pombo Bilquez
Sources
1Scrum Guide = chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
2Simon Sinek = https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action
© 2022 Copyrights by con√ergens.io