Discussion :

[randriano]

Bonjour,

Nous sommes entrain de mettre en œuvre la méthode Scrum pour gérer nos projets. Le product backlog est à remplir par le ou les product owners. Les "features" ou "stories" contenus dans ce backlog sont souvent des termes très vagues ou bien très utilisateurs.

Le rôle du SM (Scrum Master) n'est-il pas de découper ces éléments de backlog en "Sprint Backlog"? En des termes plus développeurs?

Enfin, une fois le sprint backlog établi vient l'établissement du sprint planning. C'est encore bien sûr le rôle du SM! Mais faut-il obligatoirement un "meeting" ou est-ce que le SM peut l'établir tout seul?

[maparè]

Bonjour,

Nous sommes entrain de mettre en œuvre la méthode Scrum pour gérer nos projets. Le product backlog est à remplir par le ou les product owners. Les "features" ou "stories" contenus dans ce backlog sont souvent des termes très vagues ou bien très utilisateurs.

Le rôle du SM (Scrum Master) n'est-il pas de découper ces éléments de backlog en "Sprint Backlog"? En des termes plus développeurs?

Enfin, une fois le sprint backlog établi vient l'établissement du sprint planning. C'est encore bien sûr le rôle du SM! Mais faut-il obligatoirement un "meeting" ou est-ce que le SM peut l'établir tout seul?

Si vous utilisez la méthode Scrum, normalement avant chaque Sprint vous devez faire un Planning poker : une Séance d'estimation menée par l'équipe de
développement qui évalue l`ensemble de l'effort nécessaire pour traiter les user stories du backlog.

Les stories sont présentées par le produit Owner à l`ensemble de l`équipe, une présentation leur permettant de mieux comprendre les différentes stories.
Après quoi les développeurs utilisent des post-its pour diviser chaque story (estimée en effort = points, selon sa complexité) en des taches; et pour chaque tache donner son estimation en temps de développement.

Le choix revient au développeur ayant choisi une story de découper celle-ci en des taches. C`est le ScrumMaster qui alimente le sprint encours en se servant du Backlog
et cela en fonction des priorités définies par le Produit Owner.

Est-ce votre ScrumMaster est un ex-développeur ?? Si oui il peut bien contribuer au découpage des stories en des taches et à l`estimation de temps de développement.

**si vous avez un/une analyste au sein de l`équipe, c`est lui/elle qui va collaborer avec le produit owner pour préparer les stroies du Backlog, faire le nécessaire pour mieux les expliquer(bien détailler)**

N`oubliez pas qu`une équipe Agile(Scrum) est une équipe qui s`autogere.

[randriano]

Pour le planning poker, nous on le fait au tout début du projet et c'est tout car il s'agit d'un projet forfaitaire avec un cahier de charges.

Prenons un exemple d'un projet d'une durée estimée à 3 mois, tous les user stories ont été déterminées durant la réponse à l'appel d'offres du projet, les stories ont juste été peaufinées et détaillées au début de la production. Là le PO n'a donc plus de boulot!
Est-ce une manière correcte de procéder en Scrum?
Oui notre Scrum Master est un ex développeur donc c'est principalement lui qui découpe les stories en taches informatiques.

Autre question, en Scrum, est-ce qu'il y a moyen de mesurer la productivité de chaque développeur?

[maparè]

Pour le planning poker, nous on le fait au tout début du projet et c'est tout car il s'agit d'un projet forfaitaire avec un cahier de charges.

Prenons un exemple d'un projet d'une durée estimée à 3 mois, tous les user stories ont été déterminées durant la réponse à l'appel d'offres du projet, les stories ont juste été peaufinées et détaillées au début de la production. Là le PO n'a donc plus de boulot!
Est-ce une manière correcte de procéder en Scrum?
Oui notre Scrum Master est un ex développeur donc c'est principalement lui qui découpe les stories en taches informatiques.

