Détourner l’utilisation d’un Scrumboard

Nous avons à notre disposition une multitude d’outils pour suivre l’avancement de nos projets. Pour ma part, j’ai une préférence pour le scrumboard.

Or je travaille souvent sur plusieurs projets en même temps et le temps consacré à la partie opérationnelle n’est pas négligeable.

Pour ne pas multiplier les outils et conserver celui que j’affectionnais, quelques modifications s’imposaient.

Le but n’est pas de convaincre de l’efficacité de cette utilisation par rapport à une autre mais de montrer qu’il est tout à fait possible de détourner n’importe quel outil pour l’adapter à son besoin.

Le scrumboard

Un des éléments de communication (entre autres applications) des équipes scrum est le scrumboard, ou tableau des tâches.

Il s’agit d’un tableau découpé en trois parties (à faire, en cours, fait) sur lequel on appose des post-it.

Chaque post-it est attribué à une tâche du sprint (itération d’un projet scrum) en cours.

En fonction de l’état d’avancement d’une tâche, on déplace le post-it.

Simple mais d’une redoutable efficacité.

En un coup d’œil, vous avez une vue sur l’avancement de votre sprint.

Variante du scrumboard

A la base outil de communication, j’en ai fait mon outil de gestion de tâches.
En le modifiant quelque peu. C’est mon tableau de bord pense bête.

Contrairement aux autres (tableaux de bord dans mon ordinateur) celui ci trône dans mon bureau à un endroit ou je passe régulièrement.

Je le vois donc plusieurs fois par jour.
 Je ne le place pas en face de moi afin de ne pas l’éliminer inconsciemment de mon champ de vision.

Avez-vous remarqué comme on fini par ne plus prêter attention aux post-it collés autour de son écran d’ordinateur ?

Mais pour mon usage, je lui trouvais deux faiblesses:
- Il n’y a pas d’échéancier hormis la date de fin du sprint.
- Il ne comporte pas d’état d’avancement, rien n’indique le pourcentage de réalisation d’une tâche.

L’un des avantages du premier point est de voir le temps passé et restant : il est plus facile de se situer dans le projet.

Le second avantage et de pouvoir mettre en place des jalons intermédiaires, ce qui s’imposait: tous les projets ne sont pas en mode agile et le Scrum n’est pas applicable en opérationnel (bien que le Lean soit assimilable au mode agile… mais ceci n’est pas le sujet ici).

L’avantage du second point est de visualiser le « reste à faire » de chaque tâche (j’utilise plutôt des groupes de tâches pour simplifier la lecture).

Les deux combinés donnent un aperçu rapide de ce qui reste à faire et le temps disponible pour terminer.

Il y a aussi des « effets psychologiques ».

Visualiser son avance ou le respect des délais est toujours motivant.
Par contre visualiser un retard oblige à se démener pour respecter l’échéance.

Et tout ça, en un seul coup d’œil.

Présentation de mon scrumboard

Voici comment se présente le haut de mon scrumboard

Un “sprint” d’un mois maximum, décomposé en semaine.
Les jours écoulés sont en rouge.

Les chiffres cerclés représentent des jalons, dates de « livraison » de certaines tâches.

Limiter à un mois restreint le nombre de tâches à réaliser et donc le nombre de post-it sur le tableau.

Crouler sous les post-it s’assimile à crouler sous le travail… pas très engageant n’est ce pas ?

Limiter le nombre d’action permet aussi de ne pas multiplier le nombre de problèmes simultanés.

En dessous, je place l’état d’avancement de chaque groupe de tâches.

Devant chaque groupe, j’indique le jalon associé.

Après chaque groupe, un graphique sur l’avancement du groupe de tâches.

Si un groupe est annulé ou reporté, je l’indique ici.
Lors de la visualisation, il s’agit de ne pas penser que la tâche est en retard.

Ensuite viennent les groupes de tâches et les post-it.

Lors d’un sprint, toutes les tâches doivent être accomplies et les participants se consacrent entièrement au projet.

Ici s’arrête donc le parallèle avec un véritable scrumboard : je peux me permettre de remettre certaines tâches et je gère plusieurs projets simultanément.

J’ajoute donc deux sections supplémentaires : « pour prochaine échéance » et « ajout pour échéance ».

Pour prochaine échéance


N’importe quel évènement peut survenir, y compris l’annulation ou le report d’une tâche.

J’utilise cette zone pour les tâches annulées ou reportées.

J’indique toujours les raisons en face du post-it.

Je décide de l’avenir de la tâche en fin de sprint, et pas avant, afin de me libérer l’esprit et ne pas perdre de temps.

Ajout pour échéance

Cette zone tampon est utilisée pour une tâche ajoutée pendant la période fixée.
Sur le moment, il n’est pas toujours possible de prioriser ou placer celle ci dans un groupe.

Elle reste dans cette zone jusqu’à ce que je décide de la traiter ou de la planifier pour une date ultérieure (dans ce cas là je la déplace dans la zone « pour prochaine échéance »).

Et pour finir, une dernière partie.

Ce sont les tâches hors périmètre du projet (opérationnelles par ex.) pouvant mettre en danger les groupes de tâches principales.

Certes, elles ne sont pas prioritaires, mais doivent être réalisées et sont chronophages.

Cette section me permet de garder un œil sur celles-ci et de les gérer en fonction de l’état d’avancement, ou contraintes, de mes premiers groupes de tâches.

Voici mon scrumboard complet: