Second billet consacré à mon activité de coach agile. Pour ceux qui n’ont jamais entendu parler des méthodes Agiles, lisez d’abord ce billet avant de poursuivre.
« Existe-il un backlog de produit (terme SCRUM pour la liste des exigences et fonctionnalités à implémenter pour disposer du produit) dont les éléments sont priorisés et estimés par l’équipe ? «
La position de Jeff Sutherland est ferme à ce sujet: aucune ambiguité, si vous ne répondez pas à ce critère, vous ne faites pas de SCRUM (méthode Agile la plus populaire).
En résumé: Pas de backlog… pas d’agilité … et pas de Projet.
Cela peut vous sembler un peu radical, et pourtant …
En effet, le backlog de produit est l’élément central de notre dispositif agile, la bible dans laquelle Product Owner (= Client XP = Directeur de produit) et Équipe vont piocher pour remplir à intervalles réguliers le backlog de sprint (qui n’est pas l’objet de ce billet) c’est à dire contenu à réaliser à chaque sprint (courte itération de quelques semaines).
Il est indissociable du Plan de Release dont mon camarade Blogeur Claude souligne remarquablement l’importance dans son dernier billet.
Contrairement aux backlogs de sprint, multiple (un pour chaque sprint), le backlog de produit est unique mais reste ouvert et évolutif. Il est sous la responsabilité du Product Owner.
Construire ce backlog n’est pas facile, et selon les produits, il faut du temps pour l’établir : toutefois cela doit rester l’objectif majeur, incontournable des quelques semaines du sprint 0.
Encore une fois, il ne s’agit pas de spécifications détaillées, et le recueil des besoins, les études utilisateurs ou autre analyse de Kano qui vont servir à l’établir peuvent être menées, soit dans ce sprint 0, soit en amont, soit en parallèle.
Etablir le backlog de produit en Sprint 0 est donc primordial mais il faut prévoir quelques jours d’ateliers de travail intensifs pour le formaliser et prioriser le tout en fonction essentiellement de la valeur que chaque item du backlog peut apporter au client et / ou aux utilisateurs (risques qu’il peuvent lever et des dépendances potentielles sont aussi pris en compte).
Les éléments du backlog produit prennent généralement la forme de « User stories » (ex: En tant que Client, je veux annuler ma réservation ») pour ceux en haut de pile, à traiter dans les premiers sprints.
Ensuite, les éléments du backlog prennent une forme plus macro (« epics« ) pour les éléments moins prioritaires traités en fin de release.
Les éléments des releases suivantes étant quant à eux simplement mentionnés, si c’est possible.
Enfin, le backlog de produit peut aussi contenir ce que j’appelle des « Tech Stories » mais je reviendrai sur leur traitement spécifique dans un autre billet.
Mon challenge:
- Sensibiliser sur l’importance cruciale du backlog produit et du plan de release
- Travailler avec le Product Owner pour que le backlog de produit soit un élément de sortie du Sprint 0
- Former sur la distinction User stories (et plus haut « epic », thèmes ») / Tâches (envisagées collectivement par l’équipe et niveau le plus élémentataire; décomposition des « user stories »)
- Creuser avec l’équipe la question des « Tech stories »
bonjour,
<quote>
dont les éléments sont priorisés et estimés par l’équipe ?
</quote>
Je ne suis pas "encore" un client averti d’agile mais il me semblait que c’est le client qui "priorise" les éléments du backlog. Est-ce bien le cas ?
raccourci potentiellement source de confusion:
priorisés (par le Product Owner, c’est à lui de le faire mais il peut être aidé) et estimés (par l’équipe)