J’ai pas assez de specs !

Je ne sais pas vous, mais j’entends souvent des POs en panique me dire qu’ils n’ont pas assez de specs pour le prochain sprint.

• J’ai pas fini de rédiger mes specs 
• Mes US ne sont pas chiffrées
• J’ai pas assez d’infos pour terminer les specs
• ….

Votre sprint commence dans 3 jours et vous n’avez pas assez de matière pour planifier une itération complète qui peut délivrer une valeur métier ?

Relaxez-vous, je vous donne les clés pour surmonter cette étape et pour ne plus jamais être à court de specs.

A court de specs ?

Dans ce genre de situation, le product owner doit trouver un backup pour gagner du temps.

C’est pas toujours brillant, mais voici les classiques.

Le report de sprint

Quand vous n’avez pas assez de specs pour planifier un nouveau sprint, il est tentant de parler à l’équipe et de lui présenter des (fausses) excuses pour reporter le nouveau sprint d’une semaine.

• Le designer est en retard dans ses tâches. Il serait préférable d’avoir un prototype entier pour finaliser les US

• J’attends la validation du Marketing ou le rapport d’étude de marché pour valider le besoin

• Bla bla bla

Si vous n’êtes pas du genre à être à court de specs, cela passera facilement avec votre équipe.

Par ailleurs, il y a fort à parier qu’il va rester des reliquats à la fin du sprint actuel qui vont occuper l’équipe quelques jours supplémentaires.

C’est pas la fin du monde, mais bon, ne vous mentez pas à vous même.  Si vous n’avez pas de specs à livrer, ce n’est pas que la faute des autres. 

Le ni vu ni connu

L’autre réflexe est d’aller piocher dans son backlog est d’ajouter tout ce que l’on trouve pour constituer un sprint.

L’idée est dissimuler son retard en expliquant que la vision est de faire un sprint de transition.

“On a besoin de faire ce sprint pour être à jour. C’est important d’alléger le backlog avant de commencer un nouveau chapitre”

In fine, votre sprint va ressembler à un mix de :

• Users stories que vous qualifiez de prioritaires
• Bugs à résoudre
• Tâches techniques pour absorber la dette

Ce genre de sprint arrive parfois, mais mieux vaut l’éviter car la valeur livrée est souvent faible pour les utilisateurs car il manque un objectif.

Et donc…

Ca arrive à tout le monde, rassurez-vous !

Baisse de forme, baisse de motivation, absence…

Ou tout simplement. 

Vous vous êtes laissé absorber par d’autres priorités et vous vous êtes fait piéger par le temps.

Les causes

Les US retoquées

C’est certainement la cause numéro 1 chez les PO juniors.

Vous avez écrit des US et vous vous êtes présenté en poker grooming 2 jours avant le début du prochain sprint.

Manque de pot, vous êtes tombés sur des développeurs coriaces (ou levés du mauvais pied).

• “Cette US n’est pas claire, elle n’est pas complète”

• “Ce que tu décris n’est pas possible avec notre techno”

• “Et il se passe quoi, si l’utilisateur clique là ?  C’est spécifier où ?”

• etc…
  

Bref, vous avez fait un grooming cauchemardesque et toutes vos US ont été retoquées.

Rien n’a pu être chiffré.
Vous devez refaire presque toutes vos specs et vous n’avez que 24h pour réagir.

Sale journée…

Le souci du détail

Celle là c’est la conséquence de l’expérience précédente.

Vous savez que vos développeurs sont tatillons sur les détails de vos specs.

Du coup, vous ne planifiez pas de grooming avant d’avoir atteint la perfection dans la rédaction de vos US.

Il faut que ça passe du premier coup, et vous pensez à tous les scénarios possibles et tous les détails.

Le seul problème : 
Rédiger une seule US peut prendre des heures. Le temps vous manque.

Les dépendances externes :

Vous connaissez le contenu de vos US mais vous avez besoin de réponses ou d’aides extérieures pour les terminer.

• Cette US n’est pas valide sans les wireframes de l’UX designer mais il n’avance pas assez vite ou il est occupé sur autre chose.

• Il vous manque une règle métier et le Marketing ne vous répond pas. C’est flou.

• Il faut valider cette règle avec la conformité, mais Mme Michu est en congé.

Bref, vos specs ont besoin d’insights extérieurs pour être complètes mais les personnes susceptibles de vous aider n’ont pas le même agenda. 

Vous avez trop de développeurs :

Ça fait 6 mois que vous ete PO et vous devez gérer une équipe de 7 développeurs et vos sprints durent 3 semaines.

Vous devez pondre plus de 30 US par sprint et vous n’en avez pas rédigé la moitié…

Aie Aie aie… comment faire ??

Le syndrome de la page blanche

Celui là, c’est la hantise de tous PO.

Vous bossez sur un produit qui tourne bien et qui est sur le marché depuis longtemps.

Ça fait 18 mois que vous livrez continuellement des nouvelles fonctionnalités, que vous apportez des améliorations…

Désormais, tout semble rouler. Les utilisateurs ne se plaignent pas. Ils ne demandent rien…

Pire ils trouvent votre produit génial.

Le seul problème, vous ne voyez pas quoi apporter de plus à part faire de la maintenance.

Chaque nouveau sprint devient pénible, vous êtes à court d’idée.

Mes astuces personnelles

J’ai pas la science infuse donc ce que je donne peut marcher pour certains d’entres vous et moins pour d’autres.

Tout dépend des problèmes que vous rencontrez et la phase de conception dans laquelle vous êtes.

Imposez votre agenda :

A part mes enfants, personne ne me dicte mon agenda. J’y tiens plus que tout au monde.

Ainsi, je m’accorde du temps avec moi-même chaque semaine pour être dans ma bulle.

