Sprint Goal : son utilité ? (IRL)

Communauté Scrum Life
,
1

Bonjour tout le monde !

Dans mon équipe, il y a un dév à l’esprit logique très très affûté, qui remet régulièrement en question le framework Scrum, quand il considère que telle ou telle pratique n’a pas de sens (dans notre contexte, au moins).
C’est bien car ça m’oblige à à creuser, à parfaire mon argumentaire, et, à terme ça va me rendre meilleure et augmenter ma confiance! :grinning:
Mais je me trouve parfois à court d’arguments…

Il boude la discussion sur le Sprint Goal en Sprint planning, parce qu’il considère que c’est redondant d’avec la priorisation des tickets.
En effet, selon lui, si les tickets sont priorisés, on sait déjà ce qui est prioritaire de faire pendant le Sprint, et alors pas besoin d’un Sprint goal.

Contexte :

  1. J’ai ramé pour obtenir, depuis seulement quelques Sprints, qu’on définisse un Sprint Goal pendant le Sprint planning,
  2. La P.O. n’a pas encore un Product Backlog fourni et priorisé (elle créé les tickets à la dernière minute en fonction des besoins métiers immédiats),
    => alors pour l’instant le Sprint Goal est souvent discuté en fin de Sprint Planning, après qu’on ait répondu au What et How…

Mes arguments actuels PRO Sprint Goal sont que :

  1. Ca donne un cap (mais encore une fois, la priorisation des tickets est déjà un cap, il a raison!), et
  2. que ça aide l’équipe à dire « non » à des demandes « urgentes » en cours de Sprint, quand elles risquent d’empêcher l’équipe de poursuivre l’objectif de Sprint.

En avez-vous d’autres, svp?

Merci! :slight_smile:

1 « J'aime »
2

Hello,

De mon côté je l’utilise comme « enseigne lumineuse » au dessus de mon board klaxoon. Toujours visible, tel un phare dans la nuit.
Comme ça, à chaque daily, tout le monde la sous les yeux et même si on n’y prête pas attention, on le voit. Un peu comme les tables de multiplication affichées dans les toilettes :grin:.

1 « J'aime »
3

Salut,

Petite question qui pourrait amener un axe de réfléxion:
Est-ce que la seule priorisation des tâches permet de déterminer l’avancement du Sprint de sorte à ce que ce dernier soit en accord avec la vision Produit ?

Parce que, si ma mémoire est bonne, au delà du dépilement des tickets, c’est à cela qu’est censé servir le Sprint Goal: mesurer l’avancement vers un objectif Produit afin d’atteindre au plus proche la vision Produit.

De fait, une tâche considérée en elle-même comme prioritaire peut être mise de côté en fonction de la valeur que l’on cherche à atteindre, si cette dernière a plus de sens.

Je pourrais rajouter que le Sprint Goal est censé être défini avant la prio des tâches, et que cette dernière dépend donc du Sprint Goal.

Et puis, comme dit le dieu du tonnerre dans le MCU, « On peut se fier à la vision ! »

4

Bonjour Charlotte,

Le sprint goal n’est pas un cap à suivre, c’est la destination.
La priorisation des tickets n’est pas un cap non plus, c’est uniquement le plan au jour 1 du sprint. Il est fort possible qu’au jour 2, la priorisation soit modifiée. Et à la limite tant mieux, car si tout est prévu à l’avance et que le cap ne change pas, on risque de finir dans le mur (ou les rochers si on garde la métaphore de la navigation)

L’incompréhension des développeurs sur le sprint goal est assez fréquente surtout parce qu’à la base le PO et les parties prenantes ont du mal à se fixer un objectif concret sur un temps court de sprint : PO et métiers ont une vision à plus ou moins long terme et les développeurs ont souvent la tête dans le guidon, la tête dans leurs problématique concrète de code et se pose parfois même pas la question de savoir pourquoi on leur demande de faire ça.

