Commencez par définir un objectif clair pour le projet

Avant de créer des tickets Jira, rédigez une courte déclaration de résultat décrivant l’utilisateur, le problème et le résultat attendu. Par exemple, une équipe de deux personnes qui développe une application de réservation peut avoir pour objectif de permettre aux clients de choisir un service, de sélectionner un créneau disponible et de recevoir un e-mail de confirmation. Cette formulation est plus utile qu’un objectif vague comme « créer une plateforme de réservation moderne », car elle fournit un cadre aux décisions ultérieures.

Ajoutez un critère de réussite mesurable pour la première version. Une formulation pratique pourrait être qu’un client test puisse effectuer une réservation en moins de trois minutes depuis le navigateur d’un téléphone. Ce critère n’a pas besoin de prédire le chiffre d’affaires ; il doit aider l’équipe à déterminer si une fonctionnalité appartient à la version 1 ou peut attendre.

Configurez le projet Jira approprié

Pour un premier projet logiciel, créez un projet Jira Software et choisissez un modèle Scrum lorsque le travail sera livré selon des cycles de planification fixes. Choisissez Kanban lorsque les priorités peuvent changer quotidiennement et que l’équipe souhaite ne prendre l’élément suivant qu’après avoir terminé le travail en cours. Un projet étudiant de trois semaines bénéficie généralement de Scrum, car la date de fin rend utiles les engagements courts et visibles.

Gardez le workflow initial simple : À faire, En cours, Revue de code et Terminé suffisent pour de nombreuses petites équipes. Ajouter ultérieurement des statuts distincts pour les tests, la revue de conception, le déploiement et la validation peut être pertinent, mais uniquement si quelqu’un utilise activement chacun d’eux. Chaque statut supplémentaire crée une occasion de plus d’accumuler des tickets obsolètes et de rendre les responsabilités floues.

Définissez rapidement les permissions afin que chaque contributeur puisse créer et mettre à jour des tickets, tandis qu’un responsable de projet puisse gérer les paramètres du tableau et les versions. Connectez également le projet à votre dépôt de code source si l’équipe utilise GitHub, GitLab ou Bitbucket. L’association des branches et des pull requests à des clés de tickets telles que APP-14 permet de vérifier plus facilement qu’une story planifiée correspond bien à un travail d’implémentation réel.

Transformez le périmètre en epics et en stories

Créez des epics pour les fonctionnalités majeures destinées aux utilisateurs, et non pour les départements techniques. Dans l’application de réservation, les epics appropriés sont Accès au compte, Catalogue des services, Parcours de réservation et Notifications. Un epic doit décrire une partie significative du produit pouvant contenir plusieurs éléments de travail plus petits, plutôt qu’une étiquette générale comme « frontend ».

Décomposez chaque epic en user stories rédigées du point de vue de l’utilisateur. Une story utile serait : « En tant que client, je veux voir les créneaux disponibles pour un service sélectionné afin de pouvoir choisir un rendez-vous qui me convient. » Elle indique au designer, au développeur et au testeur le comportement attendu sans imposer chaque détail d’implémentation.

Ajoutez les critères d’acceptation directement dans la story Jira. Pour la story concernant les créneaux, les critères peuvent exiger que les horaires indisponibles ne puissent pas être sélectionnés, que tous les horaires utilisent le fuseau horaire de l’entreprise et qu’un état vide s’affiche lorsqu’il ne reste aucun créneau. Ces précisions évitent qu’un ticket arrive en revue avec une interface techniquement fonctionnelle, mais incomplète.

Préparez les éléments du backlog pour le développement

Un backlog n’est pas simplement une longue liste de fonctionnalités souhaitées. Chaque élément situé en haut de la liste doit comporter une description concise, des critères d’acceptation, une priorité et suffisamment de contexte pour qu’un coéquipier puisse commencer sans réunion. Joignez une esquisse rapide d’écran, un exemple d’API ou un lien vers un fichier de conception lorsque cela répond à une question réelle ; évitez de joindre des documents que personne ne lira.

Divisez les stories trop importantes pour être terminées au cours d’un seul sprint. « Développer l’authentification des utilisateurs » dissimule souvent l’inscription, la connexion, la réinitialisation du mot de passe, la validation, la gestion des sessions et les messages d’erreur. Pour un sprint d’une semaine, séparez l’inscription et la connexion en stories distinctes, puis créez des sous-tâches techniques uniquement lorsqu’elles aident quelqu’un à suivre une étape concrète, comme une migration de base de données ou la configuration d’un modèle d’e-mail.