Chaque semaine, dans mon boulot, je suis injoignable le lundi après midi de 14h à 18h et le jeudi de 9h à 12h30.

Impossible de me caler une réunion ou un appel (sauf cas de force majeure). Mes collègues le savent et ont tout le reste de la semaine pour planifier des réunions avec moi.

Je dédie ce temps á rédiger ou à réfléchir à des specs.

Le lundi :

J’ouvre l’appli mobile ou le site internet du produit sur lequel je travaille et je le passe en revue sous toutes ses coutures.

Je prends des notes sur des bugs ou des incohérences que je vois et je rédige des brouillons de solutions.

Parfois, j’ai l’inspiration et ça se termine en solution complète, parfois j’ai des dizaines de pistes mais rien de concret.

A la fin de cette session, je prends 20 minutes pour partager ces pistes ou ces solutions à toutes les personnes concernées et je leur demande un avis ou une réponse.

Ce travail me permet de fournir du travail pour LES prochains sprints à venir.

Le jeudi

Je parcours les produit concurrents, je lis des études de marché ou j’essaye de prendre un problème interne à mon entreprise.

Par exemple : 

• Comment augmenter le taux de rétention ?
• Comment valider une nouvelle niche ?

Je ne me concentre pas sur des problèmes produit mais plus sur des problématiques ou des objectifs marché.

Ces recherches me donnent énormément d’insights pour trouver des solutions produit.

Le reste de la semaine j’écris des specs plus concrètes mais je le fais quand j’ai le temps.

Ces moments me permettent de toujours avoir plusieurs coups d’avance et de pas me laisser dépasser par des micro problèmes à résoudre pour le sprint suivant.

Ecrivez des specs à plusieurs :

Si c’est votre cas, c’est votre plus grosse erreur.

Quand vous avez une idée et que vous ne savez pas la formuler correctement, demandez à la personne qui peut vous aider de l’écrire pour vous.

Ça ne fonctionne pas à tous les coups, mais vous serez surpris de voir comment quelque chose formulé par un autre (même un brouillon) peut vous mettre sur la bonne voie.

Impliquez les gens à concevoir le produit avec vous… c’est vital.

PS : Cela vous permet d’éviter de vous planter pendant les séances de grooming.

Distribuez des tâches :

Si vous avez des dépendances externes, ne demandez pas de vous aider. Ordonnez le (implicitement). 
C’est le seul moyen pour que l’on vous réponde à l’heure.

Envoyer un email avec ce genre de formulation : 

****

****

Indiquez toujours l’objectif ou le résultat obtenu pour l’entreprise (pas le vôtre).

Les gens qui ne répondent pas à vos demandes répondront obligatoirement aux demandes de l’entreprise.

Prenez les décisions

Ils vous manquent encore des éléments ou des règles pour terminer vos US ?

Faites comme si vous étiez le boss et décidez tout seul (prix, contenu, décision stratégique…).

Si vous vous trompez, vous pourrez corriger par la suite.

Faites bouger les lignes, quand les personnes concernées se réveilleront pour contrôler, vous aurez déjà codé la solution dans sa quasi intégralité.

Les gens ont l’habitude réagir et commenter plutôt qu’agir.

Définissez des objectifs de sprint

C’est pas parce que l’on a un backlog rempli à ras bord que l’on a quelque chose d’intéressant à faire pour le prochain sprint.

Le sprint doit avoir l’objectif d’apporter une valeur pour l’utilisateur.

Un sprint, c’est long à constituer, planifier et remplir.

En revanche, un objectif c’est rapide à définir (aidez vous des KPIs). 

Tellement rapide que vous pouvez en définir plusieurs en une heure et avoir un framework pour les 4 / 5 prochains sprints.

Une fois que vous avez ces objectifs, communiquez les à votre équipe et tous les acteurs importants pour les valider ensemble.

Comme par magie, les gens vont vous aider à remplir vos sprint avec leurs idées pour atteindre ces objectifs.

Exemples :

• Le but du sprint 23 est d’augmenter le nombre d’articles dans le panier moyen

• Le sprint 24 aura pour but de simplifier le paiement par CB.

• Etc…

Ne soyez plus jamais à court

Ça a l’air simple comme ça mais croyez moi je sais mieux que quiconque que c’est parfois l’enfer.

C’est pour ça que l’entreprise le recrute.

Dans la tête d’une organisation, voici comment on voit les rôles dans une équipe agile.

• Le développeur doit pisser du code

• Le designer doit créer des interfaces

• Le PO doit rédiger des specs pour s’assurer que tout le monde à une tâche à faire.

Evidemment, dans la réalité, le job de PO est bien plus large que rédiger des specs.  Les specs, ça se rédige à la fin d’un gros travail de recherche et de réflexion.

Mais ne soyez pas naïf, dans la majorité des cas, on vous jugera sur votre compétence à fournir des specs claires et à temps. 

C’est un raccourci, ça parait injuste mais c’est ainsi.

Si vous passez à côté, les développeurs iront se plaindre et votre réputation en prendra un coup.

Remontez vos manches, faites de la place dans votre agenda et à vos claviers.

Comme pour écrire ce blog, plus on s’exerce, plus vous augmenterez votre vélocité de rédaction.

Dans mon poste actuel, il me fait environ 6 heures d’écriture pour alimenter un sprint de 3 semaines pour 5 développeurs.

Par ailleurs, je m’assure toujours d’avoir toutes mes US rédigées au moins 10 jours avant le début du prochain sprint. 

L’astuce est de vous mettre une date de début du sprint qui est de 10 jours avant la date réelle (c’est comme avancer sa montre d’une heure).

Cela me donne une sécurité pour chiffrer et revoir mes specs s’il le faut.

Bon courage