Le sprint goal a l’avantage de pousser les « métiers » à être concret et les développeurs à prendre de la hauteur de vue. C’est un peu un entre deux. Ca permet à tout le monde de s’entendre sur ce que l’on va obtenir à l’issue du prochain sprint en terme de valeur et non en terme de détail.

Pour le développeur, il peut ensuite discuter de la pertinence de ses « tickets » et du contenu du ticket pour savoir si ça matche bien avec le SG, il n’a plus besoin de suivre « bêtement » l’ordre pré-établi et l’ordre prescrit dans les RDG ou critères d’acceptation s’il y en a. Ce que le PO a écrit il y a 2 mois sur une US, est-il vraiment encore d’actualité avec ce sprint goal, est-ce que ce critère d’acception est il indispensable pour l’atteindre ?

Ca amène bien évidemment de la responsabilité en plus au développeur car il le sprint goal doit amener les personnes à comprendre pourquoi on code ça et donc il est plus difficile de se dédouaner d’erreurs, d’incompréhensions parce qu’'il a fait juste ce qui était écrit.

Alors pour conclure, le SG est là pour donner du sens au sprint, une destination. LE sg est le formalisme le plus simple pour négocier le travail du sprint et que donc il est nécessaire que le développeur s’empare du sprint goal comme d’un contrat moral de l’équipe entière (PO et developpeurs) sur les résultats à fournir.

4 « J'aime »
5

Pour compléter l’excellente réponse de Nicolas, le traduction de sprint goal = objectif de sprint.

Dans l’armée, les ordres de déplacement sont donnés dans un cadre précis qu’on appelle le DPIF. C’est un acronyme qui signifie : Direction, Point à atteindre, Itinéraire, Formation. L’ordre est important, car une fois qu’on a fixé le point à atteindre, on ne peut plus discuter de la direction à suivre. De la même manière, on peut proposer différents itinéraires pour atteindre un objectif donné, mais quand on a décidé d’un itinéraire, on n’a plus le choix de l’objectif à atteindre.

En déterminant le sprint backlog avant le sprint goal, on a créé un objectif implicite, qui consiste à suivre l’itinéraire. C’est ce qu’on appelle un commandement par ordre. C’est l’approche qu’on associe dans l’imaginaire collectif au travail militaire : débranche le cerveau et fait ce qu’on te dit de faire. Mais dans l’armée on a aussi recours au commandement par objectif : voici un effet à obtenir, voici les contraintes et limites à ton action, à toi d’élaborer un plan. C’est le genre d’approche qu’on recherche dans une équipe agile. D’où l’importance de décider d’un sprint goal en amont des discussion sur le sprint backlog.

Ca veut dire aussi que l’établissement d’un product goal par le PO est plus important qu’un remplissage et une priorisation fine du product backlog. Sinon, encore une fois, on envoie un message aux équipes qui insiste plus sur le suivi d’un plan que sur l’adaptation au changement.

2 « J'aime »
6

Très pertinent ce lien avec l’armée

7

Merci Nicolas, pour cet élément d’étude. J’avoue également apprécier le terme « navigation » abordé une fois en commentaire de vidéo Scrum life tv,et visualise mieux pour ma part les tickets comme des obstacles rencontrés et modification d’itinéraire à prendre en compte lorsque ces derniers deviennent réalité.

Je pensais alors au plan de route voiture pour arriver à destination contré par embouteillage la priorisation ticket prend son sens car le sprint reste le même. Mais la gestion tickets offrent d’autres opportunités. Par contre là où c’est intéressant et où je m’emballe peut être un peu : le rôlr de la testeuse dans la DEV team a tout à y jouer car peut aider à anticiper les changements de navigation en prévention des tickets.

A la fois merci pour le clin d’oeil et désolé d’avoir écarté la direction de l’échange.

8

Je ne le dirais pas mieux que Nicolas
Le sprint goal est l’ajout qui manquait à un sprint planning qui se limitait à une liste de tickets priorisés.
Il manquait la cible, la destination, on ne sait pas où on va. Le sprint goal a cet avantage.
Par contre, de mon côté je préférerais l’inverse, tu présentes l’objectif du sprint, et après tu vérifie les cartes que tu auras besoin pour atteindre cet objectif. Les autres cartes etant arbitrables.
En daily, tu pourras du coup te poser la question si un problème remet en question l’objectif de sprint.

