Comment faire un Product Backlog

Publié le par

Le backlog de produit  est le cœur de Scrum. C’est à dire là ou tout commence. Il s’agit d’une liste priorisée d’exigences, des choses que le client veut, décrites selon la terminologie du client.

Les exigences incluent les champs suivant :

  • ID : un identifiant unique, un nombre auto-incrémenté. Cela évite de perdre la trace des éléments du backlog quand on les renomme.
  • Nom : Un nom, une description courte de l’exigence. Par exemple   » Voir l’histoire de ses transactions ». Suffisamment claire pour que les développeurs et le Product Owner comprennent approximativement de quoi ils parlent
  • Importance : l’importance attribuée par le Product Owner à cette exigence.
  • Estimation Initial : l’évaluation initiale de l’équipe sur la quantité de travail qui est nécessaire pour implémenter cette exigence par rapport aux autres exigences.
    • Demandez à l’équipe  » si vous pouvez prendre le nombre optimal de personnes pour cette exigence et que vous vous enfermez dans une salle et que vous travaillez sans jamais être dérangé, après combien de jours sortiriez-vous avec une implémentation finie, testée et livrable ? « . Si la réponse est  » avec 3 gars enfermés dans une salle ça prendrait approximativement 4 jours  » alors l’estimation initiale est de 12 points.
    • Le point important n’est pas obtenir des estimations absolues correctes (i.e que 2 points devraient prendre 2 jours), le point important est d’avoir des estimations relatives correctes (i.e que 2 points de valeur devraient nécessiter à peu près la moitié du travail de 4 points.
  • Comment le démontrer : une description succincte comment cette histoire sera démontrée à la démo de fin d’itération.
  • Notes : n’importe quelle autre info, des clarifications, des références aux autres sources d’info, etc

Parfois il est demandé d’utiliser d’autres champs supplémentaires dans le Product Owner

  • Catégorie : un classement approximatif, « back office » , »performance » , etc. De cette façon le Product Owner peu facilement filtrer et affecter des priorités basses
  • Composant : par exemple  » base de données », « serveur », …..
  • Demandeur : Pour garder une trace de quel client ou quelle partie prenante avait demandé cet élément à l’origine.
  • ID de suivi de bug : si vous avez un système de suivi des bogues séparé, il est utile de garder une trace de toute correspondance directe entre une exigence et un ou plusieurs bogues

 

Référence : ScrumAndXpFromTheTrenches