Comment une équipe de développement de 6 personnes a remplacé Jira par un simple tableau Scrum (et a cessé de rater des sprints)

Jira est puissant. C’est aussi, pour une équipe de six personnes développant un produit SaaS, une source importante de lourdeurs administratives.

J’ai discuté avec beaucoup de petites équipes d’ingénierie ces dernières années, et le schéma se répète sans cesse : l’équipe a adopté Jira car c’est la norme du secteur, a passé deux semaines à le configurer, puis s’est retrouvée à passer plus de temps à gérer l’outil qu’à gérer le travail. Les cérémonies de sprint sont devenues des séances d’administration Jira. Le backlog s’est transformé en cimetière. Les stand-ups sont devenus de simples rapports de statut car personne n’avait consulté le tableau depuis le dernier stand-up.

Voici l’histoire de la façon dont une équipe a résolu ce problème — et à quoi ressemblait la configuration après changement.

Le problème : la complexité de l’outil freinait l’élan des sprints 

L’équipe concernée était un groupe de six personnes axé backend : deux ingénieurs seniors, deux intermédiaires, une QA et un chef de projet à temps partiel. Ils développaient une plateforme de données B2B et travaillaient en sprints de deux semaines. Sur le papier, leur processus Scrum était solide. En pratique :

• La planification de sprint durait 90 minutes car la moitié du temps était passé à retrouver le bon projet Jira, l’Epic et le type de ticket avant de pouvoir discuter de quoi que ce soit
• Des tickets restaient en « En cours » plusieurs jours car leur mise à jour nécessitait de naviguer sur quatre écrans
• Le chef de projet passait ses vendredis après-midi à extraire manuellement les rapports de sprint car les tableaux de bord intégrés étaient soit trop complexes soit nécessitaient des modules payants pour être configurés correctement
• Les nouveaux membres mettaient une semaine à comprendre où se trouvaient les éléments avant de pouvoir intervenir sur le tableau

L’outil n’était pas cassé. Il était simplement dimensionné pour une équipe de soixante, pas de six. Et la charge cognitive de l’utiliser pour chaque tâche, chaque jour, rongeait silencieusement la rigueur des sprints.

Le changement : ce qu’ils recherchaient

Quand l’équipe a commencé à évaluer des alternatives, trois critères devaient absolument être respectés :

• Un tableau lisible d’un seul regard. Colonnes Pour faire, En cours, En revue, Terminé. Le sprint clairement visible. Plus besoin de chercher le contexte.
• Des documents à côté du travail. L’équipe rédigeait beaucoup de spécifications techniques et des journaux de décisions. Ils avaient besoin que ces documents soient accessibles directement à côté des tâches concernées, et non dans un espace Confluence séparé tombé dans l’oubli.
• Un onboarding rapide. Un nouvel ingénieur rejoignait l’équipe le mois du changement. Ils ne pouvaient pas se permettre deux semaines d’apprentissage de l’outil.

Ils ont trouvé leur bonheur avec Vaiz — spécifiquement avec le modèle de tableau Scrum, qui leur a permis d’avoir une configuration de sprint opérationnelle sans aucune configuration dès le premier jour.

La configuration : comment ils ont paramétré le tableau

Le point de départ était le modèle Scrum. Dès l’installation, il leur a offert un tableau de style kanban avec des groupes de sprints, des champs de points d’histoire sur chaque tâche et un suivi des jalons pour leurs objectifs de version.

Ils ont apporté trois petites personnalisations :

• Ajouté une colonne « Bloqué » entre En Cours et À Revoir. L’équipe avait appris, par expérience, que les tickets bloqués devaient être visibles sans être mélangés aux tâches actives.
• Créé des libellés personnalisés pour le type de ticket : Fonctionnalité, Bug, Dette Technique et Spike. Cela remplaçait la hiérarchie complexe des types d’incidents dans Jira par quelque chose que tout le monde a immédiatement compris. 
• Lié leurs docs techniques directement aux tâches concernées. Les ingénieurs pouvaient ouvrir une tâche et consulter la spécification sans changer d’outil.

La planification de sprint est passée de 90 minutes à 45. Non pas parce que le travail avait changé, mais parce que la complexité de naviguer dans l’outil avait disparu.

Le résultat : trois sprints plus tard 

Après trois sprints sur la nouvelle configuration, l’équipe a remarqué trois changements concrets :

• Le taux d’achèvement des sprints s’est amélioré. Lors de leurs quatre derniers sprints sur Jira, ils avaient terminé en moyenne 68 % des story points engagés. Lors de leurs trois premiers sprints sur Vaiz, ce chiffre est passé à 84 %. La cheffe de projet l’attribuait en partie à une meilleure planification des sprints (moins de temps perdu à naviguer entre les outils, donc plus de temps pour estimer) et en partie au fait que le tableau était suffisamment visible pour que les blocages soient repérés plus rapidement.
• Le nouvel ingénieur a commencé à contribuer sur le tableau dès le deuxième jour. Aucune séance de formation n’a été nécessaire. Il a regardé le tableau, a tout compris et a commencé à déplacer les tickets.
• Les rapports du vendredi après-midi n’existaient plus. Le tableau de bord donnait à la cheffe de projet toutes les informations en temps réel. Avancement du sprint, blocages en cours, progrès des jalons — tout était visible sans aucune recherche manuelle de données.

Ce qui a fait la différence 

L’honnêteté oblige à admettre que Vaiz n’a pas plus de fonctionnalités que Jira — ce n’est pas le cas, et pour une grande équipe en entreprise, la richesse de Jira reste un véritable atout. La différence, ici, tenait à l’adéquation. Un outil qui correspondait à la taille et au rythme réels de leur travail, sans avoir à désactiver toutes les fonctions inutiles.

La possibilité d’avoir les documents directement liés aux tâches a été particulièrement précieuse. Dans Vaiz, on peut ouvrir une tâche et un document dans la même fenêtre en même temps — la spécification et le ticket sont visibles simultanément. Pour une équipe back-end qui s’écrit beaucoup de contexte technique, cela enlevait un point de friction permanent.

Essayez-le dans votre équipe 

Si votre équipe utilise Scrum et constate que la gestion de l’outil prend plus de place que la valeur du processus, il peut valoir le coup d’essayer un modèle de tableau scrum préconfiguré conçu pour les petites équipes agiles. La mise en place prend moins de dix minutes et vous disposez d’un tableau de sprint prêt à l’emploi avec story points, jalons et liens vers les documents.

Vaiz offre un essai gratuit de 30 jours, sans carte de crédit. C’est suffisant pour tester un sprint entier et voir si l’outil convient à votre équipe.