L '«élément de backlog de produit» est en effet le Quoi, la fonctionnalité qui doit être construite. La tâche décrit les étapes à suivre pour y parvenir.
De nombreuses équipes ne sont pas habituées à se décomposer en tâches, elles construisent simplement ce que dit la spécification. Pour ces personnes, il est difficile de les voir comme deux choses distinctes.
Peut-être qu'une simple anecdote aiderait:
Voir les articles du carnet de produit comme les articles de leur liste de courses pour leurs vacances. Peut-être une "tente", une "canne à pêche", une "voiture préparée pour le voyage".
Les tâches de l'élément "tente" seraient "Décrire les exigences de la tente", "Comparer les tentes en ligne", "Obtenir des conseils d'amis ayant une expérience en plein air", "Aller à la boutique en plein air", "Acheter une tente", "installer la tente dans l'arrière-cour pour vérifier l'exhaustivité "," emballer la tente pour voyager "
Les tâches pour la canne à pêche seront très similaires, mais les tâches pour "préparer la voiture pour le voyage" sont probablement très différentes: "Vérifier les exigences des États / pays sur l'itinéraire souhaité", "acheter un gilet de sécurité", "remplacer le contenu expiré des premiers secours kit "," inspecter la roue de secours "," planifier un rendez-vous avec un garage pour faire vérifier le moteur "," aller au garage pour faire vérifier le moteur "," aller à l'agence d'État pour acheter un laissez-passer d'autoroute "," vérifier l'assurance automobile "
Cela sépare clairement la question de ce que le propriétaire du produit veut de ce qu'il doit faire. À moins bien sûr que le propriétaire du produit se soit déjà décomposé en éléments exploitables dans le Product Backlog, auquel cas vous devez également lui parler.
Comme je l'ai dit, pour de nombreux développeurs, ils pensent qu'ils ont déjà suffisamment d'informations et savent quoi faire, ils ne veulent pas décomposer les étapes What into How, ils y arriveront lorsqu'ils y arriveront. Lorsque vous commencez à leur parler du suivi de la progression du sprint, de l'amélioration des estimations, du suivi du travail oublié lors de la planification du sprint et d'autres éléments liés aux améliorations professionnelles, demandez-leur comment eux et leur équipe sauront où ils peuvent s'améliorer et comment ils peuvent sais qu'ils sont vraiment faits. Quand ils peuvent trouver un système qui fonctionne sans créer de tâches et cela fonctionne, alors c'est très bien, mais les chances sont très faibles qu'ils le peuvent réellement.
Avant d'essayer de travailler avec TFS et les outils agiles, votre équipe devra comprendre comment tout cela fonctionne. La meilleure façon est de les faire travailler avec un carton, visible de tous sur le lieu de travail. Plus tard, lorsque le processus sera mieux compris, le passage aux outils sera utile. Sans compréhension, les outils ne seront pas très utiles et rencontreront beaucoup de résistance.