Scrum avec plusieurs équipes

Vous avez plusieurs équipes qui font du Scrum et vous voulez garder une vue générale, plutôt que d'avoir des projets séparés. Voilà une façon simple de faire du "scrum de scrums".

Equipes et Features

Constituez les équipes et associez à chacune une couleur. Identifiez les features, éventuellement à partir d'une vision. Rangez-les par priorité. Montrez quelle équipe va réaliser la feature en lui donnant sa couleur. Le "backlog" de features donne un aperçu du partage entre les équipes à haut niveau :

Features

Dans notre exemple, il y a 2 équipes, la rouge et la verte; les features sont associées à chaque équipe dans l'ordre des priorités; la feature en bleu sera associée plus tard.

Backlog

Chaque équipe décompose ses features en stories, puis estime l'effort nécessaire pour les développer.

Backlog

Les stories apparaissent dans le backlog (de produit), la couleur permet de savoir à quelle équipe elles appartiennent.

Plan de release

Dans chaque sprint, chaque équipe aura des stories candidates en fonction de sa capacité.

Plan de release

L'équipe verte a une capacité de 5 points et la rouge de 4.

Sprint

Les sprints de chaque équipe sont synchronisés, c'est à dire qu'ils commencent et finissent en même temps. Si les équipes sont de petite taille, on peut éventuellement utiliser un seul tableau :

Tableau de sprint

Mais dans la plupart des cas chaque équipe possèdera son propre tableau pour suivre son sprint et la réalisation des tâches.

Commentaires

1. Le mardi 03 mai 2011, 17:04 par Cédric

Bonjour Claude,
Merci pour ce billet !
J'ai du mal à cerner comment fonctionne cette implémentation dans le détail: les deux équipes estiment l'ensemble des features avant de s'engager sur une partie d'entre elles seulement ? En général, on n'estime pas les features, seulement les stories. auquel cas le nombre de personnes alors engagé peut être pénalisant (chronophage) et les estimations pourraient être biaisées : l'estimation faite par les équipes 1 et 2 ne correspondrait ni à l'estimation de l'équipe 1, ni à celle de l'équipe 2, or une seule implémentera la feature. Sinon, les estimations sont-elles faites après affectation? Oui, on revient à une approche habituelle, ce sont ceux qui réalisent les stories qui les estiment. auquel cas je ne vois pas l'intérêt d'avoir un seul backlog puisque le contenu peut en être revu à chaque itération. Un seul backlog où on différencie les équipes, cela est équivalent à un backlog par équipe. De plus le fait qu'on affecte des tâches à une équipe plutôt qu'à une autre peut aller à l'encontre de la philosophie de l'engagement de l'équipe. euh non, C'est l'équipe qui décompose la feature en stories, qui identifie ses tâches pour chacune de ses stories et qui, à partir de là, s'engage sur le contenu d'un sprint. Ou est-ce que j'ai tout faux ?