Qu’est ce que vous mettez dans votre Jira ?

8 min readApr 30, 2020

En cette période de confinement je travaille côte à côte avec ma moitié, sur cette table bancale qui nous sert à la fois de table à manger et de bureau, dans cette petite pièce qui nous sert à la fois de cuisine, de salle à manger et de lieu de travail. Dans cette situation nous sommes inévitablement amenés à vivre la journée de travail de l’autre en même temps que la nôtre : les réunions, les rires et les frustrations. Un jour, il m’a fait part de ses difficultés à avancer sur ses sujets de roadmap face à la quantité de demandes entrantes à gérer. En tant que data analyst, il voulait mon point de vue de Product Manager sur le sujet : je vous partage cette discussion qui permet d’avoir une vue d’ensemble de nos pratiques et de nos process de priorisation du backlog chez Meilleurs Agents.

Sommaire

Comment utilise-t-on Jira chez Meilleurs Agents ?
Comment rédiger un ticket ?
Est-ce que vous costez les tickets ? Comment ?
Qu’est ce que vous mettez comme tickets dans votre kanban ?
Comment traiter les bugs et les demandes entrantes ?
Et les améliorations continues ?
Qu’est ce que vous faites si au bout des deux semaines vous n’avez pas atteint votre objectif ?

Comment utilise-t-on Jira chez Meilleurs Agents ?

La façon d’utiliser Jira dépend de l’organisation et de la méthode adaptée à une équipe de développement. Chacune de nos quatre impacts teams a ses spécificités, selon les façons de travailler de chacun et les sujets traités.

En ce moment dans ces équipes nous suivons une méthode entre Scrum et Kanban : nous gardons les rituels de Scrum (daily standup, rétrospective, démo toutes les deux semaines) afin d’avoir du rythme et des moments clefs, mais nous travaillons en flux avec un kanban Jira. Les tickets sont donc ajoutés et priorisés en continu. Le but n’est pas de “vider la colonne todo” du kanban, mais nous nous fixons en équipe des objectifs réalisables, par semaine et par quinzaine.

Nous avons mis en place des “wip limits” dans nos colonnes de kanban : il ne peut pas y avoir autant de tickets que de développeurs dans une même colonne. Le but est de favoriser le travail en pair et la responsabilité d’équipe, car si la limite est atteinte, le développeur devra aider à faire avancer les tickets au lieu de prendre une nouvelle tâche. Chaque ticket est en effet la responsabilité de l’équipe et non pas uniquement du développeur ayant travaillé dessus : tout le monde doit avoir pour priorité de faire avancer le plus vite possible les tickets présents dans le kanban.

Comment rédiger un ticket ?

Le ticket doit avoir un titre clair avec une phrase structurée sous la forme « En tant que <utilisateur> je veux <action> afin de <bénéfice> » qui permet de mettre en avant la valeur apportée. Une User Story respectera tant que possible les caractéristiques du framework “INVEST”.

Indépendante : une User Story est indépendante par rapport aux autres User Stories du backlog car toute dépendance risque de générer des temps d’attente ou des complications. Ce critère est le plus délicat : parfois pour faciliter la QA ou ne pas créer un ticket trop gros nous sommes contraints de découper des tickets qui ne peuvent être livrés indépendamment les uns des autres.
Négociable : une User Story est une base de discussion par rapport au besoin initial formulé dans le ticket.
Valorisable : une User Story doit rendre un service à l’utilisateur.
Estimable : une User Story doit être bien définie pour être facilement estimable : si l’équipe a du mal à le faire, la User Story manque peut-être de clarté ou mérite d’être découpée.
Small : une User Story doit être réalisable sur un sprint pour éviter les effets tunnels sur plusieurs sprints. Il vaut mieux découper les User Stories le plus finement possible : ainsi les risques sont minimisés, le ticket plus facile à tester et il est souvent plus satisfaisant de déployer tous les sprints des petites tâches que de déployer tous les trois sprints de grosses tâches.
Testable : les scenarios et critères d’acceptabilité du ticket doivent être clairs pour valider plus vite.

Pour résumer dans une user story on va retrouver : l’objectif du ticket, le contexte (pourquoi faisons-nous ça, quel discovery nous a amené à cette tâche), le détails des spécifications, la ou les maquettes si besoin, la nécessité ou non de communiquer aux autres équipes au moment de déployer et le cahier de recette pour tester les scénarios pendant la phase de QA.

L’utilisation des epics dépend de l’équipe et du sujet : une epic peut correspondre à un lot, au sein de laquelle on trouvera un certain nombre de User Stories, mais on peut également choisir un périmètre plus petit.

Est-ce que vous costez les tickets ? Comment ?

Le costing dépend des équipes : certaines ne costent pas, d’autres costent au fil de l’eau au moment de prendre un nouveau ticket. À l’issue du cadrage, nous costons en jours hommes. Le chiffre donné doit inclure tout le trajet du ticket entre le début du développement et le passage en production, en prenant en comptela PR, la QA (chez Meilleurs Agents la QA est réalisée par les Product Managers de l’équipe) et le temps de déploiement.

