Discussion :

[Biosox]

Bonjour,

Avec mon équipe on débute dans Scrum. On se fait un peu aider par des gens qui ont eu de l'expérience, et on a lu pas mal de bouquins sur le sujet, mais on "se cherche" encore un peu.

Une des questions que j'ai, c'est: Quand est-ce le bon moment pour estimer les points des stories?
A priori, durant un sprint, des nouveaux items pourront atterir dans le produck backlog. Le rôle du product owner est de leur donner un niveau d'imoprtance, et le rôle de l'équipe est de les estimer.
Mais quand? attendre le prochain sprint planning ne me convient pas vraiment. D'une part je pense qu'il vaut mieux que cette estimation soit déja connue avant le sprint planning (pour pas que celui-ci ne s'eternise) et d'autre part, pour avoir une vision à long terme il faut que la majorité des stories dans le product backlog soient estimée (sinon on peut facilement donner la date de fin du prochain sprint, mais on a aucune estimation valable pour le plus long terme. D'un autre coté... si on attend pas le prochain sprint planning et qu'on mobilise l'équipe à chaque fois qu'un nouvel item arrive dans le product backlog, on passe complétement à coté de la méthode...

Comment faites vous de votre coté?

[montesq]

Il ne faut clairement pas déranger l'équipe pour faire des estimations en cours de sprint. L'équipe doit se concentrer sur le produit à livrer, c'est tout...
Donc la seule (et unique?) solution est effectivement de faire l'estimation juste avant le planning du sprint suivant...
Contrairement à l'estimation de l'ensemble du backlog produit, ces nouvelles estimations entre sprint doivent théoriquement être plus rapides, car la part d'incertitude sur le produit (aussi bien fonctionnelle que technique) décroit au fur et à mesure du projet, donc l'équipe à une meilleure visibilité sur les tâches à effectuer pour la réalisation des stories...

[Biosox]

Hello, et merci pour votre réponse.
Mais vous dites

Contrairement à l'estimation de l'ensemble du backlog produit...

Selon ma compréhension, l'estimation de l'ensemble du backlog produit correspond à l'ensemble des estimations de toutes les stories qui sont dans le backlog. J'imagine bien qu'une story qui sera faite "dans quelque sprints" a aujourd'hui une estimation bcp plus grossière que lors du sprint planning durant lequel elle sera effectivement incluse. Peut-être même que d'ici la elle sera separée en plusieurs stories distinctes. Mais il n'empèche que son estimation grossière aujourd'hui a bien du être effectuée par l'équipe, c'est précisément ce qui me pose problème.

Comment faites-vous? lors du sprint planning vous estimez les stories que vous introduisez dans ce sprint-ci, et en plus vous passez en revue plus rapidement et grossièrement les autres stories à ce même planning?

merci

[montesq]

Comment faites-vous? lors du sprint planning vous estimez les stories que vous introduisez dans ce sprint-ci, et en plus vous passez en revue plus rapidement et grossièrement les autres stories à ce même planning?

Il est "nécessaire" d'estimer seulement les stories que tu souhaiterais inclure dans le nouveau sprint (et les nouvelles stories qui apparaissent si tu es sûr qu'elles devront être développées au cours de la release). De cette façon, si une story avait une estimation de 13 et que finalement, à cause de la réalisation d'une autre story ou parce que le besoin fonctionnel est finalement plus simple, l'estimation devient 5 et tu as "dégagé" 7 points pour d'autres stories.

A mon avis, ce n'est pas la peine de ré-estimer tout le backlog car:
1° tant qu'une story n'est pas éligible, il peut y avoir des ajustements d'ordre fonctionnel/ergonomique/technique...
2° certaines stories ne peuvent potentiellement être jamais développées au final

[Biosox]

Je comprends bien, seulement ça m'embète un peu:

Le managment a une idée de ce a quoi va ressembler notre produit dans 1 mois, 2 mois, 6 mois...
pendant qu'on commence a developper, les vendeurs vont être confrontés au marché et se rendre compte que la vision a 6 mois devrait être un peu différente de ce qu'on avait eu. Et donc certaines idées vont évoluer et d'autre disparaitre, ce qui correspond a enlever des stories ou en modifier des autres. Donc c'est évident: estimer tout le backlog a chaque fois est long, inutile et sans doute même impossible.

Mais si la vision du marché nous amène une modifier nos idées (donc modifier quelques stories, ou en ajouter d'autres, ou en enlever d'autres) il faut pouvoir rapidement dire "et bien avec ce changement, c'est plus 6 mois, c'est 9" même si l'estimation est grossière. c'est pourquoi a mon avis, il faut pouvoir faire une première estimation dès qu'une nouvelle "idée" arrive.

Bref... on va bien trouver une solution. Merci pour votre apport.

[rad_hass]

Bonjour,

Il y a une pratique qui consiste à planifier des releases.
Une release a de préférence une durée fixe (pour pouvoir donner un rythme et cadencer les sprints), on peut l'estimer par exemple à environ 3 mois. Elle peut contenir environ 4 sprints de 3 semaines...

Si la vision du projets et identifier à long termes, une planification de plusieurs releases peut être envisager (imaginant que ça soit un travaille à faire pendant le sprint 0).
Ensuite, à chaque Sprint il faut mettre à jour le plan de release (ou des releases).

Tu peux trouver plus d'infos ici :
http://www.energizedwork.com/weblog/...-planning.html
http://www.agile-software-developmen...-planning.html
http://scrumcoaching.wordpress.com/2...ng-with-scrum/
http://www.versionone.com/Agile101/Release_Planning.asp

[Biosox]

Hello,
ce sont des lectures très interessantes.
En fait on est en train de mettre en place un release planning, mais on s'était pas aperçu que c'était un "release planning"

merci