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.
Durée :
10 minutes de lecture. 2 semaines d'implémentation.
Public :
Vous débutez dans Scrum, dans le développement Agile ou dans Jira.
Prérequis :
Vous avez créé un compte Jira
Scrum est l'un des frameworks les plus populaires pour implémenter Agile. Avec Scrum, le produit est conçu en une série d'itérations à durée fixe appelées sprints, offrant ainsi aux équipes un framework pour livrer à un rythme régulier.
Étape 1 : Création d'un projet Scrum
Dès que vous créez un compte Jira et que vous vous connectez, vous pouvez sélectionner un modèle dans la bibliothèque. Sélectionnez Scrum (vous pouvez visualiser le modèle Scrum gratuit ou apprendre à créer un projet Kanban ici).
Ensuite, vous serez invité à choisir un type de projet. Si votre équipe travaille de manière indépendante et souhaite contrôler ses propres processus et pratiques de travail dans un espace autonome, envisagez de tester le modèle Scrum géré par l'équipe. Pour en savoir plus, consultez Premiers pas avec les projets gérés par l'équipe sur la communauté Atlassian.
Une fois que vous avez créé votre projet, vous accédez au backlog vide. Également connu sous le nom de backlog produit, le backlog contient une liste continue des tâches potentielles de votre équipe pour le projet.
Étape 2 : Création de user stories ou de tâches dans le backlog
Dans Jira, nous appelons les user stories, des tâches et les bugs, des « tickets ». Créez quelques user stories grâce à l'option de création rapide dans le backlog. Si vous ne songez à aucune user story spécifique, créez simplement des exemples de stories pour découvrir comment cela fonctionne.
Les user stories permettent de décrire les tâches dans un langage non technique et du point de vue de l'utilisateur. En tant que {type d'utilisateur}, je souhaite {objectif} afin de pouvoir {avantage}.
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 mes achats précédents.
Les user stories sont généralement esquissées et hiérarchisées par le Product Owner, après quoi l'équipe de développement détermine les tâches à réaliser pour achever la story dans un sprint à venir. L'équipe de développement est également chargée d'estimer l'effort relatif nécessaire pour achever la story.
Après avoir créé quelques user stories, vous pouvez les hiérarchiser dans le backlog. Dans Jira, vous classez ou hiérarchisez vos stories par glisser-déposer, dans l'ordre où elles doivent être traitées.
Ce ne sont là que les stories de départ de votre projet. Vous continuerez à créer des stories pendant toute la durée du projet. En effet, l'agilité implique l'apprentissage et l'adaptation continus.
Étape 3 : Création d'un sprint
Créez votre premier sprint dans le backlog afin de pouvoir planifier le sprint.
Dans Scrum, les équipes prévoient de réaliser une série de user stories ou d'autres tâches 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.
Étape 4 : Réunion de planification de sprint
Au début d'un sprint, vous devriez organiser la réunion de planification de sprint avec le reste de votre équipe. Cette cérémonie garantit la réussite du sprint dans son ensemble et pour toute l'équipe. Durant cette réunion, l'équipe au complet discute de l'objectif du sprint et des stories dans le backlog produit hiérarchisé. L'équipe de développement crée des tâches détaillées et estime les stories ultra prioritaires. Elle s'engage ensuite à achever un certain nombre de stories durant le sprint. Ces stories et le plan pour les achever deviennent ce que nous appelons le backlog de sprint.
Indiquez des estimations de story point pour vos stories en ajoutant un nombre dans le champ Estimation de story point. Vous pouvez aussi ajouter plus de détails aux stories ou cliquer sur l'icône Créer une sous-tâche afin de subdiviser davantage le travail de la story.
Lorsque vous avez fini, faites glisser les stories dont vous avez convenu durant la réunion de planification du sprint dans le sprint que vous venez de créer. C'est votre backlog de sprint.
Participants obligatoires : équipe de développement, Scrum Master, Product Owner
Quand : au début d'un sprint.
Durée : généralement deux heures par semaine d'itération (par exemple, un sprint de deux semaines démarre par une réunion de planification de quatre heures). La réunion se termine lorsque son objectif a été atteint.
Objectif : planifier le travail du sprint. L'équipe convient de l'objectif du sprint et du backlog de sprint.
Lors de la création d'un sprint, le Product Owner identifie généralement un objectif de sprint. Celui-ci propose un thème pour le travail à réaliser dans le sprint. Un objectif de sprint offre par ailleurs une certaine flexibilité quant au nombre de stories achevées dans un sprint. Un sprint est considéré comme une réussite si son objectif est atteint.
Les équipes de développement traditionnelles réalisent leurs estimations en temps : jours, semaines, mois.
En revanche, beaucoup d'équipes Agile 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.
Les estimations vous aideront à é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.
Étape 5 : Lancement du sprint dans Jira
Nommez le sprint. Certaines équipes le nomment 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 démarrent 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.
Ajoutez l'objectif de sprint tel que convenu lors de la réunion de planification du sprint.
Dès que vous commencez votre sprint, vous serez dirigé vers l'onglet Sprints en cours du projet.
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é !
Si vous utilisez le modèle Scrum géré par l'équipe, il sera qualifié de tableau.
Étape 6 : Organisation des stand-ups quotidiens
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.
Participants (principalement) : l'équipe de développement.
Quand : une fois par jour, généralement le matin.
Duration: No more than 15 minutes. Don't book a conference room and conduct the standup sitting down. Standing up helps keep the meeting short!
Objectif : le stand-up quotidien a pour but d'informer rapidement tous les participants de ce qui se passe au sein de l'équipe et de planifier le travail du jour. 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 actifs 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.
Étape 7 : Affichage du graphique Burndown
Il est réellement judicieux de consulter le graphique Burndown pendant un sprint. Dans Jira, le graphique Burndown montre la quantité de travail réelle et estimée à effectuer dans un sprint Le graphique Burndown est automatiquement mis à jour par Jira lorsque vous achevez des tâches Pour l'afficher, cliquez sur Reports (Rapports) dans la barre latérale, puis sélectionnez Burndown Chart (Graphique Burndown) dans la liste déroulante des rapports
Un graphique Burndown présente la quantité de travail estimée et réelle pour un sprint. L'axe horizontal (x) d'un graphique Burndown indique le temps, tandis que l'axe vertical (y) indique généralement les story points.
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.
- 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 8 : Affichage du rapport de sprint
À tout moment pendant ou après le sprint, vous pouvez consulter le rapport de sprint pour surveiller le sprint.
Le rapport de sprint inclut le graphique Burndown et répertorie les tâches terminées, les tâches en cours et toute tâche ajoutée après le lancement du sprint.
Étape 9 : Réunion de planification de sprint
The sprint review, or sprint demo, is a sharing meeting where the team shows what they've shipped in that sprint. Each sprint usually produces a working part of the product called an increment.
Riche en commentaires sur le projet, cette réunion inclut une session de brainstorming pour aider à décider que faire ensuite.
Participants (principalement) : l'équipe de développement, le Scrum Master et le Product Owner.
Facultatif : les parties prenantes.
Quand : généralement, le premier jour du sprint.
Durée : généralement, deux heures pour un sprint de deux semaines.
Objectif : inspecter l'incrément et mettre à jour le backlog produit de façon collaborative.
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 ?
É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.
Participants : l'équipe de développement, le Scrum Master et le Product Owner.
Quand : à la fin d'une itération.
Durée : généralement, 90 minutes pour un sprint de deux semaines.
Objectif : l'équipe se passe elle-même au crible, y compris ses processus, ses outils et ses interactions. Les domaines d'amélioration sont souvent ajoutés au backlog du sprint suivant.
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 : Achèvement du sprint dans Jira
Vous devez le réaliser à la fin du sprint.
Si le sprint comporte des tickets non terminés, vous pouvez :
- les déplacer vers le backlog ;
- les déplacer vers un futur sprint ;
- les déplacer vers un nouveau sprint, que Jira créera à votre place.
Étape 12 : Répéter depuis l'étape 2
À 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 réalisé les étapes ci-dessus, passez à l'article : Comment utiliser les pratiques Scrum avancées grâce à Jira.
