Comme moi, vous avez peut-être rencontré la problématique au sein de votre équipe, lorsque vous commencez à découper vos éléments de backlogs en tâches, au moment où vous réalisez ce découpage, le résultat attendu et le plan d’action pour chacune d’entre elles est très clair. Mais la nuit ne porte pas toujours conseil, et quelques jours plus tard, l’une des tâches est traitée, une relecture va être faite, et là, c’est le drame : « mais tu as oublié de gérer le cas xyz 😲 ». Ou alors, « mince, on avait dit quoi déjà ? ».

Ce sont en tout cas des situations que j’ai vécues. Pour répondre à cette problématique, nous avons décidé dans l’équipe de mieux détailler le contenu de nos tâches et d’appliquer un certain formalisme dans ce niveau de détail, cela au travers de l’acronyme SMART. Voyons donc concrètement en quoi cela a consisté.

Qu’est-ce que SMART ?

Non, je ne parle pas de celui-là de SMART

SMART est un acronyme pour (traduit en français) :

• Spécifique
• Mesurable
• Atteignable
• Réaliste/Raisonnable
• Temps limité

Celui-ci est un pense-bête pour aider dans la définition d’objectifs clairs et consistants. Mais là où cela devient intéressant, est que celui-ci s’applique également très bien dans le cadre d’un découpage de récits utilisateur en tâches. Sur ce point-là, je n’invente rien, cela vient d’un promoteur de la méthode eXtreme Programming, Bill Wake, à qui revient d’ailleurs la paternité de l’acronyme INVEST (celui-ci, on l’utilise pour les User Stories ou éléments de backlog). Il en parle dans un article intitulé : INVEST in good stories and SMART tasks.

Appliquer SMART dans la définition de tâches

Comment je l’ai mis en œuvre

Dès le départ, j’ai proposé un cadre très formel à l’équipe et très simple, qui a consisté à tout bêtement construire un tableau où chaque ligne reprend une lettre de l’acronyme. Ce tableau est rempli pour chacune des tâches, de manière systématique, de cette manière-là :

• S : une description à la fois synthétique et précise de ce qui est attendu dans cette tâche
• M : le ou les cas de test qui vont permettre de valider que cette tâche est terminée et conforme à ce qui est attendu.
• A : le plan d’action prévu pour l’accomplissement de cette tâche
• R : « OK »
• T : Un temps estimé à passer sur la réalisation de cette tâche (0.5j, 1j, 2j).

Rentrons un peu plus dans le détail et explorons chacun des points.

S pour spécifique

Image par athree23 de Pixabay

Ce point-là peut paraitre le plus simple à remplir, mais en réalité, il amène déjà à se poser des questions. Le but étant d’arriver à décrire le plus succinctement possible ce qui est attendu tout en étant suffisamment précis afin qu’il n’y ait pas de doute. Au delà du fait de formaliser le besoin, cela permet déjà d’ouvrir la réflexion et donc avoir les éléments en tête pour construire la suite.

M pour Mesurable

Image par Horst Winkler de Pixabay

Ici, on y décrit un ou plusieurs cas de test, assez simple, permettant de valider que le contenu du S est bien respecté. Bien souvent, cela correspond en fait à l’un des critères d’acceptation que l’on a défini au niveau de la User Story, mais cela peut également être quelque chose de très simple lorsque les critères d’acceptation ne peuvent se vérifier que par l’achèvement de l’ensemble des tâches.

A pour Atteignable

Image par athree23 de Pixabay

Je dois avouer que sur ce point-là, au départ, nous étions assez perplexes pour savoir comment le remplir. On se contentait de réfléchir à ce que l’on a écrit précédemment, et se dire « est-ce que c’est vraiment réalisable ? ». On écrivait alors simplement « OK ».

Par la suite, un besoin a émergé de l’équipe : Assez fréquemment, l’équipe était bloquée dans la réalisation, ne sachant pas par quel bout prendre le code et se retournait vers moi pour avoir un peu de connaissance et d’historique (6 ans d’ancienneté alors que le reste de l’équipe découvrait le produit depuis quelques semaines à peine). Je devenais alors un point de blocage. Pour éviter ça, nous remplissions alors cette case avec un plan succinct des étapes à faire pour mener la tâche à son terme. Cela pouvait par exemple se traduire par la classe, la méthode à modifier. Parfois de manière un peu plus globale : quelles sont les pages impactées. 

