Les Fondamentaux de Scrum, ce qui n'appartient pas à la Story Utilisateur
Auteur : Boris Gloger (@borisgloger)
Source : plus disponible
Date : 04/2011
Traducteur : Fabrice Aimetti
Date : 09/05/2011
Traduction :
Lorsque nous mettons en œuvre Scrum, nous devons sans cesse répondre à la question suivante : "Que faisons-nous des tâches telles que la configuration d'un serveur ou les mises à jour d'un système d'exploitation ? Appartiennent-elles également au backlog ? Nos réponses à ces questions sont toujours les mêmes : "Non ! Seules les livrables du point de vue du client appartiennent exclusivement au backlog, les tâches internes n'ont rien à y faire."
La confusion est compréhensible car, malheureusement, il y a constamment des articles comme celui de Thomas Lieder qui justifient pourquoi les stories techniques doivent exister. D'une part, il écrit correctement : "Les stories utilisateurs doivent décrire la demande d'un utilisateur sur le système. Les sous-tâches techniques doivent, pour cette raison, toujours faire partie d'une story utilisateur et être mises en œuvre dans ce contexte."[1] BRAVO ! Très bien !
Mais ensuite... au lieu de décrire la façon dont l'équipe pourrait réorganiser cette story utilisateur, il recule : "(....) Il y aura toujours des aspects techniques qui ne pourront pas être directement liés aux besoins d'un client, par exemple, le passage à une nouvelle version de la base de données, parce que celle utilisée précédemment est prévue pour la maintenance ou parce que c'est trop complexe pour être traité comme une tâche d'une story utilisateur." ATTENTION : c'est une impasse !
Sa solution de formuler les stories utilisateurs semble, à première vue, très prometteuse et est effectivement élégante, mais finalement il manque l'un des fondamentaux indispensables au développement d'un produit basé sur l'idée de l'article New New Product Development Game. L'idée de Scrum a toujours été que l'équipe devait faire tout son possible pour livrer, comme une équipe entièrement dédiée à cette mission. Les choses qui sont exclusivement dans le backlog sont les choses que l'équipe s'est engagée à livrer.
Note : le backlog n'est PAS UNE LISTE DE TÂCHES ET NE DÉCRIT PAS CE QUI DOIT ÊTRE FAIT pour pouvoir livrer et il ne doit jamais être utilisé pour JUSTIFIER le travail.
Thomas Lieder écrit aussi : "Sous cette forme, il est facile de transmettre le sens et l'importance des tâches techniques au product owner." Mais ce n'est pas la question. Le Product Owner n'a pas besoin de comprendre pourquoi nous avons des tâches techniques à traiter.
Mon sentiment est que les développeurs, l'équipe, transfère la responsabilité d'une tâche technique au PO en passant par des stories techniques. C'est la même chose que de conserver les idées traditionnelles de gestion de projet pour les mettre en œuvre dans Scrum. Dans ce cas, le PO introduit tout ce qu'une équipe a à faire. Et non pas ce qu'ils ont à LIVRER.
Mais la responsabilité de ce qu'une équipe doit faire pour livrer des fonctionnalités est du ressort de l'équipe, par conséquent l'équipe n'a pas à le justifier auprès du PO.
