Les objectifs sont par essence liés au enjeux, envies, motivations et capacité des organisations
J’aime faire les relations avec le sport.
Un personne ou un groupe de personne peut se donner comme objectif de terminer une course de 10km
Une autre personne ou un groupe de personne peut se donner comme objectif de le faire en 4:00/km
Les 2 sont valables en fait
Tout dépend du contexte
Cependant je pense que les objectifs doivent sans cesse être plus audacieux, plus mesurables, plus quantifiables et personnellement j’aime beaucoup l’exemple de @Samuel_Abiassi car il est parlant pour tout le monde, utilisateur et développeurs
Oui, ne pas confondre économie et le domaine de la technologie ou de l’utilisabilite des applications
Quand Amazon a lancé le one-click patent ça c’était un sacré objectif
Je pense que les objectifs de Google en 1998 étaient chiffrés , rien qu’avec un nom qui donne la voie à suivre
Etc.
Dans votre exemple de la connexion, les 2 US sont donc indépendantes techniquement donc on les prend dans le même sprint ? MAIS si l’utilisateur nous fait de gros retours sur la 1ere en disant par exemple qu’il fallait pouvoir avoir accès à plusieurs comptes en même temps et que cela remet en cause la façon de faire l’US de connexion… Là, il faudra reprendre le dev de 2 US… Il me semblait que ne pas les faire ensemble permettait justement d’éviter ce problème.
Ou alors j’ai mal compris et justement il ne faut pas prendre ces 2 US dans le même sprint pour dé-risquer la feature d’abord. Mais alors à ce moment là, on retombe sur le problème du sprint goal. Si dans ce sprint on voulait proposer aux utilisateurs d’avoir accès à leur espace et bien on ne peut pas. Il faudra le faire en 2 sprints minimum : le compte puis la connexion et on repart sur du dépilage de ticket en dé-risquant un peu chaque feature…
Récolter le feedback le plus rapidement, OK pas de soucis. C’est ce qu’on fait.
Par contre dire « Un sprint n’est pas une itération », ça m’embrouille plus qu’autre chose.
Pour moi, ne pas prendre d’US (ou de SBI) liés entre elles permet surtout de ne pas « perdre du temps » dans une direction qui ne serait pas la bonne. C’est pour ça que pour moi tant qu’on avait pas le feedback de l’utilisateur, on ne prenait pas une autre US sur le même « sujet » car potentiellement il faudrait refaire 2 choses plutôt qu’une. Car même si on dit qu’on récolte le feedback avant la fin du sprint, on ne sait pas quand on aura ce feedback et donc quand on pourra commencer la suite et si on pourra la finir (ou du moins apporter de la valeur en plus d’ici la fin du sprint)…
On vient de dire qu’on peut (doit ?) récolter du feeback sans attendre la fin du sprint. Donc pourquoi adapter la durée du sprint à la durée de récolte du feeback ??
Et pour répondre à @Samuel_Abiassi à la question « Pourquoi avoir des sprint goal ? » : et bien autant je comprend l’intérêt d’avoir des sprint goals, autant je ne vois toujours pas comment les mettre en place sans perdre d’autres gros avantages (comme le fait de dé-risquer une feature rapidement grâce au feedback notamment)
Je vais continuer à me renseigner sur le sujet car cela m’intéresse
Un sprint contient généralement pas qu’un SBI pour atteindre le but. C’est un tout cohérent. Si l’équipe pense que la timebox du sprint n’est pas assez pour atteindre l’objectif, rien ne sert de continuer le sprint. On annule, on replanifie avec les nouvelles informations et surtout on inclut les nouveaux feedbacks en tête.
Le but est double : on prend le temps de replanifier, et on envoie surtout un message fort à tout le monde en disant « on a apprit quelque chose qui change notre perspective et notre direction, on a besoin de temps pour repositionner la trajectoire ».
Mais maintenant que j’y réfléchis, sur ce sujet, l’un des points que le Lean a pas forcément bien compris vis à vis du TPS, c’est la notion de Set-Based Design:
J’ai un problème, X solutions pour y répondre, je lance en parallèle les X solutions et je synchronise assez tôt pendant l’implémentation pour tirer le maximum d’informations de toutes ces implem’ et choisir celle qui est la plus pertinente.
Pour aller plus loin, et repartir sur la notion de Kaizen, en retro, c’est pas 1, 2 ou 3 actions que les ingénieur·es de Toyota prendrait, mais TOUTES en abandonnant rapidement celles qui ne portent pas leurs fruits. (pour dire, y’a même des quota de Kaizen xD)
, rien qu’avec un nom qui donne la voie à suivre