R pour Raisonnable

Image par Gerd Altmann de Pixabay

Tout comme le A, il s’agit ici simplement d’un point d’étape où l’équipe se pose et réfléchit quelques secondes. Est-ce que ce que l’on a décrit jusque-là est vraiment aligné avec la demande initiale formulée dans la User Story ? En effet, il est parfois assez facile de dériver, imaginer qu’il est nécessaire de mettre en place tout un tas de choses. Mais lorsque l’on se remet dans le contexte du besoin utilisateur, on peut finalement se rendre compte qu’il ne s’agit de de confort, ou que l’on tape à côté. Dans les faits, il nous est rarement arrivé d’en être à cette étape-là et se dire que la tâche n’est pas pertinente. Bien souvent, on s’en aperçoit lors de la rédaction du point M, où l’on se rend compte que les cas de tests ne sont pas alignés avec les critères d’acceptation.

Donc ici, pas de rédaction, on écrit simplement « OK » pour formaliser le fait que l’on a réfléchi à ce point-là.

T pour Temps limité

Image par Gerd Altmann de Pixabay

En tant qu’agiliste, on aime beaucoup les boites de temps. Et c’est donc l’occasion d’en placer une. Malgré tout, c’est également un point qui a été l’objet de nombreux débats. Je me dois donc de vraiment détailler ce point-là afin qu’il ne soit pas mal interprété.

Il ne s’agit pas ici de chiffrer le temps que l’on va passer à développer le contenu de cette tâche. Ce n’est pas non plus le temps que l’on va passer pour emmener la tâche jusqu’au « terminé ». Ici, l’équipe va plutôt essayer d’identifier un risque. L’idée étant de se poser la question suivante : « à partir de quand l’alerte doit-elle être levée si le ticket est toujours en cours de réalisation ? ». Je le reprécise donc, il ne s’agit pas ici d’un engagement de temps pour planifier la réalisation des tickets, mais bien d’un indicateur pour se protéger en cas de difficultés.

D’ailleurs, à cet effet, si vous utilisez JIRA, vous avez la possibilité d’activer un indicateur sur vos cartes qui pourra vous aider dans cette démarche (cf-ci-contre).

Les valeurs autorisées : 0.5j, 1j, 2j.

Et si la tâche consiste simplement à exécuter un script SQL préparé à l’avance, je ne peux pas mettre 5 minutes ? Non. je le répète, on définit ici un seuil d’alerte et non une estimation chiffrée. Donc si l’on met 0.5j et que l’on fait ça plus rapidement, alors tant mieux.

Inversement, et si ma tâche nécessite plus de 2 jours ? Alors il faut redécouper. Définir des tâches trop longues est un anti pattern, qui induit alors un effet tunnel. Il devient très compliqué de suivre un avancement lorsque les tickets n’ont pas l’opportunité de se déplacer régulièrement dans le board, les potentielles alertes sur des difficultés sont levées trop tard, … D’ailleurs, le Scrum Guide préconiserait plutôt des tâches de moins d’une journée. Je me répète, il ne s’agit pas de définir une durée figée. Le temps réel peut dépasser la limite fixée initialement, dans le cas où certaines problématiques ont surgi durant la réalisation. L’important étant de lever l’alerte à l’approche de l’échéance, permettant ainsi d’engager une action pour débloquer la situation. Par exemple, nous utilisions des gommettes rouges que l’on collait sur le ticket pour attirer l’œil et indiquer que les efforts de l’équipe devaient se concentrer sur ce ticket qui est en souffrance.

Quelques exemples concrets

Je vais vous livrer ici quelques exemples réels (anonymisés tout de même sur les parties potentiellement sensibles) afin de vous rendre compte de la forme que cela prend :

Un premier exemple très simple. Un S qui rappelle l’objectif, un M très succint et un A avec un plan d’action très succint lui aussi, sachant que nous avons exploré ensemble le code afin de nous assurer de l’emplacement des points d’entrée du code à modifier. 

Nous avons ici un plan d’action un peu plus détaillé. On notera par exemple que le nom des vues ou des méthodes créées sont définis à l’avance. Cela permet notamment lorsqu’il existe des dépendances entre les tâches, que tout le monde soit bien aligné sur la nomenclature utilisée, afin de ne pas avoir de mauvaises surprises par la suite.

