tutoriel

Learn scrum with Jira Software

Instructions détaillées pour gérer un projet Scrum

Claire Maynard Claire Maynard

Tutoriel Scrum

Dans ce tutoriel, nous vous fournissons des instructions détaillées pour mener un projet Scrum, prioriser et organiser votre backlog en sprints, organiser des « cérémonies » Scrum, et bien plus encore, le tout dans Jira Software.

Durée :

10 minutes de lecture. 2 semaines d'implémentation.

 

Public :

Vous êtes nouveau dans le développement Agile ou Jira Software

 

Prérequis :

Vous avez créé un compte Jira Software

Essayez-le gratuitement

What is scrum?

Scrum est un framework de développement itératif. Dans ce tutoriel, vous aurez un backlog pour prioriser vos tâches en sprints, ainsi qu'un tableau avec un workflow simple.

Étape 1 : Création d'un projet Scrum

Dès que vous créez un compte Jira Software et que vous vous connectez (lien sous les prérequis), vous pourrez concevoir un projet. Lorsque vous êtes invité à sélectionner un type de projet, assurez-vous de sélectionner Développement Scrum. Vous pouvez également apprendre comment lancer un projet Kanban ici.

Un tableau Scrum est automatiquement créé avec un projet de développement Scrum. Après avoir créé votre projet, vous serez dirigé vers le backlog vide de votre tableau Scrum. Vous avez maintenant l'opportunité de remplir votre backlog avec des user stories ou des tâches à réaliser dans le cadre de votre projet, votre fonctionnalité ou votre produit.

Étape 2 : Création de user stories ou de tâches dans le backlog

Dans Jira Software, nous appelons les user stories, tâches et bugs des « tickets ». Créez rapidement quelques user stories avec l'option de création rapide dans le backlog. Si vous ne songez à aucun projet ou à aucune fonctionnalité spécifique, créez simplement des exemples de user stories pour découvrir comment cela fonctionne.

Création de user stories | Atlassian – Le coach Agile
Que sont les user stories ?

