Le nouveau backlog du nouveau sprint
Source : The New, New Sprint Backlog (Scrum.org)
Date : 16/08/2011
Traducteur : Fabrice Aimetti
Date : 16/08/2011
Traduction :
Le Guide 2011 de Scrum, publié ce mois-ci par Ken Schwaber et Jeff Sutherland, apporte quelques audacieux changements concernant la définition et la structure d'un Backlog de Sprint. David Starr, Professional Scrum Trainer, explique ces changements avec l'aide de Ryan Cromwell, Professional Scrum Trainer :
Le Guide 2011 de Scrum apporte quelques audacieux changements concernant la définition et la structure d'un Backlog de Sprint. La clarification sur le Backlog du Sprint est attendue depuis longtemps, et ces changements devraient aider ceux qui avaient du mal avec ce concept.
Le Guide 2011 de Scrum stipule que :
Le Backlog du Sprint est l'ensemble des éléments du Backlog Produit (PBI) sélectionnés pour le Sprint plus une stratégie pour livrer l'incrément du produit et réaliser l'Objectif du Sprint. Le Backlog du Sprint est une prévision faite par l’Équipe de Développement sur les fonctionnalités qui feront partie du prochain Incrément et sur le travail nécessaire pour fournir ces fonctionnalités.
C'est un écart important par rapport à la compréhension que l'on avait d'un Backlog de Sprint, et cela ouvre de nouvelles possibilités pour ceux qui pratiquent Scrum. Cette approche moins prescriptive permet aux Équipes Scrum d'expérimenter plus de choses au sein du framework Scrum et de trouver le modèle de planification adéquat qui fonctionne pour eux. Cela met définitivement l’Équipe Scrum en position de gérer leur propre processus et permet à Scrum lui-même de s'adapter aux progrès technologiques et aux nouvelles pratiques.
Sommaire
C'était quoi le Backlog de Sprint d'ailleurs ?
Au cours de la dernière année, j'ai plusieurs fois demandé à des personnes qui connaissaient bien Scrum (mêmes à des experts qui publient des articles) de jeter un coup d’œil au schéma suivant, qui montre la décomposition des éléments d"un Backlog Produit en éléments d'un Backlog de Sprint. Ce simple modèle est un moyen classique d'envisager le travail dans un Sprint.
J'ai alors demandé à ces personnes de dessiner un cercle autour du Backlog du Sprint.
"Que voulez-vous dire ?" ont-elles demandé.
"Dessinez juste un cercle autour du Backlog du Sprint" ai-je demandé.
Après une pause inévitable, la personne trace un cercle sur le papier et me le remet après avoir choisi ce qu'elle croit être la "bonne" définition d'un Backlog de Sprint. Les différentes réponses peuvent être celles indiqués ci-dessous.
|
|
|
|
| A |
B |
C |
| Réponse la moins fréquente |
Réponse la plus fréquente |
Réponse choisie par Ken Schwaber |
Cette confusion évidente autour de la définition d'un Backlog de Sprint a des implications importantes. J'ai même parlé avec un Scrum Trainer très compétent qui a choisi la réponse B et a inventé un nouveau terme pour les PBI sélectionnés pour le Sprint.
Bien sûr, en appliquant la définition du Guide 2011 de Scrum, nous pouvons voir que C est le bon choix et que la stratégie pour réussir ce Sprint est représentée par les éléments du Backlog de Sprint, les tâches elles-mêmes. Autrement dit, les tâches constituent la stratégie.
Cette technique est la façon traditionnelle dont les Équipes de Développement totalisent le reste à faire et suivent l'état d'avancement jusqu'à ce que tout soit fini, mais prescrire cette seule façon de le faire est trop restrictif.
Problèmes combinés
Compte tenu de la disparité des réponses, quelque chose a manifestement besoin d'être fait pour garantir une compréhension commune du Backlog de Sprint. Il y avait d'autres discussions sur le sujet qui avaient également un impact au moment où le nouveau Guide Scrum est sorti.
Travail trop simple
Lors de Réunions de Planification de Sprint, de nombreuses Équipes Scrum se sont retrouvées face à un bogue ou tout autre élément du Backlog Produit
de petite taille à inclure dans un Sprint.
L'exemple le plus simple, c'est un titre qui change sur une page ou un formulaire. C'est sans doute l'un des plus simples changements possibles pour lequel on pourrait demander une implémentation à l'Équipe de Développement. La question inévitable posée par un membre de l’Équipe de Développement qui accepte cet élément du Backlog Produit dans le Sprint c'est : "Avons-nous vraiment besoin de faire une tâche (élément du Backlog de Sprint) pour cela ?"
Jusqu'à présent, la réponse était généralement : "Oui". Des éléments du Backlog de Sprint étaient obligatoires pour chaque élément du Backlog Produit. Cela signifie que les équipes pouvaient souvent se retrouver avec un petit élément du Backlog Produit et un seul élément correspondant dans le Backlog de Sprint parce que "c'est comme ça qu'on fait". C'était typiquement pour satisfaire un quelconque outil de suivi électronique ou un Scrum Master trop contraignant, mais l'effort de créer et de gérer cet élément du Sprint Backlog était néanmoins un gaspillage. Dans cette situation trop fréquente, Scrum contraint la solution, inhibant ainsi l'auto-organisation de l’Équipe Scrum.
Dans la définition du Backlog de Sprint qui est faite dans le Guide 2011 de Scrum, il est implicite que les équipes peuvent faire ce qui est le plus pertinent dans des situations comme celles-ci. Il n'y a pas de "c'est comme ça qu'on doit faire" au moment où l'on crée la stratégie de livraison des éléments du Backlog Produit sélectionnés pour le Sprint.
Nouvelles façons de Définir le Fini
Pour rendre encore plus compliquée la question "Qu'est-ce qu'un Backlog de Sprint ?", beaucoup d'équipe ont expérimenté avec succès de nouvelles et passionnantes façons de représenter le "Fini" dans un Sprint.
Une technique a émergé dans les Équipes de Développement utilisant ATDD (Développement piloté par les tests d'acceptation), une technique dans laquelle toutes les exigences sont représentées par des tests automatisés qui doivent passer avec succès pour être considérées comme terminées. Pour les équipes utilisant ATDD, une Définition valable du Fini des éléments du Backlog de Sprint pourrait tout simplement être que tous les tests associés créés lors du Sprint doivent passer ? Cette approche gagne en popularité proportionnellement à la maturité des outils, connaissances et expériences en ATDD et BDD (Développement piloté par le comportement).
Dans certaines équipes qui réfléchissent un peu moins, la Définition de Fini pour un Sprint est considérée comme la fin de toutes les tâches, ou éléments du Backlog de Sprint. Cette approche à la lettre de la définition du fini détourne l'attention de l'Objectif du Sprint, dont la livraison est la vraie Définition du Fini pour un sprint. "Peut-être", conjecturent certaines équipes "que la seule mesure réelle dont nous avons besoin c'est l'atteinte de l'Objectif du Sprint lui-même".
Conclusion
Le Guide 2011 de Scrum autorise explicitement les Équipes de Développement à sélectionner des éléments du Backlog Produit pour un Sprint et à créer une stratégie pour les livrer qui peut être propre à l’Équipe de Développement. Cette autonomie permet de prendre des décisions inventives et intelligentes qui ont du sens pour l’Équipe de Développement dans le cadre de la planification et l'atteinte de l'Objectif du Sprint. La stratégie elle-même pourrait prendre la forme d'un rapport d'exécution de tests automatisés, la mesure de l'atteinte de l'Objectif du Sprint, ou toute autre façon nouvelle de considérer le travail qui n'a même pas encore été découvert.
Le Guide 2011 de Scrum offre des opportunités passionnantes pour les Équipes Scrum de trouver de nouveaux moyens encore plus efficaces de travailler. Avec les changements apportés à la définition du Backlog de Sprint, les équipes peuvent trouver Scrum plus approprié pour le traitement des éléments de travail les plus simples, ou ils peuvent trouver une application parfaite pour des pratiques d'ingénierie nouvelles et émergentes.
En tout cas, cette nouvelle façon de voir le Backlog de Sprint offre des opportunités pour Scrum lui même de s'adapter et de grandir avec les besoins des équipes et des organisations.