Parfois, le plan est difficile à établir à l’avance, donc une tâche avec assez peu de détails. Malgré tout, l’équipe a échangé sur ce plan d’action et l’a formalisé.

Au contraire ici, on a quelque chose de très détaillé, où une solution de « secours » a été envisagée dans le cas où la première ne pourrait pas être appliquée, avec l’emplacement du code dont le développeur pourrait s’inspirer. De cette manière, au moment où la tâche sera entamée, l’équipe ne se retrouvera pas bloquée si celui qui connait le produit n’est pas disponible.

Comment cela a été vécu ?

Au départ, cela peut sembler être une lourdeur de mettre un tel formalisme dans la définition des tâches. Mais, cela avait été une demande de l’équipe, pour les raisons suivantes :

• L’équipe était novice sur le produit (présente depuis quelques mois seulement dans l’entreprise) et ne maitrisait pas l’environnement technique/métier
• Souvent bloquée car ne sachant pas forcément où aller, j’étais alors un point de blocage car j’avais l’historique nécessaire (plus de 6 ans de boite)
• Des questions pouvaient émerger après le démarrage car la partie technique n’avait pas assez été étudiée et pouvait remettre en cause l’US en elle-même

La mise en place de ce formalisme a donc été une expérimentation qui a par la suite été adoptée, puisqu’elle s’est poursuivie, et a même été améliorée (#empirisme #ameliorationcontinue).

Encore mieux, j’ai demandé le feedback à ceux qui l’ont vécu, voici leurs retours, en toute transparence :

Le formalisme SMART avait ses avantages et inconvénients, enfin en inconvénient, je dirais juste que je ne voyais pas vraiment l’utilité de S et R dans l’utilisation qu’on en faisait, mais il peut sans doute être utile de se poser la question de la finalité de la tâche avant de la commencer.

Quant aux M, A et T, le temps qu’on y passait me parait avoir été un très bon investissement puisqu’il permettait d’exécuter la tâche plus rapidement, d’avoir une bonne idée de ce qu’il fallait faire, et d’éviter d’oublier des trucs en cours de route.

Eric

Ceci m’a aidé beaucoup car je ne perdais pas de temps à chercher le processus.

Dans l’équipe xxx, de mémoire, ils n’étaient pas chauds pour l’appliquer. Cela me pénalisait car je ne connaissais pas le module xxx.

Maintenant, dans la nouvelle équipe, j’aimerais bien l’appliquer car je connais mieux le module zzz que les 2 autres développeurs.

Cyril

On l’applique d’une manière non formalisée (Pas de SMART pur) sur les grosses stories et personnellement, je trouve que c’est suffisant.

C’est un bon outil mais qui n’est pas forcément pertinent sur chaque story. Uniquement sur celles qui commencent à être complexes, ou alors qui sont suffisamment grosses pour être partagées par au moins 2 développeurs. On le fait aussi sur des stories qui concernent de nouveaux sujets.

Rémi

Conclusion

J’ai présenté ici l’acronyme SMART, et la manière dont j’ai pu le formaliser dans mon expérience. Globalement, cela à permis de bien aider l’équipe, mais il faut bien garder en tête, que cela à aidé l’équipe dans le contexte dans lequel elle était à ce moment-là. Il n’est donc pas question au travers de cet article de vous présenter un outil miracle qui va vous apprendre à faire des tâches parfaites.

D’ailleurs, est-ce que votre équipe a réellement besoin de faire du découpage en tâches ? Si elle en fait, a-t-elle réellement besoin d’écrire un contenu détaillé pour chacune des tâches ? Si la réponse à ces deux questions est oui, alors, vous avez ici une piste à explorer. Vous pourriez vous l’approprier à votre manière, vous en servir simplement juste pour un démarrage, ou alors l’améliorer, la simplifier, … N’hésitez pas à laisser un commentaire si tel était le cas, ou si vous souhaitez partager la manière dont vous organisez vos tâches dans vos équipes.

Pour aller plus loin

L’article de Bill Wake dans lequel l’acronyme SMART est évoqué pour les tâches

Une autre proposition de définition pour l’acronyme SMART

Et au passage, merci à mes anciens collègues qui m’ont gentiment fait part de leurs témoignages, ainsi qu’aux membres de la communauté Scrum Life,  qui m’ont également aidé dans l’écriture de cet article.