Autre question, en Scrum, est-ce qu'il y a moyen de mesurer la productivité de chaque développeur?

1) Lorsqu’on se lance dans le développement agile, une des premières questions à laquelle il faut répondre concerne la durée des sprints. Cette durée est fixée en accord avec le client. Actuellement ceux qui utilisent le développement avec Scrum fixent en général une durée de deux à trois semaines par Sprint. Pour chaque Sprint on fixe le nombre de points à développer.

2) Avant chaque Sprint il y’a le Sprint planning (Sprint poker) qui se déroule comme suit : Le PO se sert du Backlog(dans lequel les stories sont classées par lui selon ses priorités) pour présenter celles qu’il souhaite le développement pour le sprint à commencer. Après sa présentation, on attribue un nombre de points à chaque Story jusqu’à atteindre le nombre de points prévus pour ce Sprint. Chaque développeur choisit ses stories à développer puis la découpe en des taches, à chaque tache on attribue une durée de développement(en heures). Ce qui permettra de donner un nombre d’heures de développement pour l’ensemble des stories.

3) On peut se servir d’un tableau pour le suivi. Ce tableau sera divisé en 3 colonnes : une pour les taches à faire, une pour les taches en cours et une autre pour les taches finies. Le développeur prend une tache de la colonne à faire puis la met dans la colonne encours, une fois cette tache achevée il la met dans la colonne finie. La productivité de chaque développeur est bien visible à ce niveau. NB : L’outil ICECRUM est très bien pour ça, voir lien http://www.icescrum.org/download/

4) Le Daily Meeting ou Daily Scrum
Le daily Meeting est une réunion quotidienne qui ne doit pas excéder 15 minutes, elle sert à donner la parole à chaque membre de l’équipe pour exprimer leur situation.
Pour cela chaque membre doit répondre à trois questions :
a) Ce qu’il a fait la veille ?
b) ce qu’il va faire aujourd’hui ?
c) les éventuels problèmes rencontrés ?

5) Le Sprint Review ou Démo/Rétro
La fin du sprint est accompagnée d’une dernière réunion, la réunion Sprint Review.Cette réunion ce déroule en deux temps.
Dans un premier temps l’équipe de Dev présente ce qui à été fait pendant
le sprint et le PO valide et ferme des user stories. Mais s'il n'est pas OK pour
une story alors celle-ci ne sera pas fermée.Ce qui veut dire qu'on a pas
atteint le nombre de points à développer = objectif du Sprint pas atteint.
Dans un second temps, se déroule la « rétro ». Véritable rétrospective du sprint, cette réunion demande la participation de tous les membres de l’équipe. Elle a pour but d’identifier les points noirs du sprint passé afin de ne pas les reproduire lors du prochain sprint. Chaque participant écrit ce qu’il a « aimé » et « pas aimé » ou ce qui, d’après lui, aurait pu être évité. Cette réunion a vraiment pour but d’améliorer le prochain sprint et non pas de pointer du doigt une personne en particulier. Elle ne doit pas servir à juger, mais à s’améliorer.

[randriano]

Merci pour cette belle explication maparè! Là le SM ne sert qu'à diriger les meetings, un facilitateur comme Wikipédia le dit!

A quand le traçage des charts est utile?
Est-ce que l'on peut appeler le Scrum Master de "cadenceur"?

[Drawingrom]

Pour le planning poker, nous on le fait au tout début du projet et c'est tout car il s'agit d'un projet forfaitaire avec un cahier de charges.

Prenons un exemple d'un projet d'une durée estimée à 3 mois, tous les user stories ont été déterminées durant la réponse à l'appel d'offres du projet, les stories ont juste été peaufinées et détaillées au début de la production. Là le PO n'a donc plus de boulot!
Est-ce une manière correcte de procéder en Scrum?

Non, ce n'est pas du scrum. Qu'y a-t-il d'agile dans votre projet si tout est pré défini avant le lancement ? Comment intégrez-vous les retours du client ?

