Scrum board complet – nos astuces

Scrum board (tableau scrum), un des piliers de la transparence

Faire un scrum board (tableau 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.

Scrum board / Kanban de base

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

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 sur le scrum board (tableau scrum) ?

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.

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.

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.

Les étapes Done intermédiaires dans le scrum board

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é. C’est souvent comme ça qu’on va créer ses workflow.

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.

Des « User-Story » complètes pour le Scrum Board

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.

Nous mettons sur notre post’it, un résumé de notre « User-Story ». Ici, on a « 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 que vous utilisez). Cela permet de retrouver facilement 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 scrum board (tableau scrum)

Pour avoir un board ultra complet, je vous conseille d’y ajouter des graphs dont certains sont assez connus du grand public. Voici quelques exemples possibles :

• Burndown Chart
• Burnup Chart
• Donuts sur les Impediment
• Tableau des congés prévisionnels de l’équipe
• Graphs d’évolutions.

D’autres astuces pour votre scrum board

Voici quelques astuces sympa pour vos scrum board que je vous partage.

Des icônes représentatives

Je peux vous conseiller de faire des icônes pour représenter par exemple des user-stories bloquées ou prioritaires.

Dor and Dod

Il est parfois bien pratique de rajouter les definitions of done et definition of ready sur les scrum board. Voici un exemple :

Et vos idées pour un scrum board (tableau scrum) ?

Vous avez également expérimenté d’autres choses sur votre scrum board mural ? Je serais ravi de partager vos retours d’expérience sur les scrum board.

J’ai rapidement compris que le scrum board était 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é.

Lien utile lié au scrum board :

Make a complete scrum board
Board physique VS board numérique – lequel choisir ?