Voir la source de Scrum : 19 antipatterns de planification d'un sprint

[[Category: Portail Planification]]
[[Category: Portail Product Owner]]
Auteur : Stefan Wolpers<br/>
Source : [https://age-of-product.com/scrum-sprint-planning-anti-patterns/ Scrum: 19 Sprint Planning Anti-Patterns]<br/>
Date : 01/05/2017<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 24/12/2018<br/>
----
Traduction :<br/>
== TL;DR: 19 antipatterns de planification d'un sprint ==
La planification du sprint en Scrum est une cérémonie simple. Investissez dès le départ dans l'affinage du backlog produit et vous maintiendrez cette cérémonie productive. Évitez les 19 antipatterns suivants de planification de sprint vous aidera également.<br/>
<br/>
[[Fichier:Scrum-19-sprint-planning-anti-patterns-hands-on-agile-1650 fr.png|border|1000px|link=]]<br/>

==Le but d'une planification de sprint ==
La planification du sprint en Scrum a pour but d’aligner l’équipe de développement et le Product Owner. Les deux doivent s'entendre sur l'incrément produit déployable lors du prochain sprint. L’idée est que les prévisions de l’équipe de développement reflètent l’objectif du sprint du Product Owner. En outre, l'équipe doit élaborer un plan sur la manière de transformer ses prévisions.<br/>
<br/>
Si par le passé l'équipe Scrum a utilisé avec succès l'affinage du backlog produit, la première partie de la planification du sprint sera rapide. L’équipe de développement et le Product Owner ajusteront la portée du sprint à venir en tenant compte de la capacité disponible. Peut-être que quelqu'un de l'équipe de développement ne sera pas disponible au prochain sprint. Donc, un ou deux éléments devront retourner dans le backlog du produit.<br/>
<br/>
Ou un nouvel élément fonctionnel intéressant est apparu du jour au lendemain et le Product Owner souhaitera que cet élément fasse partie du prochain backlog de sprint. Par conséquent, une autre user story retournera dans le backlog produit. Une bonne équipe pourra gérer cela en cinq à dix minutes avant de passer à la deuxième partie de la planification du sprint. Au cours de la planification du sprint II, l’équipe décompose le premier ensemble d’éléments de backlog du sprint en tâches.<br/>

== Antipatterns de la planification du sprint ==
Il existe trois catégories d'antipatterns de planification de sprint. Ils concernent l'équipe de développement, le Product Owner et l'équipe Scrum :
=== Antipatterns de planification du sprint par l'équipe de développement ===
* '''Des absents ?''' les membres de l'équipe ne déterminent pas leur disponibilité au début de la planification du sprint. (Bonne chance pour faire une prévision dans cette situation.)
* '''Capacité ?''' l'équipe de développement surestime sa capacité et prend trop d'éléments. (L’équipe de développement devrait au contraire prendre en compte tout ce qui pourrait affecter sa capacité à livrer. La liste de ces problèmes est longue : jours fériés, nouveaux membres de l’équipe, congés annuels, membres qui quittent l’équipe, membres de l’équipe en congé maladie, les coûts indirects de l'entreprise, les cérémonies Scrum et tout autre réunion, pour n'en nommer que quelques-unes.)
* '''Ignorer la dette technique :''' l’équipe de développement n’exige pas une capacité suffisante pour traiter la dette technique et les bugs lors du sprint. (En règle générale, 25% des ressources sont affectées lors de chaque sprint à corriger les bugs et à refactoriser le code source. Si le Product Owner ignore cette pratique et que l'équipe de développement accepte cette infraction, l'équipe Scrum se retrouvera dans une spirale infernale. Sa capacité future à livrer le produit diminuera.)
* '''Pas de mou :''' l'équipe de développement n'exige pas 20% de temps mou de la part du Product Owner. (Si la capacité d’une équipe est toujours surexploitée, sa performance diminuera avec le temps. C’est en particulier le cas dans une organisation dont les activités quotidiennes sont instables. En conséquence, chacun s’efforcera de s’acquitter de ses tâches. Le temps nécessaire pour soutenir les coéquipiers ou pour binômer. L’équipe ne traitera plus ponctuellement les plus petits problèmes ou les problèmes urgents. Chaque membre de l’équipe deviendra un goulot d’étranglement, ce qui pourrait sérieusement bloquer le flux au sein de l’équipe. Enfin, l’attitude "Je suis occupé" réduira l'émergence d'une compréhension partagée parmi les membres de l'équipe. Une surutilisation poussera toujours chaque membre de l’équipe à se concentrer sur sa production propre. Alors que le temps de mou permettra à l’équipe Scrum d’agir en collaboration et de se concentrer sur les résultats.)<br/>
[[Fichier:Scrum-19-Sprint-Planning-Anti-Patterns-Slack-Time-Overutilization-1650 fr.png|border|1000px|link=]]<br/>
<br/>
* '''Planification trop détaillée :''' lors de la planification du sprint II, l’équipe de développement planifie à l'avance chaque tâche du sprint à venir. (Ne soyez pas trop fin. Deux tiers des tâches c'est plus que suffisant, le reste suivra naturellement pendant le sprint. Faire trop de planification en amont pourrait engendrer du gaspillage.)
* '''Trop d'estimation :''' l'équipe de développement estime les tâches. (Cela ressemble à de la comptabilité pour moi. Ne perdez pas votre temps là-dessus.)
* '''Planification insuffisante :''' l'équipe de développement ignore la planification du sprint II. (Il est regrettable de sauter la planification du sprint II, car c’est le bon moment pour parler de la manière de diffuser les connaissances au sein de l’équipe de développement. Par exemple, l’équipe pensera à qui binômera avec qui et sur quel élément fonctionnel. La planification du sprint II est également bien adaptée pour examiner la façon de réduire la dette technique.)
* '''Des chefs d'équipe ?''' L'équipe de développement ne propose pas de plan pour transformer ses prévisions de façon collaborative. Au lieu de cela, un "chef d’équipe" affecte des tâches à chaque membre de l’équipe. (Je sais que les développeurs expérimentés n’aiment pas cette idée, mais il n’y a pas de "chef d’équipe" dans une équipe Scrum. Pour en savoir plus : [https://age-of-product.com/engineers-despise-agile/ Pourquoi les ingénieurs méprisent-ils l’Agilité]).

=== Antipatterns de planification du sprint par le Product Owner ===
* '''Pour quoi nous battons-nous ?''' le Product Owner ne peut pas fournir d'objectif pour le sprint, ou l'objectif de sprint choisi est faible. (Un objectif de sprint original répond à la question "Pour  quoi nous battons-nous ?". Il s’agit d’une négociation entre le Product Owner et l’équipe de développement. C’est quelque chose de ciblé et de mesurable, car l’objectif du sprint et les prévisions de l’équipe vont de pair. Enfin, l’objectif de sprint est un calibrage utile pour le sprint à venir.)
* '''Appeler Kanban "Scrum" :''' le backlog de sprint ressemble à un collection aléatoire d'éléments et aucun objectif de sprint n’est défini. (Si c’est la façon naturelle de terminer votre planification de sprint I, vous avez probablement atteint le dernier degré d'utilité de Scrum en tant que cadre de développement de produit. En fonction de la maturité de votre produit, Kanban pourra s’avérer une meilleure solution. Sinon, ce caractère aléatoire pourrait témoigner d'un Product Owner faible qui écoute trop les parties prenantes au lieu de prioriser correctement le backlog produit.)
* '''Travail inachevé :''' les user stories inachevées et les autres tâches du dernier sprint sont transférées dans le nouveau sprint sans discussion. (Il peut y avoir de bonnes raisons à cela, par exemple, la valeur de la user story n’a pas changé. Cependant, cela ne devrait pas être un automatisme, souvenez-vous de [https://en.wikipedia.org/wiki/Sunk_cost#Loss_aversion_and_the_sunk_cost_fallacy l'erreur de jugement sur les coûts irrécupérables].)
* '''Changements de dernière minute :''' le Product Owner essaie d’intégrer certaines user stories de dernière minute qui ne satisfont pas à la définition du prêt. (Le Product Owner a principalement pour prérogative d’apporter ce type de modifications afin de s’assurer que l’équipe de développement ne travaille que sur les user stories les plus intéressantes à un moment donné. Cependant, si l'équipe Scrum pratique régulièrement des sessions d'affinage du backlog produit, cela devrait rester une exception rare. Si cela se produit fréquemment, cela signifie que le Product Owner a besoin d'aide pour la définition des priorités et la communication avec l'équipe. Ou le Product Owner a besoin d'aide pour savoir plus souvent dire "non" aux parties prenantes.)
* '''À fond sur la production :''' le Product Owner pousse l’équipe de développement à prendre plus d'éléments qu’elle ne pourrait le faire de façon réaliste. Le Product Owner pense sans doute à d'anciennes mesures de l'équipe, telle que la vélocité, pour encourager son fantasme.

=== Antipatterns de planification du sprint par l'équipe Scrum ===
* '''Longueurs de sprint irrégulières :''' l'équipe Scrum a des cadences de sprint variables. Par exemple, les éléments ne sont pas dimensionnés pour tenir dans la durée normale du sprint. Au lieu de cela, la longueur du sprint est adaptée à la taille des éléments. (Il est assez courant d’allonger la longueur du sprint à la fin de l’année lorsque la plupart des membres de l’équipe sont en vacances. Cependant, il n’y a aucune raison de s’écarter de la cadence normale pendant le reste de l’année. Au lieu de changer la longueur du sprint,  l’équipe Scrum devrait consacrer davantage d’efforts à découper de la bonne manière les epics et les user stories.)
* '''Excès d’engagement :''' l’équipe Scrum prend régulièrement trop d'éléments et transfère simplement le travail inachevé dans le prochain sprint. (Si deux ou trois éléments s'empilent dans le sprint suivant, qu’il en soit ainsi. Si, régulièrement, 30 à 40% de la prévision initiale n’est pas livrée pendant le sprint, l’équipe Scrum a peut-être créé une sorte de "Kanban timeboxé". Peut-être est-ce le bon moment pour demander à l’équipe Scrum si essayer Kanban pourrait constituer une bonne alternative.)
* '''Etapes / Portes avec la Définition du Prêt :''' la définition du prêt est traitée de manière dogmatique, créant ainsi un processus d'approbation semblable à un processus étapes / portes. (C’est un sujet intéressant pour une discussion entre les membres de l’équipe. Par exemple, une user story intéressante devrait-elle être reportée à un autre sprint simplement parce que les conceptions de la partie cliente ne seront pas disponibles avant deux jours de travail ? Mon conseil: présentez-la à l'équipe. Si elle est d'accord avec la situation du moment et accepte la user story dans le sprint, c'est très bien. Pour en savoir plus : [https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready Les dangers d'une Définition du Prêt].)
* '''Ignorer la Définition du Prêt :''' l'équipe de développement ne rejette pas les user stories qui ne correspondent pas à la définition du prêt. (C’est l’opposé du dogme de l’application de la Définition du Prêt : les user stories qui ne sont pas prêtes et qui vont causer des perturbations inutiles pendant le sprint sont autorisées. Laisser-faire n’aide pas non plus.)
* '''Prévision imposée :''' la prévision de sprint n'est pas une décision d'équipe. Ou ce n'est pas sans influence de l'extérieur. (On a plusieurs antipatterns possibles. Par exemple, un Product Owner assertif domine l’équipe de développement en définissant l'étendue de la prévision. Ou une partie prenante mentionne la vélocité précédente de l'équipe et exige d'elle de prendre davantage de user stories. ("Nous devons remplir la capacité disponible.") Ou le "leader technique" de l'équipe de développement fait une prévision au nom de l'équipe.)
* '''Planification ignorée :''' l'équipe de développement ne participe pas collectivement à la planification du sprint. Par exemple, deux membres de l'équipe, le responsable technique et le  responsable UX, représentent l'équipe. (Si l'on parle de cette idée d'avoir un ou deux coéquipiers "responsables" dans une équipe Scrum, en fait il n'y en a pas, voir ci-dessus. Et à moins que vous n'utilisiez LeSS - sans jeu de mots - où les équipes sont représentées dans la planification générale du sprint, l’ensemble de l’équipe Scrum doit participer. C’est un effort collectif, et chaque voix doit donc être entendue.)

== Conclusion ==
La planification du sprint en Scrum est une cérémonie simple. Investissez dès le départ dans l'affinage du backlog produit et vous maintiendrez cette cérémonie productive. La plupart des antipatterns de planification de sprint mentionnés précédemment sont simples à corriger. Contenez-vous de les présenter à l'équipe.<br/>
<br/>
Quels sont selon vous les antipatterns de planification de sprint qui manquent ? S'il vous plaît, n'hésitez pas à les partager avec nous dans les commentaires.