Qu’est ce que vous mettez comme tickets dans votre kanban ?

Environ 70% des tickets présents dans le kanban d’une équipe sont issus de la roadmap de l’entreprise et 20% sont des tickets de maintenance technique (“MCO”, maintenance en condition opérationnelle)ou d’amélioration continue.

Pour déterminer la roadmap de l’entreprise, tout commence en fin d’année quand le comité de direction choisit les OKR pour l’année suivante, en fonction des priorités stratégiques à donner. Une fois décidés, ces OKR ont des porteurs chargés d’organiser les ateliers d’impact mapping pour collecter les idées, de présenter une recommandation de priorisation de ces initiatives au Comité Exécutif tous les trimestres, et de suivre l’atteinte de ces objectifs tout au long de l’année. Tout l’intérêt de ce process est d’avoir des priorités communes pour toutes les équipes de l’entreprise (plus de détails ici). Une fois une initiative priorisée et validée, les Product Managers vont cadrer le sujet, prioriser les fonctionnalités en équipe (grâce notamment au story mapping) et définir des lots, avant de découper ces fonctionnalités en tickets à intégrer dans Jira.

Enfin, nous devons ponctuellement ajouter des tickets de bugs et de “demandes entrantes” (environ 10% des tickets).

Comment traiter les bugs et les demandes entrantes ?

Nous distinguons les bugs des “needs”, qui sont des demandes entrantes de tâches qui ne demandent pas plus de deux jours de développement mais qui ont un impact important pour les équipes ou pour les utilisateurs. Par exemple, si le mode de rémunération des équipes commerciales change, nous devons modifier certains paramètres dans le back office pour le prendre en compte dans le calcul des primes.

Afin de pouvoir traiter au mieux ces bugs et ces needs nous avons imposé un template à compléter :

Tout “need” qui prend plus de deux jours de développement doit être priorisé par rapport à la roadmap. Par exemple, nous avons choisi de décaler les sujets de roadmap pour mettre en place la communication adaptée face au Covid. Si la demande prend moins de deux jours, nous la priorisons de la même façon que pour les bugs : si cela impacte un nombre important d’utilisateurs ou de collaborateurs et qu’il y a une contrainte de temps, le ticket est directement intégré à un kanban d’équipe. Sinon, le ticket est ajouté à un backlog dans lequel les Product Managers iront régulièrement piocher, en début de semaine ou dans un moment où l’équipe a de la disponibilité, selon l’urgence de la tâche.

Et les améliorations continues ?

Les tickets de MCO permettent d’améliorer le code en continu, mais certaines tâches amélioreraient également le produit et nous nous sommes posés la question de la façon de les traiter. Nous nous sommes rendus compte que le moment où nous identifions ces tâches (retour utilisateur, tâche “nice to have” d’une initiative…) ne correspondait que rarement avec un moment où nous avions la capacité de les traiter. Entre deux Delivery, nous avons parfois une phase de Discovery et donc un peu de temps de développement disponible : l’occasion parfaite de traiter des améliorations qui ne sont pas indispensables mais qui apportent de la valeur à nos utilisateurs, tout en utilisant au mieux cette bande passante. Par exemple les agences immobilières demandent régulièrement de pouvoir ajouter un lien vers leur page Instagram depuis la vitrine Meilleurs Agents : ce n’est pas critique, mais très apprécié si nous pouvons le traiter.

Nous avons donc constitués un backlog distinct d’améliorations produit et nous nous sommes mis d’accord sur le type de tâches qui pouvaient y être ajoutées, et de quelle façon. Puisque n’importe quel Product Manager peut prendre un ticket de ce backlog, les tickets doivent être compréhensibles par tous. Un ticket vague, sans maquette et sans “preuve” que la tâche apporte de la valeur ne pourra donc pas être ajouté à ce backlog.

Ainsi, quand un développeur a un moment “mou” entre deux sujets, il en parle avec le Product Manager qui peut piocher dans ce backlog. Cette façon de faire nous permet de traiter en continu des petites tâches qui n’auraient jamais été priorisées en temps normal, mais qui apportent une réelle valeur pour nos utilisateurs.

Et en conclusion : qu’est ce que vous faites si au bout des deux semaines vous n’avez pas atteint votre objectif ?

Si les objectifs fixés ne sont pas atteints, ou si nous avons rencontrés des difficultés sur un ticket en particulier, nous en parlons soit en daily stand up soit en rétrospective. Nous essayons alors de comprendre les raisons et d’en sortir des actions, avec des porteurs, qui nous permettront d’améliorer les choses pour que la situation ne se répète pas.

Et concernant ma moitié, il a écouté attentivement puis a posté mes réponses sur son Slack d’équipe, post qui a glorieusement récolté deux likes polis. En espérant que cet article en récolte plus…!