Hello communauté, selon le Scrum Guide 2020, pouvez-vous expliquer pourquoi il est recommandé de définir d’abord l’objectif du sprint, puis de sélectionner les éléments du backlog produit (PBIs) ? J’ai du mal à comprendre cela, car selon moi, il est plus facile de définir l’objectif du sprint en fonction des PBIs. Dans le contexte de mon projet, les PBIs sont principalement liés au développement de fonctionnalités, à des améliorations ou à la correction de bugs. Mes PBIs ne sont pas très détaillés au départ, car les développeurs sont responsables de les affiner techniquement lorsqu’ils commencent à les traiter.
Par exemple, disons que l’objectif produit est de rendre l’outil plus user-friendly. Pour y parvenir, je pourrais créer un PBI comme ‹ Modifier l’écran d’importation de fichiers pour le rendre plus simple pour les utilisateurs. › Donc, pour moi, il est difficile de définir l’objectif du sprint sans d’abord examiner les PBIs. Qu’en pensez-vous ?
Je vais essayer de te donner une explication. Il faut voir l’objectif du sprint comme étant le cadre ou limite du terrain de jeux possible pour le prochain sprint.
Donc, en définissant avant ces limites, il est plus facile (normalement) de bien sélectionner les nouveaux PBI pour le prochain Sprint.
D’une certaine manière (vision simpliste, je l’accorde), l’objectif du sprint est une étape pour atteindre l’objectif de produit.
Pour faire une analogie simple, quand tu planifies un déplacement, tu choisis la destination avant l’itinéraire. En général tu ne vas pas sur le site de la SNCF, choisir des billets au pif, et constater où ça t’emmène. Tu décides d’aller à un endroit, et ensuite tu regardes quelles itinéraires sont possibles et correspondent à tes contraintes.
Déjà sur le principe, les PBI sont des « product backlog item » : ils vont dans le backlog produit, et non dans le backlog de sprint. Donc dire qu’en sprint planning, où l’objectif est d’établir un premier sprint backlog, on commence par choisir des PBI, c’est faire une erreur conceptuelle sur la nature des éléments manipulés :
Les PBI et les sprint goals sont de même nature : ce sont des problèmes à résoudre, qui ont une valeur pour les utilisateurs / le client / le sponsor. Ils sont stockés dans un backlog produit (d’où le nom de PBI) et priorisés par rapport à leur valeur potentielle pour les utilisateurs. On ne peut pas estimer leur coût, car ils ne correspondent pas à une réalité spécifique d’implémentation. Ce sont des problèmes à résoudre, ils admettent donc différentes solutions possible, qui peuvent avoir des coûts et des contraintes différentes ;
Les tâches sont les actions à accomplir par l’équipe pour essayer de fabriquer un produit/service qui va résoudre le problème des utilisateurs. Ce sont ces éléments qui sont répartis entre les membres de l’équipes et qu’on décide en début de sprint dans un sprint backlog. Ce sont des actions concrètes et spécifiques, dont le coût peut être estimé, même si globalement ça n’a pas beaucoup d’inérêt.
En génie logiciel, il y a parfois des problèmes standard, pour lesquelles il y a des solutions standard. En général, dans ce type de situation, un client fait appel à un produit sur étagère, ou au pire organise un projet de développement en cascade. Mais il y a aussi beaucoup de problèmes originaux, complexes et d’innovation. Dans ce cas, il est difficile de trouver une bonne solution (fonctionnelle, performante, rentable) du premier coup et par un pur travail d’étude. Comme on sait que la solution adaptée ne peut pas être connue dès le départ, on accepte une démarche heuristique et empirique, de remettre l’ouvrage sur la table au fur et à mesure. C’est le principe des méthodes itératives et agiles comme Scrum :
Au départ, lors du sprint planning, on va donc imaginer une solution « naïve » au PBI qui a été élevé au rang d’objectif de sprint. On va déterminer une liste d’actions à réaliser pour fabriquer cette solution, ou pour lever des hypothèses. C’est le sprint planning.
De manière quotidienne, on se réunit, non pas pour échanger sur l’avancement des tâches, mais pour discuter de l’opportunité de changer le plan d’action (l’itinéraire) pour atteindre l’objectif de sprint ;
Pour éviter que ça devienne un puits sans fond en terme de couts, on fixe un délai maximum pour atteindre l’objectif : c’est la durée sprint.
A l’issue du sprint, on présente ce qui a été fait durant le sprint aux parties prenantes. Soit les travaux donnent satisfaction et on peut célébrer la valeur produite, soit ce n’est pas le cas et on peut rollback à la version précédente ou poursuivre le travail sur le même objectif.
On peut cependant avoir plusieurs PBI sur un sprint. Un seul sera l’objectif du sprint, mais dans l’hypothèse où on aurait assez avancé sur l’atteinte de l’objectif, ou si certains membres de l’équipe sont bloqués, on peut imaginer avoir identifié 1 ou 2 PBI additionnel pour éviter la rupture de charge.
Tu souhaites inviter des amis à dîner le week-end prochain. Tu as une semaine pour organiser ce moment convivial avec des personnes que tu n’as pas vu depuis longtemps et tu souhaites qu’ils passent un bon moment.
En soi ce n’est pas un objectif mesurable ou spécifique ou même pertinent. C’est pour l’instant un « livrable » : recevoir et nourrir des gens
1ere possibilité : Tu décides donc de donner du sens à cet événement : je me suis spécialisé dans la cuisine espagnol, je maîtrise quelques recettes, je veux que ça soit convivial, festif, gustatif etc.
Donc tu vas planifier tes courses suivant les recettes choisies, organiser ton plan tes commandes ta musique tes cocktails, tu peux même facilement communiquer cet objectif pour que des invités adhèrent, se déguisent, amènent des vins espagnols, je ne sais quoi
Est ce que l’inverse est vraie ?
2eme possibilité : Je ne sais pas ce que je veux faire, je vais faire les courses et après on verra ce que je ferai concrètement et on verra si j’ai le temps et en plus je vais sûrement rusher en fin de semaine pour que mon invitation ait un peu de la gueule
Moi j’ai tendance à choisir la première possibilité
L’objectif te permet de donner du sens et de l’engagement. Ça amène de nouvelles idées pas initialement prévues et ça va amener plus de cohérence grâce à la participation de tous car l’objectif est clair et parle à tout le monde.
Une petite saynète pour expliquer plus concrètement comment ça fonctionne :
Le PO étudie le marché et identifie deux problèmes à résoudre :
« rendre l’outil plus user-friendly »
« rendre l’outil compatible avec les outils pour personnes malvoyantes »
Il met les 2 éléments dans son backlog produit, ce sont donc des PBI.
Puis, en sprint planning :
PO: « Ok l’objectif du sprint est de rendre l’outil plus user-friendly. On aurait aussi pu travailler sur la compatibilité pour les personnes malvoyantes, mais actuellement on a peu de prospects qui sont concernés, donc j’ai préféré prioriser un sujet qui permettra d’améliorer le produit pour tout le monde. Si à un moment vous êtes bloqués, vous pouvez toutefois commencer à y réfléchir, c’est un sujet important pour le produit également. Mais revenons à l’objectif de sprint, avez-vous des idées pour rendre l’outil plus convivial ? »
Dev: "Je pense qu’on devrait modifier l’écran d’importation de fichiers pour le rendre plus simple pour les utilisateurs. Actuellement c’est vraiment trop compliqué pour eux. "
Autre dev : « Je suis d’accord. On pourrait aussi faire … »
A l’issue du sprint planning, l’équipe établit la liste des tâches identifiées dans le sprint backlog, en dessous de l’objectif de sprint et se met au travail.
