Make backlog refinement great again

Plus jamais ça

A quoi sert un backlog grooming ?

• Formuler les user stories et partager le besoin
• Détecter les stories qui n'ont plus aucun sens
• Réévaluer l'ordre des priorités
• Estimer les user stories
• Découper les user stories

Un backlog

évolue constamment

Donner du sens au backlog

à travers l'impact mapping

Impact mapping

(son intérêt)

• Vision d'ensemble partagée
• Permet de challenger la pertinence d'une US
• Permet d'identifier les manques
• Rapide à mettre en oeuvre
• Favorise le travail de groupe
• Permet de se concentrer sur les fonctionnalités qui ont un vrai impact business

Impact mapping

(les éléments)

• L'objectif
• Les acteurs
  • De qui avez-vous besoin pour atteindre vos objectifs ?
• Les impacts
  • Comment souhaitez-vous modifier le comportement des acteurs afin d’atteindre votre objectif ?
• Les fonctionnalités
  • Quelles fonctionnalités ou actions devez-vous mettre en place pour obtenir les comportements identifiés ?

Impact mapping

niveau 0 : pourquoi

• Pourquoi dépenser de l'argent pour ce projet ?
• Qu'est-ce qui fait qu'on est prêts à dépenser notre énergie ?

C'est l'objectif à atteindre, pas la solution

Impact mapping

niveau 1 : qui ?

• Qui peut nous aider à atteindre cet objectif ?
• Qui peut nous aider à accomplir l'objectif ? (ou nous en empêcher ?)
• Qui est impacté ?

Evitez le terme "utilisateurs" : soyez précis

Impact mapping

niveau 2 : comment ?

• Quels comportements peuvent nous aider à accomplir cet objectif ?
• Comment le comportement des acteurs doit-il changer ?
• Comment ces acteurs peuvent-ils empêcher d'arriver à ces objectifs ?

Impact mapping

niveau 3 : quoi ?

• En tant qu'équipe ou entreprise, comment pouvons-nous faire pour favoriser ces impacts ?
• Ce n'est pas forcément une solution logicielle qui est attendue
• Il n'y a pas qu'une seule solution, on peut en définir plusieurs. On partira sur une en priorité, les autres peuvent être

Donner du sens au stories

à travers l'example mapping

Example mapping

Utiliser un outil adapté tel que realtime board pour tracer ces post-its et respecter les couleurs

Phase 1 :

Inviter les bonnes personnes et time-boxer

• Three amigos
  • PO
  • Dev
  • Recette
• Moins de personnes
  • Des discussions plus rapides
  • Moins de personnes ne prenant pas part à la discussion
• Limiter à 25 minute par US
• 1 dev = pas de discussion technique !

Phase 1 :

Utiliser un formalisme

• Limiter le nombre de règles de gestion
  • Trop de règles de gestion et la story doit être découpée car trop complexe
• Décrire les critères d'acceptation en Gherkin
  • Etant donné que ...
    • Les prérequis
  • Lorsque ...
    • L'action à évaluer
  • Alors ...
    • Le résultat à vérifier

Phase 1 :

Exemple

 Fonctionnalité: Eligibilite
  En tant qu'utilisateur
  Je veux visualiser la liste des mobiles que je peux commander
  Afin de ne pas voir les mobiles que je ne peux pas commander

  Contexte:
    Etant donnés les téléphones suivants:
      | marque | modele       | standard | etech | leader |
      | Apple  | iPhone X     |          |       | 24     |
      | Apple  | iPhone XS    | 30       |       |        |
      | Apple  | iPhone 8     | 18       |       |        |
      | Orange | Hapi 11      | 18       |       |        |
      | Orange | Hapi 50 bleu | 18       | 24    |        |

  Scénario: standard segment 1
    Etant donné que l'entité de l'utilisateur a un contrat client
    Et que l'utilisateur est un collaborateur en CDI
    Et que l'utilisateur n'a pas de fin de contrat
    Et que l'utilisateur a un segment 1
    Quand l'utilisateur se rend sur la page téléphonie mobile
    Alors l'utilisateur voit le mobile "Orange" "Hapi 11"
    Mais l'utilisateur ne voit pas le mobile "Apple" "iPhone X"
    Mais l'utilisateur ne voit pas le mobile "Apple" "iPhone XS"

True story

"J'ai déjà fait pleuré un PO avec cette méthode"

"Mon PO arrive en affinage avec des exemples écrits en Gherkin"

(Ce PO est jalousement gardé par son équipe et ils n'ont pas eut un seul bug car ils suivaient scrupuleusement les critères d'acceptation)

Phase 1 :

Affinage

• Engager la discussion autour de la story
  • Permet au PO d'être challengé et de se poser plus de questions
• Description par l'exemple
  • Permet d'être exhaustif dans les critères d'acceptation (ce qui n'est pas inclus est exclus)
  • Ecriture de tests pertinents
  • Ajouter des cas oubliés
• Redécouper
• Reformuler
• Premier chiffrage à chaud si l'US est assez complète

Phase 2 :

Présenter les US à l'équipe

• Les stories sont déjà rafinées
• Les grosses erreurs sont écartées
• Partage des stories
• Erreurs peuvent être détectées par d'autres membres
• Avec l'example mapping, si on découpe
  • chaque règle de gestion a ses critères d'acceptation

Pourquoi chiffrer ?

• Pour vérifier qu'on a la même idée de la complexité
  • Lever les incompréhensions
• Estimer les US candidates au prochain sprint
  • Le chiffrage nous permet d'embarquer le maximum d'US pouvant être terminées au prochain sprint
  • Attention à ne pas embarquer trop d'US !

Et si on embarque trop d'US ?

• Trop d'US au sprint
• Plusieurs US ne seront pas terminées
• Reportées au suivant à moitié faites
• Leur chiffrage est également reporté
• Ce chiffrage vient biaiser la futur vélocité
• La vélocité permet d'avoir une idée du périmètre du prochain sprint !

Amélioration continue

Savoir s'arrêter

• Limiter le backlog à un sprint d'avance
  • principe du Kanban, ne pas avoir trop de travail en cours (et donc non fini)
• Au delà, ne groomer que les cas prioritaires
• Savoir supprimer des stories qu'on a reportées X fois
  • Si c'est un vrai besoin, elles reviendront naturellement

Faire un ROTI

• De 1 à 5
• Ne pas avoir à (systématiquement) justifier son score
  • pour éviter les score à 4 des personnes ne souhaitant pas s'exprimer
• L'objectif est d'améliorer le score
• On suivre son évolution et faire une réunion ad-hoc si le score baisse