Utilisez les labels avec parcimonie pour les sujets transversaux tels que l’accessibilité, les bugs, la sécurité ou le mobile. N’utilisez pas les labels pour remplacer simultanément les epics, les composants et les priorités. Une nouvelle équipe doit pouvoir filtrer le backlog et répondre rapidement à trois questions : ce qui est prévu pour la première version, la personne qui en est responsable et ce qui la bloque.

Estimez le travail sans fausse précision

Estimez l’effort relatif avec des story points plutôt que de deviner un nombre exact d’heures pour chaque ticket. Une équipe peut définir 1 point comme une modification très petite et familière, 3 points comme une story standard nécessitant quelques décisions, et 8 points comme un travail qui doit probablement être scindé. Cette échelle est utile parce qu’elle fait ressortir l’incertitude, et non parce qu’un point correspond à une durée universelle.

Organisez une courte discussion de planification pour le premier sprint. Demandez ce qui est inconnu, quelles dépendances existent et quelles preuves démontrent que la story est terminée. Si un développeur estime une story à 2 points et un autre à 8, ce désaccord révèle souvent une exigence manquante, comme l’accès à l’environnement de test du paiement ou un chemin de migration requis.

Pour le premier sprint, engagez-vous avec prudence. Si deux personnes sont disponibles pendant cinq jours ouvrés, ne remplissez pas chaque heure de tickets : les réunions, les revues, les corrections de bugs et le travail de mise en place consomment une partie de la capacité. Après un ou deux sprints, utilisez le nombre de points réalisés comme vélocité propre à l’équipe, au lieu de reprendre un objectif fixé pour une autre équipe.

Planifier les sprints autour d’une tranche utilisable

Un bon premier sprint produit un parcours produit réduit, mais utilisable. Pour l’application de réservation, cela peut consister à afficher des services codés en dur, à en choisir un, à sélectionner un créneau fictif et à afficher un écran de confirmation. C’est plus utile que de terminer séparément une page de connexion soignée, un schéma de base de données et une intégration d’e-mails qui ne peuvent pas encore être utilisés ensemble.

Pendant la planification du sprint, ne déplacez dans le sprint actif que les stories prêtes et vérifiez leurs dépendances. Si l’écran de réservation dépend d’une API de services qui n’existe pas, planifiez d’abord le développement de l’API ou utilisez une source de données temporaire définie intentionnellement. Consignez ce raccourci technique dans Jira afin qu’il reste visible et ne devienne pas une dépendance permanente par inadvertance.

Attribuez le travail en fonction des responsabilités et des objectifs d’apprentissage, mais évitez de considérer le champ d’assignation comme un mécanisme de transmission. Examinez brièvement le tableau chaque jour et discutez des problèmes bloquants avant d’attribuer de nouvelles tâches. Une carte qui reste En cours pendant quatre jours mérite qu’on s’y intéresse, même si sa date d’échéance n’est pas encore dépassée.

Utiliser les rapports Jira pour améliorer le sprint suivant

À la fin du sprint, comparez le travail réalisé avec l’objectif du sprint, et pas seulement le nombre de tickets clôturés. Si l’équipe a terminé neuf petites tâches, mais que les clients ne peuvent toujours pas effectuer de réservation, le plan a peut-être privilégié des éléments techniques faciles au détriment d’un résultat utilisable. Faites une démonstration du parcours fonctionnel et notez précisément à quel endroit il s’arrête.

Utilisez le graphique burndown comme point de départ pour la discussion. Une ligne plate pendant plusieurs jours peut indiquer que les stories sont trop volumineuses, que le travail attend une revue ou que les membres de l’équipe ne mettent à jour Jira qu’à la fin de la semaine. Ce n’est pas un indicateur de performance et il ne doit pas servir à faire pression sur les personnes pour qu’elles clôturent un travail incomplet.

Organisez une courte rétrospective et transformez une ou deux améliorations en véritables éléments du backlog. Par exemple, si les revues de code ont retardé chaque story, ajoutez à l’accord d’équipe la règle de demander une revue avant de commencer un autre ticket et créez une petite tâche pour configurer les notifications de revue. La planification s’améliore grâce à cette boucle de rétroaction ; le premier plan Jira doit donc être considéré comme un point de départ vérifiable plutôt que comme un contrat permanent.

Pour aller plus loin

Jira

Gestion de projet Agile

Récits utilisateurs