Le raffinement du backlog de produit (PBR) est le processus continu d'amélioration de la liste des travaux (logiciels) à effectuer. Le PBR est la pierre angulaire pour décider de ce qui doit être fait et dans quel ordre. Dans cet article, nous décrivons les principales activités d'affinement du backlog produit et comment elles peuvent être accélérées avec l'analyseur intelligent des exigences de ScopeMaster®.
Affinement du backlog produit
Le Product Backlog Refinement est l'activité régulière menée par la plupart ou la totalité de l'équipe lors d'une réunion dans le but de préparer les activités pour la ou les itérations à venir. Les activités clés sont :
- Clarifier les user stories, afin que l’équipe en ait une compréhension commune.
- Diviser les histoires qui sont trop volumineux pour tenir dans une itération.
- Créer de nouvelles user stories et en supprimer d'autres selon de nouvelles connaissances.
- Attribution d'un deviss aux histoires
- Attribution des priorités aux histoires
L'affinement du backlog produit est une activité très longue et coûteuse, consommant généralement 5 à 151 TP3T du temps de travail total des équipes. Pourtant, c’est absolument essentiel car c’est l’étape clé pour garantir que l’équipe travaille sur les bonnes choses. Si l’on n’y consacre pas suffisamment de temps, l’équipe perdra du temps sur de mauvaises activités, ce qui peut être encore plus coûteux.
Examinons chacune de ces activités PBR un peu plus en détail et voyons comment l'automatisation peut aider.
Que se passe-t-il dans le backlog produit ?
Un backlog de produit contient généralement des user stories (qui décrivent les fonctionnalités), des epics à haute granularité et des user stories plus détaillées. Le backlog du produit doit exclure d'autres tâches qui peuvent être impliquées mais qui ne fournissent pas directement les fonctionnalités de l'utilisateur.
Activités de raffinement du backlog :
1. Clarifier les user stories
La langue anglaise est extrêmement flexible. Nous avons de nombreux mots alternatifs pour la même chose. Nous pouvons changer l’ordre des mots pour en modifier le sens et changer la façon dont l’histoire sera interprétée. Les variations sont presque infinies, même une user story de 12 mots comporte 87 milliards de permutations dans l'ordre des mots. Avec chaque variation, l’interprétation du lecteur sera probablement légèrement différente. Et même dans ce cas, l’interprétation que fait chaque individu d’une user story dépend de son propre vocabulaire et de ses capacités linguistiques. Il est plus que probable que deux personnes lisant une user story auront des interprétations différentes.
Si les membres de l’équipe ne partagent pas une compréhension commune d’un élément du backlog, il est probable que ceux qui y travailleront par la suite perdront du temps à construire/tester la mauvaise chose. Une compréhension cohérente de la part de toute l’équipe est donc essentielle pour minimiser les efforts inutiles.
Selon scrum.org « En général, un élément du Product Backlog passe par trois réunions de perfectionnement avant d'être considéré comme étant prêt. » Pour rendre cette discussion fructueuse, plus la qualité de l'histoire entrant dans la réunion est bonne, moins de temps sera perdu.
La majorité des éléments du backlog décrivent l'intention fonctionnelle, le OMS et Quoi de la user story. C'est là que ScopeMaster peut éliminer complètement toute ambiguïté en une fraction du temps, éliminant ainsi les longues discussions.
2. Diviser les histoires pour les intégrer dans un sprint
Les user stories agiles doivent être complétées en une seule itération ou sprint (généralement deux semaines). La réalisation d’une seule histoire ne devrait pas s’étendre sur deux sprints. L'achèvement doit également inclure tous les tests unitaires. Si une histoire est trop volumineuse, elle doit être divisée en petits morceaux. En règle générale, un développeur sera capable de créer (y compris les tests unitaires) environ 8 points de fonction COSMIC (CFP) par sprint. Cette estimation de la productivité individuelle varie considérablement, mais si une seule histoire dépasse 8 CFP, elle doit soit être partagée entre plusieurs membres de l'équipe et/ou divisée en « bouchées » plus petites, chacune pouvant être complétée au cours d'un sprint/itération.
La capacité de ScopeMaster à détecter la taille fonctionnelle lui donne une estimation immédiate de savoir si une histoire doit être divisée.
3. Créer de nouvelles user stories et en supprimer d’autres
Les équipes logicielles doivent s’adapter aux demandes changeantes de l’entreprise. Lors du raffinement du backlog, il sera nécessaire de diviser certaines histoires, d'en créer de nouvelles et d'en supprimer d'autres. Cela garantit que le travail effectué cible le besoin commercial tel qu’il est actuellement connu. Créer de nouvelles histoires pour répondre à des demandes changeantes est une bonne chose, mais le changement doit être limité autant que possible, car des niveaux de changement excessifs perturbent l'équipe. De nombreuses « inconnues » sont en fait « connaissables ». Les changements devraient être limités aux choses qui étaient initialement inconnaissables. Dans la mesure du possible, il est utile d'anticiper les besoins globaux le plus tôt possible. Cela permet de planifier le travail de l'équipe le plus efficacement possible.
La capacité de ScopeMaster à analyser un ensemble de user stories à la recherche de fonctionnalités manquantes ou en double permet à l'équipe de mieux comprendre la portée globale beaucoup plus tôt.
4. Affectation d'estimations aux histoires
L'estimation des histoires est peut-être l'un des aspects les plus chronophages de l'affinement du backlog produit. Cela implique généralement de jouer à des jeux de « story poker » dans lesquels les membres de l’équipe devinent l’effort requis pour raconter l’histoire sous forme de t-shirts ou plus tard sous forme de points d’histoire (arbitraires). Non seulement cela prend du temps, mais c'est fastidieux, subjectif, incohérent et peu utile pour la gestion de projet, en particulier sur un projet à grande échelle. De plus, les estimations de points d’histoire sont généralement « jouées » pour atteindre un résultat particulier.
La capacité de ScopeMaster à estimer instantanément la taille fonctionnelle des user stories (en points de fonction COSMIC) signifie que l'équipe doit passer très peu de temps lors des réunions à discuter de la taille de l'histoire. La taille fonctionnelle de l’histoire raffinée est une valeur cohérente, standardisée et immuable. Cela libère du temps à l'équipe pour discuter des meilleures façons de comment pour livrer l’histoire le plus efficacement possible.
5. Attribuer des priorités aux histoires
La priorisation des histoires est une conséquence de leur importance pour l'entreprise, des autres histoires dont elles dépendent et des efforts qu'elles nécessiteront pour les livrer. Si les autres activités de raffinement du backlog ont déjà été partiellement ou en grande partie automatisées, l'équipe peut consacrer plus de temps à en discuter lors des réunions de raffinement du backlog. Cela contribuera à garantir que l'équipe fait le le plus important les choses dans le bon ordre.
