Je suis Scrum Master depuis peu, et une question me trouble depuis un certain temps.
Lorsque l’objectif du sprint est défini, que doit-il contenir ?
Je m’explique.
L’application sur laquelle je travaille est en phase de développement, mais c’est une assez grosse application et une partie est donc déjà en production.
Il y a donc régulièrement des bugs qui remontent de la production et qui sont plus ou moins prioritaires.
Lors des derniers sprints, l’objectif concernait premièrement le côté fonctionnel (As a, I want, So that) qui était « réalisé » par des US, mais aussi des bugs (Fix blocking PROD bugs, par exemple).
J’ai le sentiment que ce type d’objectif n’amène pas grand chose car il n’est pas réellement concret.
Des bugs bloquant peuvent s’ajouter durant le sprint et, de plus, les bugs peuvent venir de parties de l’application complètement différentes.
Et donc cet objectif est tellement vague qu’il ne sert à rien.
@const est frustré, car les membres de la communauté sont réactifs. Si tanter qu’il n’a pas le temps de répondre car les réponses contiennent les idées qu’il veut partager.
J’offre pour les prochaines 24h la parole à @const.
L’objectif c’est l’argument ultime qui indiquera aux parties prenantes pourquoi le sprint va apporter de la valeur
C’est pas moi qui le dit mais le scrum guide
L’objectif est l’engagement de l’équipe pour le sprint et amène focus et transparence
Donc l’objectif a besoin d’être concret car il doit parler à la fois aux développeurs et aux parties prenantes, d’être précis, non ambiguë, mesurable, motivant etc.
L’objectif n’est pas sensé décrire tout ce qui sera fait dans le sprint, déjà parce que l’on n’est pas sensé savoir en sprint planning tout ce qui sera fait dans le sprint
Le soucis avec les objectifs de sprint c’est qu’il est établi sous la forme de résumé du sprint backlog et du coup ça veut plus rien dire à personne
De ce fait on doit rentrer dans le story telling, le PO doit « vendre » le sprint, et je ne connais pas beaucoup de PO qui savent le faire
Ca fait partie des exercices à mettre en place : essaye de me vendre en 1 phrase le dernier sprint que tu as fait, et si ma grand-mère comprend ta phrase, c’était que c’était un objectif de sprint efficace
Je préfère prendre le problème dans l’autre sens.
Quel est l’objectif produit ? Et comment chaque sprint va contribuer à l’objectif produit ?
Pour moi, le sprint goal représente une étape de valeur pour avancer vers le product goal.
En conséquence, je ne fabrique pas le sprint goal en fonction du contenu du sprint backlog.
En effet, si je devais le faire, cela n’aiderai pas mes parties prenantes à comprendre comment j’avance.
Et parce que je fais confiance à mon équipe, alors elle n’a pas besoin de raconter tout ce qu’elle fait pendant un sprint.
Plusieurs possibilités s’offrent :
faudrait-il améliorer la DoD ?
avez-vous laisser suffisamment de place à l’incertitude dans chaque sprint (un bug n’est pas connu d’avance) ?
faudrait-il prévoir un objectif pour stabiliser le produit afin d’améliorer l’expérience utilisateur ? Et la votre dans la capacité à limiter les interruptions et se concentrer sur des nouvelles initiatives.