En bon développeur, connaître une trajectoire court, moyen et long terme aide à mieux anticiper les changements

9

Dans mon équipe, j’agis en tant que PO et beaucoup coach aussi :slight_smile: j’ai un objectif à atteindre qui est clair dès le début du sprint planning : un certain nombre de PBI sont identifiés en amont et on a une valeur business travaillée en transparence avec les métiers.

Je suis là en sprint planning pour expliquer concrètement la valeur de ces PBI. J’applique des cas concrets leur montrant l’intérêt de changer les choses et quelle est ma vision, à l’instant t, de l’implémentation idéale (pour moi) de telle ou telle US et donc de comment je vois les choses.
Je laisse les développeurs débattre des PBI, je les laisse me proposer d’autres alternatives, tout en gardant à l’esprit que les adaptations (améliorations d’US, simplifications, découpage) doivent servir l’objectif : collaboration, transparence et respect des opinions dans le cadre d’un objectif à atteindre.

A la fin du sprint planning, quand le contenu du sprint backlog est élaboré, la liste des tickets est souvent moins ambitieuse que prévue (maudit biais d’optimisme). Alors on affine le sprint goal sur la composante « Mesure » du l’acronyme S.M.A.R.T, afin de rendre le sprint goal atteignable mais quand même challengeant pour l’équipe.

Je prends aussi souvent l’exemple de la course à pied, si vous aimez un peu la compét, il se peut que vous souhaitiez faire un 10k dans 3 semaines et obtenir un temps inférieur à 50 minutes. Pour cela vous élaborez une feuille de route dans un sprint backlog : 3 sorties par semaine, alterner sorties longues en fondamentale et fractionné. Sauf qu’en 3 semaines vous allez avoir des empêchements, vous n’allez pas réussir à courir votre sortie longue dans le temps prévu, vous allez être malade. Cependant, vous n’allez pas être jugé sur la tenue de votre plan, mais sur l’atteinte ou non de votre objectif. Et si au final vous faites votre 10k en 52’, ça change quoi ? Pas grand chose ! vous abimez votre égo mais vous progressez sur votre vision qui peut être d’être suffisamment prêt pour le marathon que vous ambitionnez dans 1 an.

1 « J'aime »
10

Bonjour à tous·tes,

Merci pour vos contributions ! :pray:t5:

Je suis d’accord avec vous sur ce qu’est un Sprint Goal, et qu’il devrait être fixé AVANT le reste pendant le Sprint planning.
C’est bien pour ça que j’ai précisé :

Contexte :

J’ai ramé pour obtenir, depuis seulement quelques Sprints, qu’on définisse un Sprint Goal pendant le Sprint planning,
La P.O. n’a pas encore un Product Backlog fourni et priorisé (elle créé les tickets à la dernière minute en fonction des besoins métiers immédiats),
=> alors pour l’instant le Sprint Goal est souvent discuté en fin de Sprint Planning, après qu’on ait répondu au What et How…

Pour être complètement claire, j’aurais sûrement dû ajouter « et je le déplore ».

Je déplore que ce soit ainsi, et je sais pertinemment que ce n’est pas une bonne pratique. Mais j’avance au rythme possible, compte tenu de ce dont j’ai hérité en devenant SM dans cette équipe. :no_mouth:

Et si je veux voir le verre à moitié plein, je dirais que partant de rien du tout, et avec toutes les résistances contre lesquelles je lutte, avoir obtenu qu’on discute d’un Sprint goal, c’est déjà un succès. Même si c’est après tout le reste, même si les dév n’en voient pas l’intérêt, même si pour le moment, en Daily, les dév ne s’en préoccupent pas, etc.
La patience est le moindre de mes défauts = je suis la première à souffrir de la lenteur de transformation de l’équipe ! :roll_eyes:

