Sharepoint pour le backlog

Avec l'utilisation des listes

Un backlog de produit peut se concrétiser sous différentes formes. Dans les différents projets auxquels j’ai participé, j’ai utilisé :

  • des fiches bristol épinglées sur un tableau
  • une feuille de calcul d’un tableur OpenOffice ou Excel
  • une feuille de calcul partagée avec GoogleDocs, ce qui est déjà beaucoup mieux qu’un simple tableur
  • un outil dédié, IceScrum bien sûr, ce qui est encore mieux

Mon client actuel utilise SharePoint pour les sites d’équipe, c’est à dire que SharePoint sert de référentiel pour tous les documents produits pendant le développement. Comme toute l’équipe n’est pas dans le même bâtiment, la solution de fiches pour le backlog de produit n’est pas suffisante. Et pas question d’utiliser GoogleDocs ou IceScrum pour le moment.

J’ai donc commencé par élaborer le backlog de produit avec Excel, le fichier produit étant mis dans un dossier du site d’équipe. Puis j’ai découvert la gestion des listes avec SharePoint. On peut créer facilement ses propres listes en définissant les attributs (colonnes) souhaités. Et un backlog n’est rien d’autre qu’une liste de éléments (une liste de user stories). L’avantage par rapport à une feuille de calcul Excel est que la liste est visible sur le portail sans qu’il soit nécessaire d’ouvrir un fichier. Cela facilite grandement le travail collaboratif. De plus SharePoint offre des facilités pour gérer les listes : on peut trier très facilement sur n’importe quelle colonne et surtout créer des vues qui ne montrent que l’information souhaitée.

Pour le backlog de produit, j’ai défini les colonnes suivantes pour chaque élément :

  • un identifiant (géré automatiquement pas SharePoint)
  • un nom court
  • une description générale, là où on écrit la story avec la formulation “en tant que <rôle> je peux afin de "
  • le thème, qui permet de classer les stories selon un domaine fonctionnel
  • l'état de l’élément, à choisir parmi : créé, estimé, prêt, en cours, à tester, fini
  • une estimation de coût, obtenue après une séance de planning poker
  • le type précisant s’il s’agit d’une story, d’une exigence non fonctionnelle ou d’un bug
  • la liste des cas de tests associés
  • le sprint dans laquelle la story est planifiée

C’est déjà pas mal et on peut facilement adapter la liste en modifiant les valeurs possibles pour chaque champ, en définissant ce qui est obligatoire et ce qui est optionnel ou en ajoutant une nouvelle colonne.

J’ai créé des vues pour montrer la liste des éléments dans chaque état : ce qui est fini, ce qui est en cours, ce qui reste à estimer… On peut demander à SharePoint d’afficher le total des éléments présents dans chaque vue, ce qui facilite les mesures faites à la fin de chaque sprint.

Finalement, SharePoint pour le backlog de produit c’est pas si mal[1]. J’utilise aussi ces listes personnalisables pour la liste des problèmes et pour la gestion des risques. Pour le backlog de sprint nous préférons la solution des notes collantes affichées au mur, c’est plus adapté à une gestion au quotidien.

Notes

[1] mais ce n’est pas l’idéal, notamment pour la gestion des priorités, pour la production des burndown charts… et ce n’est pas du tout Web2.0 comme IceScrum

Voir aussi :