Bonjour
J’ai recommandé dernièrement que l’estimation en h/jrs n’est pas vraiment bonne donc j’ai pris la décision d’essayer avec le story point . Mais ma qu’est comment je peux estimer que les user story que l’équipe vient de les estimer ne dépasse pas le sprint de 2 semaines ?
Je ne me sers de l’estimation en charge ou en story point qu’au moment de la priorisarion des tâches, en début de sprint.
Après ma consigne est « faites ce que vous pouvez, tant que ça tient en deux semaines »
Et je trouve que ça fonctionne plutôt bien. Les développeurs se sentent à la fois responsabilisés, autonome et engagé, sans ressentir le côté flicage ou d’un engagement prématuré sur les délais vu qu’on sait tous que les estimations sont fausses.
2 « J'aime »
J’ajouterai que si les développeurs se rendent compte que la US ne tient pas dans les deux semaines, on se concerte pour découper cette US et tenir le sprint. En gardant à l’esprit que l’important c’est la livraison de valeur.
1 « J'aime »
Bonjour,
Au début tu ne pourra pas savoir si ça dépasse 2 semaines, même si je pense que les développeurs auront une bonne idée de si ça dépasse uniquement en voyant les tickets embarqués (sans estimation).
Si tu veux utiliser les story points je te conseil de ne jamais convertir en j/h. Car ça fausse la creation de ce référentiel en SP. Le risque étant qu’ils continuent à estimer en j/h et que les SP ne soit que des j/h cachés, tu perdrais le bénéfice de cette façon d’estimer.
Ce que tu peux faire pour te rassurer c’est embarqué un nombre de story points « min » et prévoir une fourchette haute pour compléter si vous avancez bien. En gros tu dis que tu prend 30 pts et tu anticipe 10 pts « bonus ». Il y a sûrement d’autres « bidouille » pour que ça soit accepté par le management mais celle là fonctionne.
J’aime cet état d’esprit : « s’appuyer sur l’estimation développeurs » qui comme dit se sentent capables et responsables de la valeur ajoutée au produit à apporter dans les délais impartis.
Le travail d’équipe prend alors toute son importance et les daily sont souhaités sans contrainte.
Pour l’estimation , vécu une seule fois en tant que dévellopeur (testeur), mais l’usage du poker planning m’avais complétement ouvert les yeux quant à la valeur ajoutée par les US et surtout à prendre en charge dans le sprint ou décaler.
Si vous êtes SM de l’équipe ce n’est pas à vous déterminer si l’estimation des dévs rentrent dans les 2 semaines(il n’y a même pas de lien entre les estimations des US et la durée du sprint).
Les Dévs peuvent prendre autant d’US lors du sprint planning(SP) qu’ils veulent en tenant en compte leur capacité et selon les sprints(les fonctionnalités priorisés peuvent être plus complexes d’un sprint à l’autre).
Pour leur capacité, ils peuvent comme par exemple prendre comme point de référence leur vélocité moyenne actuelle(que tu peux rappeler au début de chaque SP mais rien ne les oblige à prendre le même nombre de points que leur vélocité ou plus(car selon la complicité des US à chaque sprint et la disponibilité des membres de l’équipe(congés, absences prévues, jours fériés, les incertitudes…etc) ils pourront prendre plus ou moins de points.
Au fur et à mesure des sprints ils seront de plus en confiants sur leur capacité à chaque sprint et elle sera de plus en plus au tour de leur moyenne de vélocité(d’où l’intérêt de suivre l’historique de vélocité, l’idée étant que l’équipe puisse, au fur et à mesure des sprints avoir un plateau avec la vélocité qui se trouve au tour d’une moyenne souvent entre le 4éme et 8éme sprint au lieu de trop osciller ce qui est souvent le cas en début de projet sur les premiers sprints car ils feront face à beaucoup de contraintes techniques et des difficultés à affiner les US au début ).
Plus l’équipes travaille ensemble(maturité de l’équipe) plus elle sa vélocité moyenne est stable avec une confiance sur leur capacité réelle à chaque sprint.
L’autre aspect voire, le premier c’est de s’assurer(avec ton aide en tant que SM) que les US soient assez affinées/bien écrites et découpées(une bonne US est dite INVEST: Indépendante, Négociable, à de la Valeur, Estimable, small pour petite et Testable) pour rentrer dans un seul sprint sinon elles seront considérées comme des Epics à découper encore(une des indications qu’une US est trop grande: lorsque l’estimation de l’équipe est >= 8 points mais ce n’est qu’une indication car une US peut être plus complexe sans forcément être une Epic en tout cas si l’équipe détecte beaucoup de sous fonctionnalités Indépendantes donc pouvant être embarquées séparément alors il faut l’affiner encore au lieu de l’embarquer comme telle et de ne pouvoir la terminer qu’en partie).
Bonjour Maxime,
Je vous remercie pour vos commentaires. Cependant, ce qui reste flou pour moi, c’est comment je peux m’assurer que l’équipe respecte les délais et que le projet ne soit pas affecté par un éventuel retard.
Bonjour Jonathan ; alors si je ne peux pas savoir si ca dépasse 2 semaines ou pas alors comment je peux m’assurer que le projet respecte les délais et que le projet ne soit pas affecté par un éventuel retard.
Bonjour Monsieur,
Je me pose la même question concernant un projet d’une durée de 3 mois. Comment puis-je m’assurer qu’il n’y a pas de retard ? Par exemple, en utilisant l’estimation en heures/jours, nous avons un sprint toutes les 2 semaines, et grâce à ces sprints, je peux savoir si l’équipe progresse correctement ou non.
Malheureusement si quelqu’un avait la réponse à cette question, il serait mondialement vénéré par tous les professionnels de l’IT.
La plupart des projets (un minimum complexes) sont en « retard » dans le sens où la plupart les estimations initiales sont fausses, et de beaucoup. Aucune méthode ne permet de résoudre le problème.
Les méthodes Agiles prennent justement le parti de dire « on ne sait pas quand le projet sera totalement terminé, mais on vous promet qu’on délivrera de la valeur régulièrement ».
5 « J'aime »
Salut Mary,
Tu peux essayer de voir les choses autrement. Dans un projet, tu as grossièrement 3 variables :
- Le scope (ce que contient le projet)
- La durée
- La qualité
Malheureusement, dans la cadre de projet IT, tu ne peux pas figer ces 3 variables à l’avance (On rentre dans la théorie des systèmes complexe et des systèmes chaotiques, bref…).
En général, tu choisis une variable principale que tu souhaites figer. Dans ton cas, la deadline semble être la plus forte, donc il faudra jouer sur les 2 autres.
On peut jouer sur la qualité, c’est une stratégie valable dans le cas de projets court terme et « one shot ». Mais ça se paye très chère à plus long terme.
Reste le scope. C’est là que l’agilité rentre en jeu. Elle te permet d’ajuster le scope de ton projet de sprint en sprint. Si au cour d’un sprint, ton équipe se rend compte qu’une feature est trop longue à implémenter, ou si un retard se cumule de sprint en sprint, ça te permet de réduire le scope pour assurer une sortie à la date prévue.
L’important n’est pas « Comment m’assurer que mes estimations sont bonnes », mais « Comment m’assurer que je bosse sur ce qui est important », de manière à être sûre que « le plus important » soit bien terminé avant la deadline.
Si tu annonces à ton management que le portail sera release en Q2 2024, le management se fiche complètement de savoir si l’icône du panier sera bien réactive, ou si le menu utilisateur sera bien dans un panel coulissant. Il veut un truc en Q2 2024. Donc à toi d’ajuster le scope, de sabrer les parties « non essentiel » en cours de route pour avoir quelque chose à la date indiquée.
3 « J'aime »
En Agile le produit n’est pas driver par les délais.
Dans tout projet il y a trois paramètres: les délais, le coût et le scope et Agile s’intéresse plus au scope qui est variable contrairement au deux autres paramètres d’où le concept de triangle inversé.
Cela ne veut pas dire qu’on ne prend pas en compte les délais/contraintes de temps mais l’idée est que s’il y a un délai fixe qu’est ce que l’on pense pouvoir livrer dans ce délai de 3 mois par exemple et surtout qui a de la Valeur, d’où l’importance de la priorisation(en utilisant par exemple la technique comme MoSCoW) du PO pour que même si on ne peut pas tout livrer que ce qui est important dans ce délai.
On peut utiliser la technique de l’ Extreme Quotation (poker planning rapide/groupé de toutes les PBIs/US) permettant à partir de l**'estimation grossière**(après il faudra affiner au fur et à mesure à chaque sprint pour confirmer ou mettre à jour l’estimation des US priorisées) de tout ce qu’il a actuellement dans le Backlog Produit de projeter combien de Sprints seront nécessaires(à l’instant T) pour finaliser en divisant le nombre total de points restants dans le backlog par la vélocité moyenne(on peut même faire un tableau en prendre trois vélocités: la plus haute, la vélocité moyenne actuelle et la vélocité la plus petite au moment de la quotation) de l’équipe.
Selon le résultat du nombre de sprint calculé(à refaire à la fin de chaque sprint car la vélocité est recalculée et le backlog étant dynamique le nombre points restant peut varier) on peut voir si on sera dans les délais de trois mois ou pas et dans ce cas, s’ajuster(Adaptation le dernier pilliers de Scrum) le plus important sera re/dépriorisation du PO pour certaines fonctionnalités/US voire leur suppression carrément du backlog(par exemple les Won’t have/Want to have but not at this moment avec la méthode MoSCoW) sans que cela n’affecte le produit qui va être livré dans ce délai.
4 « J'aime »