@nicobiot : un cap ou une destination, certes ce n’est pas exactement la même chose, mais dans la vraie vie, ça revient souvent au même : on avance vers l’objectif. Si on l’atteint, c’est la destination, si on ne l’atteint pas, c’est le cap.
Or, dans notre cas, on est très loin d’atteindre toujours la destination!

Bref.

La question de départ était : auriez-vous des arguments (concrets, pratiques, transposables dans la vraie vie d’une équipe de dév) en faveur du Sprint goal, dans le contexte décrit = on n’a pas un Product Backlog digne de ce nom, dans lequel les dév choisiraient collaborativement avec la P.O. les tickets les plus pertinents à développer compte tenu d’un Sprint goal pré-défini.

On a des tickets faits au fil de l’eau par la P.O., souvent en catastrophe la veille du Sprint planning. On vient seulement d’entendre parler d’un Product Goal annoncé par la P.O. Enfin ! (Peut-être parce que j’ai soulevé le sujet plusieurs fois ? J’aime à le croire. Ca voudrait dire que je n’ai pas rabâché en vain!). :stuck_out_tongue_closed_eyes:

@Delio : merci pour cet argument, oui! un ticket ‹ haute priorité › peut être dégradé en ticket moins prioritaire, alors que le Sprint goal, lui, ne bougera pas (en substance).
Ca n’arrive jamais dans notre contexte, puisque les tickets sont créés juste avant le Sprint planning, et souvent leur priorité n’est définie que pendant le Sprint planning.
Du coup, un ticket ‹ haute priorité › reste ‹ haute priorité ›, puisqu’il est créé pour le Sprint.

Mais cet échange m’a permis d’envisager un 3è argument : prendre la bonne habitude de réfléchir en Sprint planning à un Sprint goal, car il nous sera utile quand le contexte sera « normalisé » => quand on aura un PB digne de ce nom, des tickets pré-existants et pré-priorisés, et que notre Sprint planning se déroulera comme il devrait, avec une discussion collaborative sur ce qui doit être pioché dans le PB pour réaliser le Sprint goal, que la P.O. aura suggéré au début :wink:

@nicobiot merci pour le 4è argument :pray:t5: : « Le sprint goal a l’avantage de pousser les « métiers » à être concret et les développeurs à prendre de la hauteur de vue. C’est un peu un entre deux. »

Bonne soirée à tous·tes!

11

Si tu poses la question au PO en début de sprint planning « Pour quoi (en deux mots) veux tu que l’on travaille pour ce sprint? » qu’obtiendrais tu comme réponse ?

Définition des objectifs dans l’appli Strava

Les objectifs vous donnent quelque chose à rechercher - ainsi qu’une chance de suivre vos progrès et de célébrer des jalons. Alors donnez-vous un coup de pouce. Fixez-vous un objectif et commencez à le poursuivre dès aujourd’hui.

12

Des arguments pour convaincre qui ?

C’est pas tant l’équipe de dev qu’il faut convaincre d’avoir des objectifs de sprint. Du point de vue des développeurs, la direction à suivre est un entrant, ensuite le sprint planning c’est une discussion collégiale sur l’ambition de l’objectif par rapport à la durée du sprint et la crédibilité du backlog proposé.

C’est à la PO d’arriver en planning avec la vision que l’organisation va investir X k€ pour un sprint de N semaines dans l’espoir d’en récupérer un ROI de Y k€/an. C’est à elle qu’on va demander des comptes pour savoir si l’argent a été bien dépensé ou pas. Et donc normalement y’a pas besoin de la convaincre, c’est plutôt son rôle à elle, de convaincre l’équipe et le parties prenantes qu’il faut investir dans telle fonctionnalité plutôt qu’une autre pour apporter un max de valeur aux utilisateurs.

Et justement, aujourd’hui ça bloque parce que la PO, au lieu d’arriver avec un objectif à atteindre en laissant l’équipe organiser son plan de bataille, elle vient avec un backlog. Alors l’équipe développe ce qu’on lui dit de faire.

Est-ce ta PO n’aurait pas tout simplement besoin d’aide dans son approche digital marketing ?

