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