Développement par hypothèses : intégrer l'expérimentation dans Scrum
L'une des sources de gaspillage les plus persistantes en développement de produits est la livraison de fonctionnalités que les utilisateurs n'adoptent pas. Le développement par hypothèses (HDD) aborde directement ce problème en recadrant les fonctionnalités comme des hypothèses à tester plutôt que des exigences à livrer.
Le format de l'hypothèse
"Nous croyons que [cette fonctionnalité] permettra d'atteindre [ce résultat] pour [cet utilisateur]. Nous le saurons lorsque [nous observerons ce signal mesurable]." Le signal mesurable est l'élément le plus difficile à définir -- et le plus important. Sans lui, l'hypothèse ne peut être testée, seulement affirmée.
Intégration avec les Objectifs de Sprint
Un Objectif de Sprint formulé comme "Tester si les filtres de recherche améliorés réduisent les sessions sans résultat" décrit une expérience orientée résultat -- plutôt qu'un livrable. Cette formulation change la conversation lors de la Planification du Sprint, pendant le Sprint et lors de la Revue de Sprint.
Le rôle du Product Owner dans le HDD
Le HDD redéfinit le rôle du Product Owner : il devient explicitement responsable de définir les résultats -- le "pourquoi" derrière chaque élément de backlog -- et d'identifier les signaux mesurables qui indiqueront si le résultat a été atteint. L'équipe reste responsable des livrables.
Défis courants
Définir des signaux mesurables est difficile -- l'infrastructure analytique actuelle peut ne pas capturer les données nécessaires.
Les parties prenantes peuvent résister au cadrage expérimental.
Tout ne devrait pas être une hypothèse -- la maintenance et la dette technique doivent être traitées indépendamment.
Le signal mesurable doit être convenu à l'avance, pas choisi après coup.
XNM Conseil aide les organisations à construire des pratiques Scrum et agiles qui relient l'exécution des sprints aux résultats produit.