Tu as raison, mais c’est la raison pour laquelle Scrum est qu’une étape et pas la finalité. L’équipe idéale n’a plus ni PO ni SM ni Scrum.
1 « J'aime »
Merci,
Est-ce que tu veux dire qu’il est préférable de communiquer avec l’équipe en SBI / PBI plutot en US ?
Jusqu’à là j’ai plutôt fait l’inverse : je propose les fonctionnalités dans le Product backlog sous forme des Epics et US, et s’il y a des parties techniques, des tâches « back office » à faire pr pouvoir réaliser les US pris, les dev ajoute dans le sprint backlog.
Pourrais tu stp me donner un exemple pour que je rend compte mieux ?
Il y a un exemple concret expliqué dans le pattern « Sprint Goal »:
In Silicon Valley in 2007, Palm was working on a Web OS that was later acquired by Hewlett-Packard. Sprint to sprint the teams were doing well until they appeared to hit a wall in a couple of Sprints. PBIs were not getting finished. Developers were demotivated and going home early. I was brought in and got the Product Owners and ScrumMasters to spend an hour interviewing team members on why they were demotivated. We found that they did not understand the reason they were working hard on low-level PBIs*.*
We spent an afternoon cleaning up the Product Backlog showing a clear linkage between high-level stories and the decomposition hierarchy. As soon as the developers understood that the Sprint Goal was to improve performance of the Web OS by 10%, they were motivated to complete the low-level stories and velocity went back up to normal.
Understanding why the PBIs are being implemented is critical for developers, particularly for expert developers who would prefer to go surfing if they don’t see the reason for their work.
1 « J'aime »
Mais ça ne répond pas entièrement à ta question. Le formalisme des US fait qu’elles entrainent une communication formatées de l’information pour atteindre un but précis. Les taches que tu appelles « Back Office » sont aussi importante pour l’atteinte du Product Goal que les « US », mais sont traités comme des taches de secondes importance dans la littérature actuelle. En plus de ça, (mais là, ça dérive sur un autre sujet), le format US est devenu un fourre tout en terme de process pour définir tout et n’importe quoi.
Les PBI te permettront de comprendre pourquoi l’équipe fait ça là où l’US servira à dire quoi faire pour répondre à ce pourquoi ou pour arriver à répondre à ce pourquoi.
et la tech est plus dans le comment faire pour y arriver.
Mais effectivement, lorsqu’on utilise un outil, par exemple Jira, tout passe par une US (même si plus haut on a des EPICS) et donc l’US devient un peu un fourre tout.
1 « J'aime »
Conway… tout ça tout ça… x)
1 « J'aime »
Que utilisez vous en dehors de Jira ?
Pour moi l’exemple parle de la relation entre la productivité et la compréhension de l’objectif mais ça ne répond pas à mon problème qui est plutôt dans la compréhension de la relation entre US / PBI / epic
Y’a pleins d’outils autre que Jira, qui vont des post-it au tableau excel en passant par Trello et bien d’autres mediums.
La relation entre un PBI et des US/Epic, c’est que le PBI décrit un « Quoi » quand l’US se focalise sur le « Pourquoi ». Là où ça coince, c’est que ce « Pourquoi » est orienté ‹ utilisateur › mais que le produit/système/process/l’équipe à également besoin d’évoluer pour atteindre le Product Goal.
Si tu utilises déjà Jira, tu peux aller par exemple vers Miro ou draft.io qui pourront apporter un côté visuel, tableau de bord intégré qui fait le lien via plugin avec Jira et permet de gagner en productivité.
Ca peut te servir à apporter des éléments de réponses autour des tickets seuls si cela te permet d’être plus claire et d’apporter plus de visibilité à l’équipe sur le sens de tout ce que vous faites. Et utilisable également lors des rituels en coopératif donc plutôt fun.
Merci je comprends mieux la différence.
Pour moi les autres sont beaucoup moins adapté au cadre de Scrum. J’utilise déjà Miro pour le mapping, roadmap, estimation ,retro etc mais j’ai du mal à voir comment on peut passer de Jira
J’aurais tendance à dire que c’est typiquement une situation où l’outil informe la pratique. Mais ça fait partie des choses qui ont besoin d’être « vécue » pour être comprises de manière profonde. Désolé c’est un peu vague =/
dis toi juste qu’on peut tout faire avec des post it, tu comprendras mieux qu’on peut donc très facilement se passer de jira… même si le côté numérique apporte une souplesse dans le travail à distance… par rapport aux post it et aux photos 
Toutes mes équipes sont en télétravail mais avec Miro le systeme de post it fonctionne tres bien.
C’est juste que je n’ai pas songé à remplacer tout le backlog par les post it 
Avez-vous eu le choix de choisir si vous travaillez avec Jira ou pas ? Ou le choix est imposé par l’entreprise ?
J’ai eu plusieurs opportunités, mais sur toutes les dernières que j’ai vécu, Jira était imposé. En vrai, c’est uniquement sur celles qui n’utilisaient pas encore Jira que la possibilité de changé existait. Sur toutes les organisations « mariées » à Jira, je n’en ai encore jamais vu une sortir de cette horreur.
Fais un petit tour par ici, tu gagneras peut-être à plus utiliser Miro et garder le lien sur jira si tu es obligée de travailler avec. Miro & Atlassian integrations | Integrate Miro with Jira, Trello & Confluence | Miro
Ca peut être un point de départ pour mieux fluidifier ton workflow…
J’ai cherché à faire cela dans le passé mais c’est une option payante donc je n’ai pas pu
J’aime cette idée de lister un ensemble de questions à répondre par oui ou non.
Je suis de temps en temps amené à faire des audits de conformité ; pour cela j’ai traduit un tableau d’anti-pattern que je remplis à mesure de mes constats.
C’est fou comme on peut torturer notre petit guide ! et les déviances vont bon train sans la vigilance d’un SM !
Pourquoi ne pas partager ce genre de questionnaire d’audit ?
Celui que j’ai est basé sur les rôles ; un outil qui me fait gagner énormément de temps !
Et puis, il pourrait servir aux « équipes pour s’auto-évaluer » et permettre ainsi aux équipes sans SM (ou qui n’en n’ont plus) de s’améliorer en continu en complément des rétrospectives.
(Il faut que je retrouve la source du tableau que j’ai utilisé … avant de partager si besoin)
1 « J'aime »
Le PO gère ou ou plusieurs produits. Et donc, est dans plusieurs équipes… théoriquement.==> Oui s’il a la capacité, le scrum guide laisse le champ ouvert
En fait, le PO est hors des équipes, il est juste là pour créer des US. ==> non, il fait partie de l’équipe, il clarifie le besoin, il support techniquement s’il a les compétences.
Le PO est le responsable de son ou ses produits. Et donc, s’il y a un problème en prod c’est lui le responsable. ==> Non toute l’équipe Scrum est responsable, puisque durant chaque itération on fait un revue, et un retro,
Le PO gère son ou ses backlogs et priorise ses tickets.==> non c’est l’équipe qui gère selon Scrum guide
Le PO ne dérange pas les devs. Il doit passer par le SM quand il veut leur poser une question et poser une réunion pour ne pas les déranger dans leur travail. ==> non PO fait partie de l’équipe il n’est pas externe, il doit discuter avec l’équipe a chaque fois il y a l’occasion.
Le PO est toujours disponible pour les membres de l’équipe à tout moment. Les devs ou le SM peuvent venir lui parler quand ils veulent. ==> oui puisqu’il fait partie de l’équipe.
Le PO présente les US en raffinement. ==> oui
Le PO ne participe pas au « chiffrage » des US avec l’équipe. ==> c’est l’équipe Dev
Le PO ne participe pas au sprint planning de l’équipe. ==> non , il participe, il y- a sprint Goal , il y a les critères d’acceptation… donc il doit participer
Le PO est présent au DM mais ne parle pas, ou alors tout à la fin s’il a quelque chose à dire. ==> même il n’a pas obligé d’être présent,
Le PO ne participe pas à la rétrospective. ==> faux , il doit, c’est toute l’équipe.
Le PO ne décide pas quand une US rentre dans un sprint, c’est le SM qui décide ça. ==> Faux , le scrum master surveille le cadre de scrum et c’est le DEV décident qu’elle US sera pour le sprint selon le sprint goal.
Je suis circonspect sur « tout le monde est responsable » … car c’est le meilleur moyen de sombrer dans le « personne n’est responsable ».
« Un problème en prod » ça veut dire quoi ? Le système est arrêté ? Une partie majeure du système est arrêtée ? Un contrôle est défaillant sur un formulaire ?
Bref, analyse et priorisation de la résolution du « problème ». Donc le dernier mot est au PO …
Et en élargissant le débat sur la responsabilité collective, j’ai peur que ça ne fonctionne pas ainsi dans de nombreuses entreprises où le PO reste le représentant du métier (MOA) qui pilote l’activité de l’équipe de Dev (MOE), même si le fonctionnement au quotidien est collaboratif
Concernant l’utilisation d’US en général, certains vont argumenter que l’utilisateur n’est pas forcement le client final, et utilise une US avec comme « utilisateur » un systeme, une machine, ou un developpeur, une personne de l’equipe maintenance etc.
Donc pour les gens qui veulent vraiment utiliser des US partout, ils peuvent. Faut juste garder à l’esprit les « autres utilisateurs ».
D’un autres côté pour ceux qui ne veulent pas utiliser d’US, mais ont JIRA, normalement JIRA peut être configuré pour utiliser plusieurs types de tickets, donc on peut créer un projet sans story.
En conclusion, utilisons ce qu’on veut, l’important c’est que l’info passe bien ;).