Sketchnote : gérer un projet UX avec la méthode Agile

Gérer un projet UX en méthode agile : SCRUX

Pop in the UX

Si vous êtes familier des projets UX design, vous n’avez pas du passer bien loin de ceux qui ne jurent que par la méthode agile, ou sa dérivée : le scrum. Cette approche de gestion de projet très en vogue a toutes les raisons de nous intéresser. Organisée en périodes courtes pendant lesquelles l’équipe se concentre sur un seul objectif et fait des reportings réguliers, elle est reconnue pour faire aboutir les projets avec flexibilité. Quand l’UX vient à s’immiscer, cela donne « SCRUX », comme l’a employé l’américain Jack Josephy dans son article…et qui nous a bien inspiré. 

Le SCRUX en Sketchnote

C’est la première sketchnote qu’on ose publier. Forcément, on y a mis un peu (trop) de couleurs et un peu (trop) de temps. Espérons que vous y trouverez un bon résumé du concept.

Sketchnote : gérer un projet UX avec la méthode Agile

 

 

Quand utiliser la méthode SCRUM dans un projet UX ?

La méthode trouve tout son intérêt quand l’équipe UX ne travaille pas intimement avec les développeurs web. Il s’agit de livrer des prototypes « clé en main », prêts à être intégrés. Si le projet a le luxe de compter un développeur web, il devient plus intéressant de coder et tester rapidement en ligne les éléments au fil de l’eau, selon une démarche apparentée au lean UX.

Les rôles clés

  • Le product owner : chef de produit ou directeur, c’est lui qui peut prendre les décisions au nom de la société (ou se diriger vers les bons décisionnaires le cas échéant).
  • Le scrux master : il tient les ficelles du process et s’assure que tout le monde reste accroché.
  • L’équipe UX : dans l’idéal, elle regroupe a minima un chercheur UX, un ergonome féru d’Axure (ou autre, nous ne sommes pas exclusifs) et un graphiste.

Les sprints

Avant le début du projet, le scrux master se réunit avec le product owner pour définir les grands objectifs, et les prioriser en sprints : des périodes de 1 à 2 semaines répondant à un objectif unique, sur lequel peut se concentrer l’équipe.

Quelques exemples : designer le tunnel de conversion, le process de commande, réaliser le storyboard de l’expérience utilisateur cible, mener des tests utilisateurs, …

Les tâches

Un sprint comporte plusieurs tâches, priorisées. Il s’agit souvent d’une page ou d’une fonctionnalité précise à designer. Il est important d’estimer le temps de chaque tâche. Entre 2h et 16h. Si c’est moins, cela risque d’être trop insignifiant. Si c’est plus, il faut sans doute diviser la tâche en deux.

Le sprint board

Le scrux master tient à jour un tableau de bord, appelé le sprint board. Il peut être tenu sur un paperboard, avec des post-its, ou sur des outils en ligne tels que Trello.

  • Product backlog : ici, sont assignées toutes les tâches du projet.
  • Sprint backlog : les tâches pour le sprint en cours sont rangées par ordre de priorité (de haut en bas), tel que l’a décidé le product owner. Il est important de faire correspondre le temps total des tâches avec le temps de ressources humaines disponibles pour la période.
  • En cours : l’équipe prend en charge les tâches et les déplace au fil des colonnes.
  • Bloqué : la colonne recense les tâches qui ne peuvent pas aboutir sans intervention du product owner.
  • À valider : toutes les tâches accomplies du sprint arrivent ici. Le product owner les passe en revue à la fin du sprint.
  • Terminé : une fois validées par le product owner, les tâches sont « terminées ».

Les réunions

La méthode prévoit 4 types de réunions :

  • Sprint planning : première réunion du sprint, durant laquelle le product owner et le scrux master définissent et priorisent les tâches du sprint, en adéquation avec l’objectif.
  • Stand up quotidien : les membres de l’équipe, en présence du scrux master, ont 1 minute chacun pour informer de leurs avancées de la veille et du programme de la journée. Ils soulèvent les points de blocage s’il y en a, que le scrux master gère en dehors de la réunion.
  • Sprint review : en fin de sprint, l’équipe présente son travail au product owner. Les feedbacks ayant été quotidiens, il ne doit pas y avoir trop de surprises. La réunion peut se solder par le passage au sprint suivant, ou a une dernière phase de modifications.
  • Retrospective : l’équipe, sans le product owner, pointe du doigt ce qui a bien marché durant le sprint et ce qui pourrait être amélioré pour le suivant.

Comment s’assurer du succès de la méthode ?

Pour implémenter le scrux, les règles d’or sont les mêmes que pour la méthode agile :

  • Un client acquis à la cause : le client doit être convaincu du bien fondé de la méthode et vous faire confiance. Certes, il n’aura pas de cahier des charges d’avant projet (qu’il ne lit d’ailleurs jamais en entier), mais il aura son produit livré du mieux possible, à temps, et dans le budget.
  • Des décisionnaires impliqués : pas de secret, si les prises de décisions ne sont pas réalisées quotidiennement, le projet stagne.
  • Une décision centralisée : que vous n’ayez pas à contacter 10 interlocuteurs avant d’avoir votre validation.
  • L’intervention de spécialistes : à prévoir en amont du projet. Les fins connaisseurs d’un sujet (juriste, référenceur, acrobate des bases de données, …) doivent être appelés à participer dans les bonnes réunions.

Le mot de la fin

C’est surtout le mot SCRUX qui nous a plus. Car pour le reste, il n’y a rien d’une révolution quand on connaît la méthode initiale. C’est juste une bonne occasion de l’introduire à tous ceux qui s’intéressent à l’UX design. Convaincus ? N’hésitez pas à partager vos retours d’expérience.

Article largement inspiré de « How to apply a Scrum inspired agile process to UX design« , Jack Josephy.

À propos de l'auteur