[randriano]

Les retours clients sont intégrés au fur et à mesure. Dans l'outil IceScrum, les retours clients sont insérés par le PO dans le bac à sable d'abord, ensuite dans le backlog, et c'est à la fin au SM (ou bien à travers un sprint planning meeting) de planifier les sprints à mettre ces retours.

Pour info, on travaille sur des projets forfait: le projet est estimé en totalité avant sa réalisation, sinon le client ne paiera rien.

Je rectifie alors ce que j'ai dit, au lancement du projet le PO n'a de boulot que lors des Sprint Review et lorsqu'il y a des retours clients (les bugs en général).

[maparè]

Merci pour cette belle explication maparè! Là le SM ne sert qu'à diriger les meetings, un facilitateur comme Wikipédia le dit!

A quand le traçage des charts est utile?
Est-ce que l'on peut appeler le Scrum Master de "cadenceur"?

Un ScrumMaster ne sert pas seulement à diriger les meetings.
Dans un projet agile il arrive des imprévus, des demandes pour des tâches urgentes. Il
doit controler la façon de gérer tout ça pour éviter que l'équipe soit pertubée. C'est lui le garant
de l'application de la méthode au sein de l'équipe, sous entendu qu'il connait bien Scrum.

Dans un projet de forte demande pourquoi pas confier aussi au ScrumMaster(EX développeur) des taches comme :

- faire des builds "quotidiens" pour le QA
- préparer un environnement de démo à la demande d'un commercial pour un futur client
- Préparer la démo pour le sprint review(en collaboration avec le QA)

Le Burdown Chart( à la fin de chaque Scrum meeting), il serait préférable que chaque développeur mette ses taches à jour avant le scrum meeting, mettre une tache finie dans la colonne finie. Avec Iscrum la courbe s'ajuste
en conséquence.

Le Burnup Chart(à la fin de chaque sprint)

[randriano]

Ou par manque de ressource, le Scrum Master fera une partie du travail de QA?

En fait, le PO estime une story en points, mais a-t-il la connaissance technique pour évaluer cela?
Par curiosité:
Pour le découpage des stories en tâches, les tâches sont à évaluer en heures ou en jours dans vos projets? En fait pour moi, si un jour correspond à 8h de travail par exemple, 1 semaine = 5j et 1 sprint = 2 semaines, 1 sprint vaut donc 8x5x2 = 80 heures, alors je ne prennes que les stories avec le total des tâches compris dans ce 80h.
Lorsque les stories d'un sprint ne sont pas terminées dans le délai imparti (2 semaines pour nous), que fait-on? Car quelque fois, nous on déplace certaines stories dans le sprint suivant et augmenter la cadence pour ce sprint suivant. Ce n'est que des fois que l'on laisse dépasser le délai et s'attendre à un burndown chart catastrophique.

[maparè]

Ou par manque de ressource, le Scrum Master fera une partie du travail de QA?

En fait, le PO estime une story en points, mais a-t-il la connaissance technique pour évaluer cela?
Par curiosité:
Pour le découpage des stories en tâches, les tâches sont à évaluer en heures ou en jours dans vos projets? En fait pour moi, si un jour correspond à 8h de travail par exemple, 1 semaine = 5j et 1 sprint = 2 semaines, 1 sprint vaut donc 8x5x2 = 80 heures, alors je ne prennes que les stories avec le total des tâches compris dans ce 80h.
Lorsque les stories d'un sprint ne sont pas terminées dans le délai imparti (2 semaines pour nous), que fait-on? Car quelque fois, nous on déplace certaines stories dans le sprint suivant et augmenter la cadence pour ce sprint suivant. Ce n'est que des fois que l'on laisse dépasser le délai et s'attendre à un burndown chart catastrophique.