Question bête, mais est-ce qu’elle a des compétences et de l’expérience en marketing ?

Edit: encore une question bête mais est-ce que vous savez « mesurer le succès » ?

1 « J'aime »
13

Pour moi, on est dans un contexte dysfonctionnel… mais où les dév ne souhaitent pas de changement, et où la P.O. dit ne pas pouvoir ce changement.
Elle est très occupée à des tas d’autres choses que la gestion de son PB, et elle a ouvertement admis ne pas souhaiter renoncer à ses autres tâches (elle seconde le chez du DSI, participe à des tas de comités, etc.).
Ca fait un an que j’essaie d’obtenir qu’elle s’occupe de gérer son PB, je lui ai proposé maintes fois de l’y aider, en vain…

Et pour répondre à tes questions, ce sont des arguments pour convaincre TOUTE l’équipe, que je souhaitais rassembler.
Je ne crois pas que la P.O. ait de l’expérience en marketing, non.
Et, on ne mesure pas le succès, non. Comme dit plus haut (sauf erreur), je n’ai pas pu obtenir de savoir quels indicateurs étaient utilisés pour mesurer le succès/la valeur. Je crois qu’il y a un travail d’analyse business qui n’a pas été fait du côté client. Tout se fait un peu « à l’arrache » à mon sens.

Quoiqu’il en soit, à l’heure où j’écris, je suis à nouveau très découragée, et je pense que je vais surtout essayer de me recycler ailleurs :wink:

Je vis mon rôle de SM sans joie, avec beaucoup de frustration et l’impression de n’être pas du tout respectée (un mauvais pli a été pris au départ, je pense) et je trouve le rôle de P.O. beaucoup plus intéressant !

Merci pour tes interventions, conseils et pistes de réflexion, Adrien ! :pray:t5:

14

D’expérience, l’équipe de dev n’a pas besoin d’être convaincue, le rôle de PO donne le ton.

Manifestement une erreur de casting.
Peut-être même qu’elle est en souffrance sur ce rôle et serait contente d’en sortir.

Tu penses pouvoir aborder avec elle et votre hiérarchie cette option pour qu’elle se concentre sur ses autres tâches, et que l’équipe bénéficie d’une autre personne plus en phase avec le rôle ? Est-ce que l’organisation n’aurait pas aussi une vision biaisée du rôle ? On dit un peu partout qu’un PO c’est quelqu’un qui vient du métier. Mais en vérité, c’est justement un rôle avec une connotation marketing / BA qui vous fait tant défaut …

… ou de jouer aux chaises musicales, avec toi en nouvelle PO, et l’entrée d’une nouvelle personne comme scrum master …

1 « J'aime »
15

Notre P.O. est une consultante externe d’une ESN que le client paye pour remplir ce rôle.
(Les tentatives de mes managers de convaincre le client de prendre quelqu’un-e de leur propre staff pour le poste n’ont pas porté leurs fruits, pour des raisons qui m’échappent).

Selon ce qu’elle a admis elle-même, elle préfère ses autres fonctions, plus « macro », plus stratégiques. Et je suis quasi sûre qu’elle veut installer la B.A. (consultante de la même boîte que la P.O.) sur le rôle de P.O. après elle. Pour l’instant, la B.A. fait un boulot de Proxy P.O. sur la partie mobile de notre appli, ce qui la forme sur le produit et l’introduit gentiement dans l’équipe.

Tout ça sur fond de « refonte du SI » chez le client, commencée depuis un bon moment, qui, à mon avis, signifie notre éviction à moyen terme (+/- 1 an).

=> aucun espoir que je devienne P.O. à la place de la P.O. : ma boîte ne fera plus de vieux os avec ce client ! :smile:

Ceci explique sûrement cela : la P.O. se désintéresse peut-être de son PB, parce qu’il n’a plus vraiment de sens. On est entrés dans une grosse phase de résorption de la dette technique de l’appli (plein d’upgrades à faire), mais le plus important chez le client, actuellement, c’est cette mutation en cours.

Encore merci Adrien pour ton aide !