L’af­fi­nage du product back­log

L’af­fi­nage du product back­log appa­raît comme une étape essen­tielle dans tout projet Scrum. Il va permettre d’or­don­nan­cer fine­ment les éléments du product back­log afin de rendre la plani­fi­ca­tion de sprint la plus fluide et effi­cace possible.

Extrait de la vidéo de forma­tion : Chal­lenge Scrum Master

Dans cette vidéo, nous allons abor­der une autre acti­vité qui se situe au coeur du sprint. Il s’agit de l’affi­nage du product back­log. C’est une acti­vité primor­diale pour avoir un product back­log prêt et opti­misé en terme de valeur.

Opti­mi­ser et prépa­rer le product back­log

Dire qu’un product back­log est opti­misé et prêt, cela signi­fie avoir la tête du product back­log prépa­rée pour être enga­gée dans un sprint. Cela corres­pond géné­ra­le­ment à l’équi­valent de la vélo­cité moyenne plus 20%, c’est le mini­mum. Et idéa­le­ment, à l’équi­valent de 2 vélo­ci­tés, donc deux sprint de vélo­cité moyenne. Cela pour avoir suffi­sam­ment de matière pour pouvoir ajus­ter les éléments qui seront sélec­tion­nés au moment de la plani­fi­ca­tion.

Cela signi­fie donc des éléments décou­pés rela­ti­ve­ment fine­ment avec de pré-requis dispo­nibles. Alors, les pré-requis peuvent être diffé­rentes choses, comme par exemple :

• une déci­sion métier sur une règle de gestion
• une déci­sion juri­dique sur une fonc­tion­na­lité
• un jeu de données dont on dépend
• la créa­tion d’une nouvelle équipe de déve­lop­pe­ment sur un logi­ciel

Et si tous ces pré-requis ne sont pas là, on ne pourra pas réali­ser la fonc­tion­na­lité ou la user story dans le prochain sprint qu’on va plani­fier. Voilà ce qu’est simple­ment un product back­log prêt. Et le but de l’af­fi­nage est évidem­ment d’avoir toujours ce product back­log prêt et bien ordon­nancé, pour pouvoir déli­vrer un maxi­mum de valeurs possibles.

L’af­fi­nage du product back­log : une acti­vité sous la respon­sa­bi­lité du product owner

Tout ces travaux d’af­fi­nage se déroulent sous la respon­sa­bi­lité du product owner, qui peut être assisté par l’équipe de déve­lop­pe­ment.

En géné­ral et quoi qu’il arrive, l’équipe de déve­lop­pe­ment est contri­bu­trice sur les acti­vi­tés du product back­log. Et donc on estime que son effort moyen en terme de capa­cité à faire est égal à 10%. Clai­re­ment, c’est un temps qu’elle ne passera pas à déve­lop­per de nouvelles users stories. Donc c’est vrai­ment un temps qu’elle doit avoir provi­sionné dans chacun de ses sprints et qu’elle ne pourra pas consa­crer à d’autres tâches, celles du sprint back­log en parti­cu­lier. Autre­ment dit, sur des acti­vi­tés de déve­lop­pe­ment de l’in­cré­ment.

Quelles sont les acti­vi­tés qui se retrouvent dans l’af­fi­nage du product back­log ?

Voyons main­te­nant les diffé­rents types d’ac­ti­vi­tés que l’on retrouve dans l’affi­nage du product back­log. Cela peut être :

• ajou­ter des détails aux éléments du product back­log, les users stories en parti­cu­lier. Ce sont donc des détails qui vont permettre de prépa­rer de plus en plus la user story à l’im­plé­men­ta­tion
• des ajouts d’es­ti­ma­tion et notam­ment dans le cas d’une nouvelles idées qui arri­ve­raient en cours de route
• de l’ordon­nan­ce­ment d’élé­ments dans le product back­log pour opti­mi­ser la valeur créée à chaque sprint

Conclu­sion

Donc voilà les diffé­rentes actions que l’on peut mener dans l’af­fi­nage du product back­log sous la respon­sa­bi­lité du product owner, géné­ra­le­ment assisté par l’équipe de déve­lop­pe­ment. Préci­sons que dans le cas où le product back­log ne serait pas prêt au moment de la plani­fi­ca­tion de sprint, elle risque d’être très doulou­reuse et chao­tique. C’est en tout cas ce que j’ai pu consta­ter dans ce type de situa­tion. Plus le product back­log est préparé, plus la plani­fi­ca­tion de sprint sera fluide et effi­cace. L’équipe pourra alors se concen­trer sur la défi­ni­tion de l’objec­tif ou sur le plan à établir, plutôt que d’es­sayer encore d’af­fi­ner ou de se livrer à des esti­ma­tions manquantes. 

Mon conseil concer­nant l’af­fi­nage du product back­log, c’est d’enté­ri­ner un créneau et de le program­mer de façon récur­rente, plutôt à un rythme hebdo­ma­daire. Par exemple, vous pouvez bloquer chaque mercredi, une ou deux heures qui sont réser­vées à des acti­vi­tés d’af­fi­nage du product back­log. C’est un bon moyen de sanc­tua­ri­ser pour s’as­su­rer que cela devienne une habi­tude, pour laquelle le temps a réel­le­ment été provi­sionné.