** Coopérer, s'adapter font partie des comprtements indispensables dans un projet Agile. c’est courant de voir des développeurs et un testeur ou deux travailler ensemble pour s’assurer qu'une story a été correctement réalisée. Si, le ScrumMaster peut aussi aider le testeur.
- Est-ce que votre PO, vient au moins une fois dans la semaine dans votre local agile, hors mis le jour du Sprint Review? Si oui, il fait quoi pendant sa présence?

** Meme si le PO a les connaissances techniques, c'est au dev de faire une proposition de points pour chaque story. Si c'est raisonnable le PO accepte et valide, sinon il faudra expliquer la complexité de celle-ci pour lui convaincre.

** Une fois le délai du Sprint fixé,le plus important pour le PO sera le nombre de points pour celui-ci. Le découpage des stories en points est la vision du PO

** Le Po peut changer d'idée sur le fonctionnement d'une Story , aussi on ne peut jamais prévoir qu'une story
peut fonctionner sans bug.c'est des exemples de facteurs qui peuvent influencer le temps de développement d'une story.
Le découpage des taches en heures est une vision dév, une estimation nécessaire mais pas exacte comme une équation mathématique.

** Lorsque les stories d'un sprint ne sont pas terminées dans le délai imparti ou lorsque le PO n'est pas satisfait d'une story développée, il 'y a pas de choix que de les repousser au Sprint suivant. C'est là que la rétro trouve sa place( l'autocritique ), afin de trouver un plan d'action pour mieux faire au sprint suivant.

[randriano]

** Le Po peut changer d'idée sur le fonctionnement d'une Story , aussi on ne peut jamais prévoir qu'une story
peut fonctionner sans bug.c'est des exemples de facteurs qui peuvent influencer le temps de développement d'une story.
Le découpage des taches en heures est une vision dév, une estimation nécessaire mais pas exacte comme une équation mathématique.

** Lorsque les stories d'un sprint ne sont pas terminées dans le délai imparti ou lorsque le PO n'est pas satisfait d'une story développée, il 'y a pas de choix que de les repousser au Sprint suivant. C'est là que la rétro trouve sa place( l'autocritique ), afin de trouver un plan d'action pour mieux faire au sprint suivant.

Un sprint de 2 semaines reste donc à 2 semaines, c'est ça? On déplace juste les tâches non finies dans le sprint suivant?

Comment les PO affectent des points à chaque story: selon l'importance du story ou la priorité du story ou bien la durée de réalisation du story?

[maparè]

Un sprint de 2 semaines reste donc à 2 semaines, c'est ça? On déplace juste les tâches non finies dans le sprint suivant?

Comment les PO affectent des points à chaque story: selon l'importance du story ou la priorité du story ou bien la durée de réalisation du story?

** Dans les conditions normales, la durée du Sprint doit etre respectée. Une story est finie quand elle est validée par le PO.
Oui, c`est de repousser les stories non finies ou non satisfaisantes au sprint suivant.
Mais on doit comprendre que le nombre de points à réaliser par Sprint est un engagement face au client.

** Le PO classe les stories dans le Backlog par priorité. C`est sur cette priorité qu`on se base pour choisir les stories du Sprint à venir.

** Une story peut etre grande mais non complexe, petite mais complexe ou simplement facile; c`est ce qui permet au Dev d`estimer sa durée
de réalisation et faire une proposition de points à affecter à la story. Et le PO se base sur Ça pour donner son OK.

[SumsForever]

** Dans les conditions normales, la durée du Sprint doit etre respectée. Une story est finie quand elle est validée par le PO.
Oui, c`est de repousser les stories non finies ou non satisfaisantes au sprint suivant.
Mais on doit comprendre que le nombre de points à réaliser par Sprint est un engagement face au client.

** Le PO classe les stories dans le Backlog par priorité. C`est sur cette priorité qu`on se base pour choisir les stories du Sprint à venir.

