Donnez un nom à votre projet, une clé (un identifiant simple qui définira l’URL du projet) et décidez de sa visibilité : tout le monde a accès à un projet public alors que seuls ses membres ont accès à un projet privé.
Lorsque vous créez un projet, vous obtenez toutes les autorisations sur celui-ci, ce qui équivaut à être Product owner et ScrumMaster.
Si vous avez déjà créé une équipe, vous pouvez ensuite la choisir. Sinon, vous pouvez en créer une nouvelle en saisissant un nouveau nom et en cliquant dessus dans la barre de recherche. Si vous créez une nouvelle équipe, vous y serez automatiquement affilié en tant que ScrumMaster et vous pourrez ajouter de nouveaux membres. Sinon les membres sont déjà définis et ne peuvent pas être modifiés ici, vous pouvez donc passer à la section suivante.
Equipe: Dans une nouvelle équipe, vous pouvez rechercher un nouveau membre dans la barre de recherche et choisir son rôle:
Membres du projet: Vous définirez ici les Product Owners (PO) et les Stake Holders (SH) de votre projet:
Un utilisateur peut être à la fois ScrumMaster et Product Owner afin d’obtenir toutes les autorisations sur le projet. Il s’agit de la seule combinaison rôle d’équipe / rôle de project autorisée, iceScrum empêche d’autres combinaisons. Un Membre d’équipe ne peut pas être ajouté comme Product Owner, vous devez d’abord le passer ScrumMaster.
Une fois que vous avez défini votre équipe, vous pouvez passer à l’étape suivante. Pour plus d’informations sur les rôles, reportez-vous à la documentation: Roles, teams & projects.
Les pratiques par défaut sont bien adaptées pour commencer, gardons-les pour le moment.
Enfin, vous pouvez définir le cycle de vie et démarrer la première release. Par défaut, les sprints durent 2 semaines (14 jours). Si vous cochez la case Créer la première Release et ses sprints, l’assistant suggère que le premier sprint commence le jour de la création du projet. Une release est prévue, avec une durée par défaut de 3 mois, à partir du jour de la création du projet. Vous pouvez également définir une vision la vision de cette release : ce à quoi devrait ressembler votre produit à la fin de la release.
Après cette dernière étape, la création du projet est lancée. Allons voir ce que cela donne !
Vous pouvez maintenant consulter le résultat dans la vue Planning qui a été initialisée avec la création de la première release et de ses sprints, en fonction des durées par défaut, à l’étape 4 de l’assistant. Bien sûr, les dates de release peuvent être modifiées ultérieurement et d’autres releases peuvent être créées.
La vue Planning montre la durée de vie d’un produit à long terme, présentée le long du calendrier, avec les releases successives et les sprints contenus dans ces releases.
Une feature est un service ou une fonctionnalité de votre produit qui apporte de la valeur à un utilisateur final. C’est un élément de haut niveau qui est divisé en stories. Vous trouverez plus d’informations sur les features dans la documentation dédiée.. Si vous êtes plus familier avec ce terme, les features sont souvent équivalentes à ce que certain appellent « epic » ou « épique ».
Dans iceScrum, les features ont leur propre vue, le backlog de features. Pour un nouveau produit, une approche descendante est souvent utilisée, en commençant par la définition de features.
Une couleur différente peut être utilisée pour chaque feature afin de faciliter l’identification des stories associées à cette feature. Il est également possible d’utiliser la fonction valeur pour décrire la valeur ajoutée de la feature, lui donner un type (fonctionnel / architectural), une balise, une description et aussi ajouter des notes.
Lorsque vous ajoutez une nouvelle story vous pouvez définir son type (story d’utilisateur, technique ou de défaut), la décrire et éventuellement l’associer à une feature mais également lui attribuer une valeur commerciale et/ou la rendre dépendante d’une autre story.
Lors du démarrage du projet, le backlog Bac à sable peut contenir des douzaines d’éléments. C’est le bon endroit pour compléter les connaissances sur une story. Tous les participants peuvent contribuer et ajouter leurs commentaires/notes dans la vue détaillée de la story.
Dès qu’il pense qu’une story est suffisamment détaillée, le Product Owner l’évalue. S’il pense qu’elle apporte de la valeur, il l’accepte comme story, ce qui la déplace automatiquement dans le bac Backlog de la vue Backlogs. Vous pouvez accepter une story dans son panneau descriptif en cliquant sur le bouton « Accepter », ou directement sur le post-it si vous cliquez sur « … ».
Astuce : Pour accepter/sélectionner/effacer plusieurs stories à la fois activez la fonction de sélection multiple via les raccourci clavier (shift ou ctrl + click).
Le product Owner définit les priorités en déplaçant les post-its. La plus haute priorité se trouve en haut à gauche de la vue. Grâce au bouton Classement, vous pouvez trier automatiquement vos histoires par type, effort, fonctionnalité, date de création, etc …
L’équipe estime les stories, généralement par le biais d’une session de planning poker. Les estimations sont saisies par un membre de l’équipe ou par le ScrumMaster, en cliquant sur le ? sur le post-it ou en le sélectionnant dans le panneau des détails.
Par défaut, l’évaluation peut être effectuée selon la suite de Fibonacci, cela peut être modifié en modifiant les pratiques du projet. Pour se faire allez dans le menu déroulant du projet (cliquez sur l’icône icescrum en haut à gauche de votre écran), cliquez sur Configurer puis sur Pratiques.
Pratique avancée : Vous pouvez estimer vos stories par comparaison avec vos autres stories estimées. Pour ce faire, cliquez sur le bouton juxtaposé aux champs Valeur et/ou Effort. Une modale apparaîtra instantanément avec les stories que vous avez précédemment estimées et vous donnera un aperçu de ces stories. Cet aperçu vous rappellera les expériences précédentes et vous aidera à faire la bonne estimation.
La planification de la release consiste en l’association des stories du Backlog aux sprints de la release. Seules les stories estimées sont candidates à la planification et les sprints doivent également être créés. Il sera possible ultérieurement de modifier l’association, par exemple en déplaçant une story d’un sprint à un autre.
Une fois que les sprints de la release sont créés et que le Backlog est estimé et priorisé, la planification peut être effectuée. Avec iceScrum, la planification de la release peut être effectuée manuellement ou automatiquement (iceScrum prend en compte la vélocité et la priorité pour la planification automatique). Puisque la vélocité n’est pas mesurée au début, il vaut mieux faire une planification manuelle.
Une façon simple de planifier une story manuellement consiste à ouvrir la vue Planning et à cliquer sur «…» puis sur Planifier. Un nouveau panneau affichant toutes les stories estimées apparaîtra et vous pourrez sélectionner toutes celles que vous souhaitez planifier. Ensuite, cliquez sur sur le bouton Planifier. La liste des stories apparaissant dans la vue Planning est la liste ordonnée des éléments estimés du Backlog de produit.
Pour vous aider à commencer, la première release est lancée automatiquement.
Pour planifier vos stories dans un nouveau sprint, allez sur la vue Planning et cliquez sur Planifier. Une modale apparaîtra, affichant toutes les stories estimées que vous avez dans votre Backlog de produit. Sélectionnez les stories en cliquant sur chacune de celles que vous voulez ajouter dans votre sprint, puis cliquez sur Planifier à nouveau. Maintenant vous verrez vos stories planifiées quand vous allez sur la vue Tâches.
La vue Tâches affiche un tableau avec des marges colorées représentant les stories planifiées et des post-its représentant les tâches.
Lors des réunions de planification de sprint, au cours desquelles les membres de l’équipe identifient les tâches, il est possible de créer des tâches récurrentes qui peuvent être copiées sur les sprints et des tâches urgentes qui n’appartiennent pas à une story.
Lorsque toutes les tâches sont créées, avec leur Temps restant éventuel et une personne désignée comme responsable, le sprint peut être activé pour matérialiser l’engagement convenu lors de la réunion.
Félicitations, vous êtes maintenant prêt à activer votre sprint ! Vous pouvez activer votre sprint depuis la vue Planning en cliquant sur Lancer le sprint.
Ou encore depuis la vue Tâches :
Attention, une fois le sprint activé vous ne pouvez plus revenir en arrière !
Les membres de votre équipe pourront alors mettre à jour l’état de leurs tâches en les faisant glisser vers la colonne En cours et Terminé et mettre à jour leur Temps restant. Bien sûr, d’autres tâches peuvent être créées si nécessaire.
Une dernière astuce : Les boutons bleus. Dans toutes les vues d’iceScrum v7, vous avez de nombreux boutons sur lesquels cliquer. Certains, souvent synonymes d’une action, sont bleus. Lorsqu’un bouton bleu se trouve à côté du signe « … », cliquer dessus vous mènera à l’action logique suivante, selon votre contexte, contenu dans la liste des actions que vous verriez si vous cliquiez sur « … ». Par exemple, si vous allez dans votre Bac à sable, un bouton bleu vous proposera de créer une nouvelle story. Ensuite, si vous cliquez sur cette story nouvellement créée, un bouton bleu vous proposera de l’accepter, ce qui est la suite logique pour une nouvelle story. Et une fois celle-ci acceptée le même bouton bleu vous proposera de l’estimer, etc… Bref, gardez à l’esprit que le bouton bleu est souvent le futur logique de vos items dans iceScrum !