Faire un board scrum complet

Un des piliers de la transparence

Faire un board scrum très complet est un atout majeur en Agile pour amener à une transparence totale. Si la transparence permet aux autres équipes de pouvoir suivre plus facilement l’avancement des travaux, elle permet aussi à l’équipe elle même de ne pas se retrouver dans des situations de confusion : par exemple ne pas prendre un ticket déjà traité par un autre de l’équipe discrètement.

Voici comment faire un “Board Djude” (ma façon de nommer ces boards complets) qui vous aidera dans votre organisation.

Board scrum / Kanban de base

De base quand on réalise un board scrum, on part souvent du tableau classique du Kanban. Nous allons donc suivre cette règle et alimenter notre tableau au fur et à mesure.

Tableau Kanban
Tableau Kanban

On a ainsi mis 4 colonnes classiques : Todo, In progress, Test et Done. C’est simple mais c’est souvent pas suffisant en Scrum même si c’est le tableau le plus couramment utilisé dans les équipes. C’est ce type d’éléments qui font qu’une équipe fait du “Scrum” ou du vrai “Scrum”.

La règle de ce tableau est assez simple, on avancera chaque “User-Story” (représentée par des post’it jaune, de gauche à droite durant le Sprint en cours.

Pour faire ce type de board sur les murs, les vitres fonctionne plutôt bien mais l’utilisation de papier kraft est encore mieux. Il ne faut pas hésiter à avoir du matériel pour faire de beaux board.

Qui fait quoi ?

Quand on voit ce board, la question peut vite se poser en effet. Est-ce que le ticket dans “in progress” est vraiment en cours de développement ou est-ce qu’il est libéré pour X raisons (bien qu’on sait que ce n’est pas bien de ne pas finir un ticket en cours) ? Est-ce qu’ils sont assez sur le ticket ou est-ce que je pourrais fournir mon aide ?

Pour cela, nous allons rajouter un élément important au tableau : les avatars. Chaque membre de l’équipe se fera un petit avatar et le positionnera sur la “User-Story” qu’il est en train de traiter.

Board Kanban avec avatars
Board Kanban avec avatars

Nous avons d’ailleurs rajouté des lignes horizontales afin de bien séparer les “User-Story” pour des raisons de visibilité.

Ici, nous voyons à présent sur quelles “User-Story” notre équipe travail. Cela peut également rassurer les équipes métiers qui peuvent en passant dans le bureau voir si leurs demandes avancent ou non.

User story et Tache technique en Scrum/XP

Dans des organisations comme en Scrum, il est souvent plus simple de séparer les “User-Story” et les tâches techniques (découpage technique des “User-Story”). Cette pratique est probablement moins utile dans une organisation Kanban.

Je vous propose de prendre des grands post’it pour représenter les “User-Story” et des petits post’it pour représenter des tâche techniques.

En suivant le résonnement précédent, nous allons donc fixer deux règles simples : une “User-Story” par ligne maximum et plusieurs tâches techniques possibles par ligne. La “User-Story” ne pourra aller dans les colonnes Todo et Done uniquement et les tâche techniques dans les colonnes Todo (par dessus la “User-Story si manque de place), In Progress et Test uniquement.

Si nous devons toujours tester une “User-Story” complètement terminée, nous ne mettons que les tâches techniques dans Test car en cas de test invalide, nous devrons rajouter des tâches techniques supplémentaires (correctifs). Donc par logique, les tests peuvent être réalisés uniquement quand toutes les tâches technique de la ligne sont dans la colonne Test.

Board Agile avec user-story et tâches techniques
Board Agile avec user-story et tâches techniques

Ajout de colonnes utile

Cette partie est plus complexe car chacun d’entre nous avons des contextes différents dans la création de nos applications. Cependant quelques propositions ci-dessous pourront vraiment vous être utiles.

Une colonne Parking

Il nous arrive à tous de devoir arrêter une tâche en cours pour X raisons : changement de priorité soudaine, on s’aperçoit qu’une “User-Story” n’était pas si complète après le début du développement, on veut aider un collègue en difficulté sur sa “User-Story” d’où l’abandon temporaire de la tâche en cours.

Pour cela, on ajoute une colonne Parking qui permet de mettre une “User-Story” qui a commencé à être prise en charge mais qu’on désire abandonner temporairement. La “User-Story” devra revenir sur sa colonne d’origine lorsqu’elle est reprise en charge par un membre de l’équipe.

Board Scrum avec une colonne Parking
Board Scrum avec une colonne Parking

Les étapes Done intermédiaires

Ajouter des colonnes intermédiaires “Done” peut-être très utile pour bien mieux situer la position des tâches techniques. Par exemple, si nous rajoutons une colonne “Dev Done” entre “Dev” et “Test”, nous sauront si les tests sont commencés ou non.

Ce type d’ajouts est vraiment utile pour avoir une très bonne lisibilité des Sprint en cours. Pour ceux qui maîtrisent des outils tels que Jira, cela leur sera très familié car c’est souvent comme cela qu’on va créer ses workflow.

Board Scrum avec une colonne Parking
Board Scrum avec des Dones intermédiaires

D’autres colonnes contextuelles

Votre entreprise et son contexte vous impose des étapes intermédiaires qui influent souvent votre organisation. Il n’y a pas de règles définies sur ces sujets car chaque contexte est différent.

Dans cet exemple, nous avons rajouté : Mise en production et Analyse comme étapes obligatoires de traitement mais c’est à votre équipe de définir ces colonnes complémentaires qui permettront d’améliorer encore plus votre board mural.

Board Scrum avec une colonne Parking
Board Scrum avec une colonne Parking

Des “User-Story” complètes

Faire des post’it complet et structuré vous permettra de renforcer la qualité de transparence de votre board. Voici mes grands conseils sur le sujet.

Post'it de User Story
Post’it de User Story

Nous mettons sur notre post’it, un résumé de notre “User-Story” qui serait dans ce cas “Bouton acheter en bleu” pour “En tant qu’acheteur, je souhaite avoir le bouton acheter en bleu”.

Nous mettons dans une couleur différente (le vert par exemple), la complexité donnée par l’équipe de développeur au ticket ; cette indication est essentielle sur les tickets pour travailler plus rapidement sur les différents reporting possibles.

Pour ceux qui gèrent les “Impediment” (perturbation), je conseille fortement de bien préciser par une icône IM en rouge que la “User-Story” est une perturbation.

En haut à droite, il est toujours utile de mettre l’identifiant de la demande (celui du logiciel dans lequel vous mettez vos demandes si c’est le cas) pour facilement retrouver le contenu des demandes en un coup d’oeil.

Cela peut paraître inutile à dire mais je ne l’ai pas toujours vu partout, je vous conseille de toujours utiliser la même façon d’écrire vos tickets pour des raisons de lisibilité.

Ajout d’indicateurs au board

Pour avoir un board ultra complet, je vous conseille d’y ajouter des graphs dont certains sont assez connus du grand public : Burndown Chart, Burnup Chart, Donuts sur les Impediment, Tableau des congés prévisionnels de l’équipe, Graphs d’évolutions.

Board avec reporting
Board avec reporting

Et vos idées ?

Si vous avez également expérimenté d’autres choses sur les board muraux, je serais ravi de partager vos retours d’expérience sur le sujet.

J’ai rapidement compris que les boards étaient souvent un élément clé du Scrum voire un pilier de son application. Pensez vraiment a bien faire votre board de façon complète car il sera à lui seul un gain de productivité.

2 Replies to “Faire un board scrum complet”

Laissez une réponse