** Une story peut etre grande mais non complexe, petite mais complexe ou simplement facile; c`est ce qui permet au Dev d`estimer sa durée
de réalisation et faire une proposition de points à affecter à la story. Et le PO se base sur Ça pour donner son OK.

Nous implémentons Scrum et il y a plusieurs points pas très clairs.
* Le PO classe son product backlog par priorité ok, en fonction de ses intérêts mais également en fonction des story points j'imagine (complexité d'une tache), il priorisera certainement une tache de faible complexité qui lui rapporte.
Là ou je ne comprends plus est que une tache de complexité 1 comme tu le dit peut-etre grande, en gros une fois découpée en tache elle peut faire 10h une autre de complexité 1 peu faire 1h. Du coup ce n'est pas le meme impact pour le PO hors il ne perçoit que le backlog avec les valeurs en story point.

Idem pour la vélocité, si une équipe fait 10 points par sprint, cela peut representer 100h de travail (si la tache de 1point = 10h) mais aussi bien 10h (si la tache de 1point = 1h).
Nous assignons les story aux développeurs (au sprint meeting) et nous nous rendons compte comme tu dis qu'une fois que le développeur découpe en taches (étage d'après), la story simple fait bcp d'heures et du coup que le travail pour le développeur est > 80h (8h * 10jours) (Hors nous nous étions déja engagé sur cette story de 1point au sprint meeting).

* Second obstacle, si nous utilisons le planning poker avec l'équipe entière afin d'estimer les stories (en points de complexité), on arrive donc à un consensus. Hors si j'ai bien compris c'est le développeur lui-même qui va découper et estimer les sous-tâches. Comment être sur qu'il ne va pas gonfler les estimations des sous-taches et que sa vision (compréhension) est bonne ?

merci

[Bruno Orsier]

@SumsForever

Peut-être il est utile de revoir dans quel ordre faire les différents activités. Voici ce que nous pratiquons sur plusieurs équipes Scrum (et recommandons à des clients) :

- entretien du backlog : cela se fait en cours de sprint, afin de préparer le travail pour les sprints suivants (par exemple pour avoir 1 à 3 sprints bien définis). Cela comprend la clarification des users stories (les critères notamment), et l'estimation par l'équipe, avec par exemple le poker planning. A ce stade il n'est normalement pas nécessaire de découper finement en tâches, vu qu'on estime en points, relativement à des stories de référence.