Dans un framework Agile, les user stories sont les plus petits blocs de travail. En tant que {type d'utilisateur}, je souhaite {objectif} afin de {bénéficier des avantages}.

 

Utilisons un site Web comme exemple simple de création d'une user story.

 

En tant que client, je souhaite pouvoir créer un compte qui me permettra de visualiser les achats que j'ai effectués au cours des 12 derniers mois et prévoir mon budget pour l'année suivante.

 

Les user stories sont esquissées par le responsable produit, après quoi l'équipe produit détermine collectivement les exigences de façon plus détaillée. Ce sont les blocs de travail granulaires qui aident à définir les éléments d'implémentation pour la story et le sprint à venir.

Après avoir créé 6 user stories ou plus, vous pouvez les prioriser dans le backlog. Dans Jira Software, vous classez ou priorisez vos stories en les glissant et en les déposant dans votre backlog, dans l'ordre d'importance qui convient à votre équipe.

Étape 3 : Estimation de vos stories

Avant de commencer votre premier sprint, il est essentiel d'estimer les stories dans le backlog afin de déterminer le temps nécessaire pour terminer les blocs de travail.

Qu'est-ce qu'une estimation Agile ?

Les équipes traditionnelles de développement de logiciels réalisent leurs estimations en temps : jours, semaines, mois. En revanche, beaucoup d'équipes agiles sont passées aux story points. Les story points notent l'effort relatif du travail selon la suite de Fibonacci : 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Cela peut sembler tout sauf intuitif. Pourtant, cette abstraction est utile puisqu'elle pousse l'équipe à prendre des décisions plus radicales en ce qui concerne la difficulté du travail.

Les estimations vous aideront également à évaluer la quantité de travail à ajouter au prochain sprint en fonction du nombre de membres de l'équipe disponibles. Après quelques sprints, votre équipe parviendra mieux à estimer la quantité de travail qu'elle pourra accomplir à chaque sprint, ce qui évitera de prendre des engagements trop importants.

Dans Jira Software, vous pouvez effectuer une estimation des tickets en accédant au backlog et en saisissant un nombre dans le champ Estimation pour chaque ticket.

Étape 4 : Création d'un sprint

Créez votre premier sprint dans le backlog afin de pouvoir organiser les tickets en sprints.

Qu'est-ce qu'un sprint ?

Dans Scrum, les équipes prévoient de réaliser une série de user stories pendant une période définie, connue sous le nom de sprint. En général, les sprints durent une, deux ou quatre semaines. C'est l'équipe qui détermine cette durée. Nous vous conseillons de commencer par deux semaines. C'est assez long pour parvenir à un résultat, tout en permettant à l'équipe de recevoir un feedback régulier. Une fois que la cadence du sprint a été fixée, l'équipe opère toujours au rythme défini. Les sprints dont la durée est fixe renforcent les aptitudes d'estimation et permettent de prédire la vélocité future de l'équipe au fur et à mesure de sa progression dans le backlog.

Création d'un sprint | Atlassian – Le coach Agile

Étape 5 : Réunion de planification de sprint

Avant de commencer un sprint, vous devez organiser la réunion de planification de sprint avec le reste de votre équipe. Au cours de cette réunion, vous estimerez les user stories non estimées du backlog priorisé, vous obtiendrez l'engagement de l'équipe sur ses capacités et, enfin, vous créerez le premier sprint.

Vous devriez également tenir compte des absences éventuelles au sein de votre équipe, comme les vacances, les congés prévus, ainsi que de tout autre problème qui pourrait affecter la réalisation des tâches de sprint.

Notez également qu'à l'étape 3, votre équipe devrait avoir estimé les stories dans les story points, et ce, dans l'ordre de priorité. Lors de la planification du sprint, vous ne devriez uniquement estimer les stories qui ne l'ont pas encore été, notamment en raison d'une ambiguïté lors de l'estimation des stories.

Qu'est-ce qu'une réunion de planification de sprint ?

Participants : équipe de développement, Scrum Master, responsable produit

 

Quand : au début d'un sprint.

 

Durée : Généralement une heure par semaine d'itération (par exemple, un sprint de deux semaines démarre par une réunion de planification de deux heures).

 

Framework Agile : Scrum. (Les équipes Kanban planifient également, bien entendu, mais elles ne fonctionnent pas selon un calendrier d'itérations fixe avec une planification formelle des sprints.)

 

Objectif : la planification du sprint garantit la réussite de l'équipe dans son ensemble, tout au long du sprint. En arrivant à la réunion, le responsable produit disposera d'un backlog produit hiérarchisé. Il discutera de chaque élément avec l'équipe de développement. Le groupe estimera, de façon collective, les efforts que cela implique. L'équipe de développement procèdera ensuite à une prévision du sprint, en déterminant la quantité de travail réalisable par l'équipe à partir du backlog produit. Cet ensemble de tâches deviendra alors le backlog de sprint.

Étape 6 : Glisser-déposer de tickets dans votre sprint

Le backlog vous permet de prioriser vos user stories les plus essentielles. Au cours de la réunion de planification de sprint, vous pouvez déterminer les tickets sur lesquels vous souhaitez travailler dans votre premier sprint. C'est important, dans la mesure où vous souhaitez éviter toute dérive des objectifs. Réfléchissez au travail que votre équipe est prête à accomplir et à ce que vous souhaitez réaliser dans le sprint.

Lorsque vous avez fini, faites glisser les stories dans le sprint que vous venez de créer.

Étape 7 : Lancement de votre premier sprint

Nommez le sprint. Certaines équipes nomment le sprint en fonction de leur objectif. S'il existe un point commun entre les tickets dans le sprint, choisissez un nom en rapport avec ce thème. Sinon, vous pouvez nommer le sprint comme bon vous semble. Indiquez la durée du sprint et les dates de début et de fin. Les dates de début et de fin doivent être alignées sur le calendrier de votre équipe. Par exemple, certaines équipes commencent les sprints le lundi et les terminent le vendredi matin de la semaine suivante. D'autres équipes décident de commencer et de terminer leurs sprints au milieu de la semaine. C'est vous qui voyez ! Si vous n'êtes pas sûr de la durée à prévoir pour vos sprints, nous vous recommandons d'essayer deux semaines.

Dès que vous commencez votre sprint, vous serez dirigé vers l'onglet Sprints en cours du projet.

Sprint actif | Atlassian – Le coach Agile

C'est l'étape à laquelle votre équipe sélectionnera des éléments de la colonne À faire pour les déplacer dans En cours, puis finalement dans Terminé !

Étape 8 : Organisation du stand-up quotidien

Une fois votre sprint lancé, organisez une réunion quotidienne avec les membres de votre équipe (en principe le matin) pour discuter des tâches réalisées par chacun. L'objectif est de voir si l'un d'eux rencontre des difficultés pour réaliser les tâches de sprint.

Qu'est-ce qu'un stand-up quotidien ?

Participation obligatoire : équipe de développement, Scrum Master, responsable produit Facultatif : parties prenantes de l'équipe

 

Quand : une fois par jour, généralement le matin.

 

Durée : pas plus de 15 minutes. Ne réservez pas une salle de conférence pour y tenir le stand-up en position assise. La position debout permet de raccourcir au maximum la réunion.

 

Framework Agile : Scrum et Kanban. 

 

Objectif : le stand-up quotidien a pour but d'informer rapidement tous les participants de ce qui se passe au sein de l'équipe. Il ne s'agit pas d'une réunion d'avancement à proprement parler. Le ton doit être léger et ludique, tout en restant informatif. Invitez chaque membre de l'équipe à répondre aux questions suivantes :

 

  • Qu'ai-je terminé hier ?
  • Sur quoi vais-je travailler aujourd'hui ?
  • Y a-t-il quelque chose qui bloque mon travail ?

 

Rendre compte aux autres des tâches que vous avez accomplies la veille comporte une forme de responsabilisation implicite. Personne ne souhaite devenir le membre de l'équipe qui travaille constamment sur les mêmes tâches et qui ne progresse pas.

 

Conseil d'expert : certaines équipes utilisent des chronomètres pour que chacun respecte le temps qui lui est imparti. D'autres lancent une balle d'un membre de l'équipe à un autre afin que tous restent attentifs. Beaucoup d'équipes distribuées se servent de la vidéoconférence ou de la discussion de groupe pour réduire la distance entre les membres. Votre équipe est unique, votre stand-up devrait l'être tout autant !

Vous pouvez utiliser les sprints en cours de votre tableau Scrum au cours du stand-up quotidien, de sorte que chaque membre de l'équipe puisse voir les tâches sur lesquelles il travaille.

Affichage du graphique d'avancement

Il est réellement judicieux de consulter le graphique d'avancement pendant un sprint. Dans Jira Software, le graphique d'avancement montre la quantité de travail réelle et estimée à effectuer dans un sprint. Pour l'afficher, cliquez sur Rapports dans la barre latérale, puis sélectionnez le graphique d'avancement dans la liste déroulante des rapports.

Qu'est-ce qu'un graphique d'avancement et comment le lire ?

Un graphique d'avancement présente la quantité de travail estimée et réelle pour un sprint. L'axe horizontal (x) d'un graphique d'avancement indique le temps, tandis que l'axe vertical (y) indique les tickets.

 

Utilisez le graphique d'avancement pour suivre l'ensemble du travail restant pour un sprint et pour déterminer la probabilité d'atteindre l'objectif du sprint. En suivant le travail restant tout au long de l'itération, une équipe peut gérer sa progression et réagir en conséquence.

 

Les équipes Scrum organisent le développement en sprints limités dans le temps. Au début du sprint, l'équipe prévoit la quantité de travail qu'elle sera capable de réaliser pendant celui-ci. Ensuite, le graphique d'avancement présente le suivi du travail réalisé tout au long du sprint. L'axe X représente le temps et l'axe Y montre la quantité de travail qu'il reste à réaliser et qui est mesurée soit en story points, soit en heures. Les équipes Scrum utilisent ensuite le graphique d'avancement pour voir l'avancement des membres de l'équipe dans la réalisation des tâches prévues d'ici la fin du sprint.

 

Une équipe qui honore régulièrement ses prévisions fait la meilleure des publicités pour Agile au sein de l'entreprise. Mais que cela ne vous incite pas à manipuler les chiffres en déclarant une tâche achevée avant qu'elle ne le soit réellement. Cela peut sembler positif à court terme, mais à long terme, cela ne fera qu'entraver l'apprentissage et l'amélioration. Dans ce scénario, une équipe utilisant le graphique d'avancement a plus de chance d'exécuter les actions nécessaires pour garder le cap, et finalement atteindre l'objectif du sprint.

Graphique d'avancement Agile | Atlassian – Le coach Agile
Anti-schémas à surveiller
  • L'équipe termine très rapidement, sprint après sprint, parce qu'elle s'engage à réaliser trop peu de travail.
  • Sprint après sprint, l'équipe ne parvient pas à honorer ses prévisions parce qu'elle s'engage à réaliser trop de travail.
  • La ligne d'avancement affiche des chutes soudaines plutôt qu'une progression graduelle parce que le travail n'a pas été divisé en tâches granulaires.
  • Le Product Owner allonge ou modifie le cahier des charges en cours de sprint.

Étape 9 : Clôture du sprint

Vous devez le réaliser à la fin du sprint.

Une fois le sprint terminé, vous pourrez afficher le rapport correspondant.

Qu'est-ce que le rapport de sprint et comment le lire ?

Le rapport de sprint répertorie les tâches terminées, les tâches en cours et toute tâche ajoutée après le lancement du sprint.

 

Questions à poser :

 

  • L'équipe a-t-elle respecté la prévision du sprint ?
  • Des tâches ont-elles été ajoutées ou supprimées au cours du sprint ?
  • Des tâches sont-elles restées inachevées à l'issue du sprint ?
  • Le cas échéant, pourquoi ?

 

Objectif : Comprendre la différence entre les prévisions de sprint et la livraison réelle.

Étape 10 : Rétrospective de sprint

Une fois le sprint terminé, demandez à votre équipe d'organiser une rétrospective. Consignez celle-ci quelque part. Nous suggérons Confluence.

Qu'est-ce qu'une rétrospective de sprint ?

Participation obligatoire : équipe de développement, Scrum Master, responsable produit

 

Quand : à la fin d'une itération.

 

Durée : 60 minutes.

 

Framework Agile : Scrum et Kanban. Les équipes Scrum réalisent des rétrospectives de sprint selon une cadence fixe. Les équipes Kanban peuvent également bénéficier de rétrospectives occasionnelles.

 

Objectif : Agile vise à obtenir un feedback rapide pour améliorer la culture de développement et le produit. Les rétrospectives permettent à l'équipe de comprendre ce qui a fonctionné ou pas.

 

Les rétrospectives ne doivent pas uniquement servir à se plaindre, sans agir. Profitez des rétrospectives pour déterminer ce qui fonctionne afin que l'équipe puisse continuer à se concentrer sur ces points. Voyez également ce qui ne fonctionne pas, recherchez des solutions créatives et élaborez un plan d'action. L'amélioration continue favorise le développement et la pérennité de l'équipe Agile, et les rétrospectives en sont un élément clé.

 

Questions à poser :

 

  • Qu'avons-nous bien fait durant le sprint ?
  • Qu'aurions-nous pu faire mieux ?
  • Qu'allons-nous améliorer pour la prochaine fois ?

 

Conseil d'expert : même si tout se passe bien au sein de l'équipe, ne renoncez pas aux rétrospectives. Elles donnent à l'équipe l'orientation nécessaire pour que tout continue à bien se passer.

Étape 11 : Répétition de l'étape 4

À ce stade, vous commencez à comprendre comment créer votre backlog avec des user stories, organiser vos user stories en sprints, démarrer votre sprint et organiser des « cérémonies » Scrum. Vous pouvez décider si cette solution répond aux besoins de votre équipe ou si vous souhaitez passer à des sujets plus avancés.

 Une fois que votre équipe et vous-même avez suivi les étapes ci-dessus, passez à l'article avancé : Comment utiliser les pratiques Scrum avancées avec Jira Software.