Comment échapper à «Story Card Hell» en trois étapes simples.

Votre carnet de commandes est rempli d'histoires d'utilisateurs détaillées. Votre équipe n'est plus en mesure de les gérer ou de les classer.

Vous vous demandez quel est le produit que vous construisez. Les parties prenantes semblent changer d'avis tout le temps. Vous manquez la grande image.

Je pense que vous êtes dans Story Card Hell, comme dit James Shore.

Voici trois façons de s'échapper.

Vision produit

Une vision énonce un objectif. Mais cela ne vous dit pas comment y accéder.

Une grande vision est stimulante et inspirante. Cela transcende l'individu. Il rassemble les gens pour travailler dans ce sens. Cela les motive.

La vision de la société SpaceX, la société aérospatiale d’Elon Musk, est la suivante:

SpaceX conçoit, fabrique et lance des fusées et des engins spatiaux de pointe. La société a été fondée en 2002 pour révolutionner la technologie spatiale, dans le but ultime de permettre aux gens de vivre sur d'autres planètes.

La vision produit de l’iPod d’Apple était la suivante:

Toute ma musique dans ma poche.

Généralement, un responsable / propriétaire de produit définit la vision du produit. Donc, si vous ne connaissez pas la vision, parlez-en à votre chef de produit.

Si vous êtes un chef de produit: comment présenteriez-vous votre produit à un investisseur potentiel en 30 secondes?

Vous pouvez créer un Product Vision Box avec d'autres parties prenantes. Prenez du carton et construisez une boîte. Écrivez et dessinez à la surface. À quoi ressemblerait l'emballage hypothétique d'un produit? L'espace limité vous obligera à vous concentrer sur les principales fonctionnalités de votre produit.

Pour une description plus sophistiquée de la vision, vous pouvez utiliser un tableau de vision produit:

Product Vision Board de Roman Pichler (Creative Commons BY-SA 3.0)

Le Product Vision Board explique:

  • Le groupe cible (qui utilisera le produit)
  • Les besoins (des utilisateurs)
  • Le produit (caractéristiques principales)
  • Les objectifs commerciaux (par exemple, comment l'entreprise tire-t-elle de l'argent du produit?)

Comment une vision de produit vous aide-t-elle à vous échapper de Story Card Hell?

Une vision donne une direction. C’est pourquoi vous devriez le rendre visible là où le développement se produit. Créez par exemple une énorme affiche et accrochez-la au mur.

Tout le monde peut vérifier si de nouvelles histoires correspondent à la vision du produit. Et contester des histoires qui s'écartent de la direction prévue.

Grande image

Même si vous avez une vision, vous pouvez manquer des informations contextuelles pour vos histoires. Ceci est la grande image.

Plusieurs pratiques vous aident à comprendre la situation dans son ensemble. Une de ces pratiques est Story Mapping par Jeff Patton. Ci-dessous, vous trouverez la façon dont je le pratique.

Cartographie d'histoire

Les activités des utilisateurs sont au top. Encadrez une activité par un objectif que certains utilisateurs souhaitent atteindre. Cela peut être pour leur propre avantage ou pour faire leur travail. Ordre des activités de gauche à droite. Plus à gauche, plus l'activité a lieu tôt.

Les exemples d'activités d'une boutique en ligne sont les suivants: Ajouter un produit, Parcourir les produits, Acheter des produits, Préparer l'envoi, Expédier des produits. Dans la plupart des cas, un utilisateur effectue une activité en une seule séance. Souvent en quelques minutes ou au plus heures.

Pour atteindre un objectif, les utilisateurs doivent effectuer des tâches: les tâches de l'utilisateur. Des exemples de tâches sont Rechercher des produits et Afficher les détails du produit pour l’activité Parcourir les produits.

Avec les activités, les tâches représentent la colonne vertébrale. C'est la structure que vous utilisez pour organiser les histoires.

À partir des tâches, vous dérivez des histoires. Dans la tâche Afficher les détails du produit, vous pouvez dériver une histoire intitulée Afficher les détails du produit (texte uniquement) et une autre histoire intitulée Afficher les détails du produit (avec une image).

Plus l'équipe place une histoire haut, plus tôt elle la met en œuvre. L'implémentation se déplace de gauche à droite dans une rangée et de haut en bas.

Ne stockez pas une carte d’histoire dans un outil électronique. Au lieu de cela, placez-le sur un mur et utilisez-le pour communiquer au sein de l'équipe, avec les utilisateurs et avec les autres parties prenantes. Laissez-le en suspens, et vous verrez toujours le contexte des histoires.

Parmi les autres pratiques permettant de comprendre le contexte des récits, citons:

  • Cartographie d'impact
  • Cas d'utilisation 2.0

Spécification juste à temps

Une pratique cruciale pour échapper à Story Card Hell est la spécification juste à temps. Ne détailler que les histoires pour les deux prochains sprints. Passons en exemple.

Le chef de produit écrit une carte d’histoire:

En tant que client, je souhaite trouver les produits d'une propriété pour savoir que le magasin offre ce que je veux.

Le chef de produit a quelque chose de spécifique à l'esprit. Les utilisateurs doivent pouvoir rechercher par nom de produit, numéro de produit, catégorie de produit et prix.

Une semaine avant le début du sprint, le responsable produit discute de l’idée avec l’équipe. Les développeurs lui ont dit qu'une autre équipe avait lancé une puissante fonction de recherche il y a quelques jours, pour un produit différent.

C’est basé sur un simple champ de texte, comme Google. Ce serait moins d'effort de le réutiliser que de développer quelque chose de nouveau. L’équipe est d’accord sur ce point et écrit ce qui a été convenu comme critère d’acceptation.

L'équipe documente donc les détails de l'histoire peu avant la mise en œuvre. De cette façon, l’équipe possède le plus de connaissances possibles sur les développements antérieurs.

Conclusion

Il existe plusieurs pratiques pour échapper à Story Card Hell:

  • Une vision produit définit un objectif et aide à garder le développement sur la bonne voie.
  • Story Mapping fournit une image globale en tant que contexte pour les histoires.
  • La spécification juste à temps vous permet de ne détailler que les histoires les plus clairement comprises.

Dans le meilleur des cas, vous utilisez toutes les pratiques. Pour que cela fonctionne, vous avez probablement besoin d'un chef de produit qui

  • Favorise les relations avec les intervenants
  • Est bon en communication et en résolution de conflits
  • N'a pas peur de dire «non» de temps en temps

Si vous voulez savoir ce que je vais faire, visitez mon projet GitHub.

Vous pouvez me contacter sur Twitter ou LinkedIn.