- le démarrage du sprint, avec deux réunions successives:
a. identification du contenu souhaité pour le sprint qui démarre.
b. découpage en tâches (par l'équipe, pas par un seul développeur). Les tâches sont estimées en heures dans cette réunion. A ce stade on peut s'apercevoir que le travail à faire ne tiendra pas dans le sprint ; c'est normal et prévu dans Scrum - on rediscute alors avec le Product Owner.

J'insiste sur le travail d'entretien du backlog à faire avant le démarrage, il est souvent vital pour que les réunions de démarrage se passent bien. Sinon il faut le faire en même temps que le démarrage, et tout devient très compliqué. C'est un travail d'équipe, il faut le prévoir (autour de 1/2 journée par sprint par exemple, plus ou moins selon l'expérience de l'équipe).

[SumsForever]

@SumsForever

- le démarrage du sprint, avec deux réunions successives:
a. identification du contenu souhaité pour le sprint qui démarre.
b. découpage en tâches (par l'équipe, pas par un seul développeur). Les tâches sont estimées en heures dans cette réunion. A ce stade on peut s'apercevoir que le travail à faire ne tiendra pas dans le sprint ; c'est normal et prévu dans Scrum - on rediscute alors avec le Product Owner.

*Cela veut-il dire que qu'un Sprint meeting se découpe en ces 2 étapes? ou bien que le découpage des taches est un meeting a part qui vient aprés la sélection des items et qui se fait sans le PO (car le PO s'en fou un peu du passage decoupage en sous-taches) (et ds le cas d'un dépassement de travail on revient vers le PO, avec un second Sprint meeting?)

*Puis l'étape suivante du process, est-ce bien l'assignement des taches a l'équipe. On fait 'un autre meeting' de 1h ou les développeurs choisissent les taches qu'ils ont envie de faire parmi ttes celles du sprint afin que chacun est son quota d'heure pour toute la duree du sprint.

* Est-ce correct de faire des sprints de 8j (1 semaine + 3j) et de conserver les 2 autres jours de la seconde semaine a, la sprint review (4h), la retrospective, l'entretien du backlog, et le sprint meeting 2. Car dans l'idee j'aimerai commencer et terminer un sprint toujours au meme date

[Bruno Orsier]

*Cela veut-il dire que qu'un Sprint meeting se découpe en ces 2 étapes? ou bien que le découpage des taches est un meeting a part qui vient aprés la sélection des items et qui se fait sans le PO (car le PO s'en fou un peu du passage decoupage en sous-taches) (et ds le cas d'un dépassement de travail on revient vers le PO, avec un second Sprint meeting?)

En effet, 2 étapes, le PO ne participe pas en général à la deuxième, par contre il doit être disponible en fin de 2ème étape, car le découpage en tâches génère au minimum des questions supplémentaires au PO, et parfois la nécessité de négocier avec lui si le découpage fait apparaître que le travail ne tient pas dans le sprint.

*Puis l'étape suivante du process, est-ce bien l'assignement des taches a l'équipe. On fait 'un autre meeting' de 1h ou les développeurs choisissent les taches qu'ils ont envie de faire parmi ttes celles du sprint afin que chacun est son quota d'heure pour toute la duree du sprint.

Scrum ne fait pas de recommendation particulière à ce niveau, c'est l'équipe qui est supposée s'auto-organiser pour se répartir le travail. Donc vous pouvez en effet essayer un meeting de 1H pour décider de comment s'organiser. Les équipes que je connais n'ont en général pas besoin d'un tel meeting formel, les daily meetings suffisent. Mais elles pratiquent Scrum depuis plusieurs années.

* Est-ce correct de faire des sprints de 8j (1 semaine + 3j) et de conserver les 2 autres jours de la seconde semaine a, la sprint review (4h), la retrospective, l'entretien du backlog, et le sprint meeting 2. Car dans l'idee j'aimerai commencer et terminer un sprint toujours au meme date

Oui c'est correct. Attention de bien séparer toutes ces activités pour ne pas créer de confusion. Ne pas confondre l'entretien du backlog (doit être très focalisé sur les besoins utilisateurs) et le découpage en tâches par exemple.

2 jours complets pour ces activités c'est peut-être trop car il s'agit de sprints assez courts (l'intérêt est que tous les meetings sont eux aussi plus courts - quand Scrum mentionne des meetings de 4H c'est pour des sprints de 4 semaines).

S'il reste du temps sur ces deux jours, ça peut être bien de le consacrer à de l'auto-formation, ou a traiter les actions venant de la rétrospective...

[Drizzt [Drone38]]

* Est-ce correct de faire des sprints de 8j (1 semaine + 3j) et de conserver les 2 autres jours de la seconde semaine a, la sprint review (4h), la retrospective, l'entretien du backlog, et le sprint meeting 2. Car dans l'idee j'aimerai commencer et terminer un sprint toujours au meme date

C'est très court comme sprint.
Il ne faut pas oublier qu'un sprint ça peut être assez éprouvant pour les équipes. En général plus que via un cycle de développement plus classique.
A chaque sprint tu as une livraison, démo ... En 8j tu n'as pas forcément le temps de faire grand chose (faut caler les TI aussi).

Et en terme de renta si tous les 8j tu perds 1 à 2j en review & co, ça coute vite cher.

En tout cas si tu restes sur ce rythme il faut prévoir une période off de temps à autre pour faire redescendre la pression sur l'équipe.