comment découper vos « User Stories » #Agile (Histoires Utilisateur) avec la méthode INVEST

Splitting User Stories

http://www.agileadvice.com/2016/06/03/scrumxplean/splitting-user-stories/ par Faisal Ansari

Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.

Microsoft est partenaire de DantotsuPM
Microsoft est partenaire de DantotsuPM

I.N.V.E.S.T.

  • IIndépendante
  • N– Négociable
  • V– de Valeur
  • EEstimable
  • SSuffisamment petite
  • TTestable

Indépendante

Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.

Négociable

Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.

de Valeur

Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.

Estimable

Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».

Suffisamment petite

Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.

Testable

Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.

Découpage vertical ou horizontal

Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.

Des exemples de découpe de « User Stories »

Trop grosse User Story:
Trop grosse User Story: « En tant que client, je peux payer ma commande pour recevoir les produits »
En tant que client, je peux payer ma commande pour recevoir les produits

Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…

  • En tant que client, je peux faire un paiement par carte pour ma commande et collecter des points de récompense sur ma carte de crédit.

Et/ou

  • En tant que client, je peux faire un paiement PayPal pour ma commande pour que achever mon achat en toute sécurité sans partager les détails de ma carte de crédit avec un autre détaillant.

Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.

Découpage par flux de travail

revoir mon panier de courses
revoir mon panier de courses

Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :

  • Fournir mes informations bancaires
    Fournir mes informations bancaires

    En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.

  • En tant que client, je peux fournir mes informations bancaires pour ma commande pour recevoir les produits que j’ai achetés.
  • Recevoir une notification par SMS
    Recevoir une notification par SMS

    En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.

D’autres méthodes

Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :

Visitez le blog Agilistic
Visitez le blog Agilistic
  • par déroulement heureux / malheureux (ce qui se passe quand tout va bien versus quand il y a des exceptions, déviations ou autres problèmes)
  • par options d’interaction / par plate-forme
  • par types de données ou paramètres
  • par scénarios de test
  • par rôles
  • par ‘j’optimise maintenant ‘ contre ‘ j’optimise plus tard
  • par compatibilité de navigateur

la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.

Autres Ressources Utiles

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Pourquoi je vais passer la certification PMI-PBA® ? Par Marc Burlereaux

Marc Burlereaux
Marc Burlereaux

Pourquoi le responsable de programme, chef de projet que je suis va passer une certification sur l’Analyse Métier et en l’occurrence PMI-PBA® : Professional in Business Analysis de PMI (Project Management Institute) ?

1. Mon parcours

Si j’ai fait de l’Analyse métier au début de ma carrière (à l’époque nous utilisions MERISE !), que ce soit en ayant le titre de chef de projet ou consultant et si mon poste actuel au sein de HSBC Private Bank Swiss SA est « Senior Business Analyste », la plupart de ma carrière dans la banque privée suisse se déroule à des postes de Responsable de Programmes, Chef de Projets, Responsable de Département IT…

Et, enfin et surtout, en tant que Responsable Européen des Releases : je précise « surtout » car ce poste occupé pendant deux ans m’a permis de constater de nombreux errements quant à la gestion des exigences, qu’elles soient fonctionnelles ou non fonctionnelles. Et cela coûte cher et ajoute des risques quand nous devons « sortir à la dernière minute » des livrables non acceptables par le client car mal ou pas complètement analysés.

user requirementsTout le monde connait cette illustration sarcastique du produit livré ne correspondant ni aux attentes du client ni à la réalité de ces besoins. Mais c’est si vrai ! Ce serait une des raisons pour laquelle l’Analyse Métier s’est professionnalisée.

C’est aussi une des raisons de l’émergence de l’agilité.

A ce propos, je me rappelle une anecdote de mon début de carrière, en 1988. Je travaillais sur la conception d’une nouvelle plateforme bancaire à Genève en utilisant MERISE au sein d’un gros projet : jeune analyste métier, je rédigeais des Spécifications Fonctionnelles Détaillées en étant contraint par les Spécifications Fonctionnelles Générales analysées précédemment par d’autres.

En discutant avec le métier je me suis aperçu que l’étape précédente avait été mal analysée et j’ai donc adapté mon analyse détaillée au besoin du métier. Je fus recadré par la Direction du Projet qui me demanda de respecter les contraintes de l’étape précédente même si cela allait à l’encontre de la satisfaction des besoins du métier ! Ma frustration est encore vivace !

2. Mon expérience de Release Manager Européen

europeLors de ces deux années mon rôle fut de manager les livraisons coordonnées des différents projets livrés par les différents domaines du développement d’une banque privée genevoise dans un contexte européen.

Les livraisons étaient d’abord effectuées avec une fréquence trimestrielle, donc avec de nombreux livrables provenant de différentes équipes mais ayant des interdépendances.

Nous avons travaillé avec les acteurs de la gestion du changement, à savoir le métier, les architectes, la sécurité, le test et la production afin que l’entrée en release soit validée par ces acteurs pour éviter de découvrir quelques semaines avant la livraison des dysfonctionnements tels que :
  • le périmètre de la livraison est bien déterminé : fonctionnellement mais aussi géographiquement. Cela semble couler de source, mais pour des projets de petite taille (moins de 200 jours homme), j’ai constaté un manque de rigueur fatal à toute mise en production.
  • les architectes ont bien validé la solution.
  • la sécurité a été impliquée et que ses recommandations ont bien été mises en œuvre.
  • le support et la production ait pu donner leurs exigences non fonctionnelles à respecter avant toute mise en place.
Mais cela ne nous a pas empêché d’avoir à gérer des « sorties de release » suite à des analyses métier déficientes avec diverses origines :
  • Difficultés de l’analyse métier « à distance » par nos équipes offshores
  • Oubli d’interdépendances fonctionnelles ou géographiques
  • Normes de sécurité non respectées
  • Rejet par des utilisateurs non préparés (en termes de ressources et de formation)
  • Manque de stratégie globale de test sur des livrables différents mais interdépendants

3. L’Analyse Métier réussie, facteur clé de la réussite des projets

Une des raisons majeures des échecs dans les projets est la mauvaise définition des besoins :
  • succès ou échecSelon Carnegie, 25%-40% du budget des projets est utilisé par refaire à nouveau ce qui a déjà été fait … et que 70% – 85% de ces coûts de « re travail » sont dus à des erreurs dans la collecte des exigences métiers.
  • Selon le Gartner, 60 à 80% des échecs de projets peuvent être directement attribué à une mauvaise analyse des besoins ou exigences.

Il est donc important que le Responsable de Programmes, Chef de Projets, comprenne et maîtrise ce domaine, même s’il est sous-traité à des équipes d’Analystes Métier, afin de diriger au mieux cette activité primordiale de la gestion de projet et d’en gérer les risques.

4. Pourquoi je vais passer cette certification PMI-PBA®

Tout d’abord pour les mêmes motivations qui m’ont fait passer d’autres certifications :
  • PMI PBATravailler sur des supports de cours en anglais et donc progresser dans ce domaine,
  • Réfléchir sur des concepts et outils que j’utilise au quotidien mais dont je peux utiliser l’amélioration,
  • Acquérir de nouveaux outils,
  • Rencontrer des personnes ayant les mêmes centre d’intérêts toutefois dans des domaines différents afin d’enrichir ma créativité.
Mais aussi :
  • Assurer une meilleure initiation des projets / programmes
  • Éviter d’avoir à retravailler des livrables du projet
  • Savoir déjouer les pièges de l’Analyse Métier à distance lorsqu’elle est déléguée à des partenaires éloignés comme en Inde, Chine ou Pologne, mais aussi quand une équipe centrale collecte des besoins pour différentes entités locales. Mon expérience m’a montré que les « Analyses Métier à distance » sont pleines de pièges à déjouer : autant anticiper !
  • Posséder une double compétence de plus en plus prisée pour des projets petits à moyens ou la réduction des coûts implique de savoir tout faire
  • S’assurer dès le début du projet que la collecte des exigences métier est intégrée dans un mécanisme de documentation des tests d’acceptation
  • Pour introduire de l’agilité, car le client a désormais le droit de changer d’avis … mais aussi car l’environnement incertain et instable requiert cette flexibilité accrue
Détails sur la certification PMI-PBA du PMI
Détails sur la certification PMI-PBA du PMI

Et enfin parce que l’analyse métier réussie est un facteur clé de succès du projet !

Je vous donne rendez-vous dans quelques semaines une fois la certification passée pour vous faire part de la rétrospective de mon expérience !

Partenaire de DantotsuPM
Partenaire de DantotsuPM

PMI Requirements Management Practice guide available for free download

Requirements Management Practice Guide Launched

requirements managementPMI recently launched a new practice guide on requirements management, which is available for free download for a limited time.

Requirements Management: A Practice Guide is a complementary document to the Project Management
Institute’s (PMI’s) foundational standards. This practice guide provides guidance for project and program managers
who are looking to further understand the components and importance of requirements management.

A Practice Guide is for your individual use only. It may not be shared, copied or otherwise distributed further without written permission from Project Management Institute. All rights reserved.

Auriez-vous mis la charrue avant les bœufs ?

Project Management: Is Your Cart Ahead of the Horse?

http://www.pmhut.com/project-management-is-your-cart-ahead-of-the-horse par Chris Thompson

Cart-before-horseDites-moi si vous avez jamais vécu ce scénario :

Un client vient vous voir avec un besoin. Ceci crée un projet pour compléter la tâche et peut typiquement prendre la forme d’un projet de conception-construction. Quelqu’un peut entendre « conception-construction » et penser à la conclusion d’un contrat, mais je soutiendrais que le scénario conception-construction n’est pas uniquement lié à la conclusion d’un contrat.

La conception-construction considère les besoins du client, avec la connaissance du vendeur, pour en bout de ligne créer le résultat final après que les termes sont acceptés par les deux parties. Les processus de conception ou développement peuvent être itératifs ou être achevés avant que le projet ne commence. Pendant cette période de collecte des besoins et pendant le développement du périmètre, une relation unique commence à se former entre les deux partenaires. On espère que ce processus sera positif et qu’un certain niveau de confiance est mutuellement acquis.

Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

Ceci est le moment où la charrue commence à passer devant les bœufs.

stop siffletLes deux parties prenantes sont enthousiasmées par le projet et les deux tiennent beaucoup à commencer à travailler. La question principale à vous poser à vous-même est, avez-vous tous les deux convenu de vraiment tout à l’avance ? Vous avez probablement collecté les besoins nécessaires pour concevoir la partie qui sera complétée en premier. Vous avez probablement convenu d’un devis tarifaire et avez développé un accord contractuel pour protéger légalement les deux parties. Vous avez probablement même développé une sorte d’échéancier car ceci peut être un facteur déterminant pour vérifier si vraiment le client veut lancer le projet ou si vous avez la capacité de le faire ainsi dans les délais demandés.

Semble-t-il que tout soit prêt pour que le projet commence ? Typiquement, en dehors de la construction proprement dite, il n’y a pas de vrai événement significatif du début d’un projet. On commence lentement par de petits morceaux, des appels téléphoniques, des courriers électroniques, un petit travail de fond sur quelques items et, avant que vous ne le sachiez, vous êtes entièrement plongés dans le projet.

À ce point, si ceci est arrivé, votre charrue a largement dépassé vos bœufs.

Qui le projet va-t-il impacter ? Pensez-vous juste au propriétaire ou au représentant du propriétaire, ou considérez-vous aussi d’autres parties prenantes à l’intérieur ou à l’extérieur des deux organisations ? Que veulent-elles gagner ou obtenir avec ce projet ?

Quelles communications sont importantes pour elles? Comment veulent-elles ces communications, combien de fois et dans quel format ? D’autres projets dépendent-ils de ce projet ?

Voici quelques questions simples (liste non exhaustive…) pour vous aider à vous rendre compte qu’il vous manque deux ingrédients clés et, détail le plus important, un plan de management de projet agréé tant par vous que par le client.

Définir qui le projet touchera et en quoi il les affectera produit deux choses.

D’abord, cela produit une liste de parties prenantes, mais plus important encore une analyse des parties prenantes qui permettra d’identifier les besoins que vous devrez considérer pendant la réalisation du projet. La production d’un résultat final ou d’un livrable satisfera l’élément le plus basique de l’engagement. Ce qu’il pourrait vous manquer sont les besoins des parties prenantes supplémentaires qui n’ont pas été satisfaits. Le développement de cette analyse aidera aussi à développer un autre composant clé, le plan de communication.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

« Le Savoir est le Pouvoir ».

knowledge is powerCeci vous semble-t-il familier ? Rappelez-vous que chaque personne affectée par ce projet a des intérêts spécifiques qui devront être adressés. Peut-être que l’un des investisseurs aura besoin de délais ou informations spécifiques à intervalles réguliers pour informer l’entité avec des détails précis. Ceci pourrait affecter le financement du reste du projet. Le Directeur de Programmes dans votre organisation devra-t-il agréger des informations de projet par lui-même pour le comité de direction ?

Ces deux cas nécessitent que des informations différentes soient vérifiées non seulement par des méthodes différentes, mais peut-être aussi des moyens différents et à des fréquences différentes. Avez-vous 100 à 200 parties prenantes ? Est-il réaliste de communiquer des informations par courrier électronique, ou le développement d’un site web serait-il plus pertinent ?

En supposant que nous avons répondu à toutes les questions ci-dessus et fourni un plan pour les adresser, regardons maintenant ce que nous avons développé. Nous avons un registre et une analyse des parties prenantes, des besoins définis, un contenu bien borné, un plan d’approvisionnement, un échéancier de projet, un contrat et un plan de communication. Tels sont les ingrédients clés du plan global de projet (sans parler de l’analyse de risque réalisée à ce stade). Chacun de ces éléments devrait alors être formalisé, assemblé selon un ordre logique et présenté comme tel. Ceci sera le plan utilisé pour compléter le PROJET qui produira le LIVRABLE.

Remarquez la dernière phrase…car ceci est une considération importante.

House and Keys in Female HandsUn projet crée ou produit un livrable. Un projet est composé d’étapes pour produire un résultat final. Le plan de projet est le document détaillé qui décrit noir sur blanc comment ce sera fait. Une fois complété, il est présenté au client et chaque côté doit alors le signer. Cela ressemble beaucoup à un contrat et peut avoir la même signification légale. Cependant, la plupart du temps c’est un plan modifiable qui expose des critères pour les futurs problèmes qui pourraient surgir et les obligations contractuelles se centrent typiquement sur des items plus classiques comme le coût des articles, l’échéancier et la date d’achèvement, des questions de propriété et des considérations gouvernementales.

J’espère que cette description de scénario aura provoqué chez vous une réflexion autour de vos standards de mise en œuvre de projet. Rappelez-vous que maintenir les bœufs devant la charrue rendra beaucoup plus facile de la diriger quand vous prendrez de la vitesse.

et si vous positionniez votre portefeuille de projets sur le modèle de Kano ?

Plot your portfolio onto the Kano model

http://www.betterprojects.net/2013/01/plot-your-portfolio-onto-kano-model.html

 

Kano_ModelVous avez un portefeuille de projets. Certains projets changent totalement les règles du jeu. Certains sont sous les feux de la rampe. Certains sont plutôt exploratoires. Pourquoi ne pas essayer de les positionner sur le modèle de Kano Noriaki ci-dessus et voir ce que vous pouvez en apprendre ?

Extrait Wikipedia:

« Sur la base de cette nomenclature, quatre zones-fonctions (Indifférence, basique, performance, excitant) sont repérées sur le graphe ci-dessus (en anglais) qui comporte deux axes :

L’axe vertical représente le niveau de satisfaction : En bas, le moins satisfait (dissatisfied), En haut, le plus satisfait (satisfied)

L’axe horizontal représente la prise en compte des attentes : À gauche faible couverture (Need not fullfilled), à droite forte couverture (Need well fullfilled) »

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Peut-être devriez-vous changer de votre pondération d’investissement. Peut-être êtes-vous incertains de la profondeur de fonctionnalités ou la qualité d’un projet et devrez le détailler davantage.

J’aimerais entendre vos commentaires lorsque vous aurez réalisé cet exercice…

47% of unsuccessful projects fail to meet goals due to poor requirements management

Requirements management — a core competency for success

Requirements management — a core competency for success

Check PMI’s new Pulse of the Profession® in-depth report: The problem is multi-faceted, tied to a lack of focus on people, processes and culture.

Personal comment: While this report is interesting, I wish it would dive deeper next time into how the Agile principles can help address some situations where the fuzziness of the business requirements is high.

Learn more about the struggles faced by organizations and the way forward in the latest Pulse report.

The report identifie 2 key skills to develop !
The report identifie 2 key skills to develop !

les bonnes exigences pour bien les tracer ou bien les bonnes personnes pour un meilleur résultat?

Stephen Carver, conférencier à Cranfield, a dirigé un groupe de travail interactif sur le management des exigences de projet et il est parvenu à d’excellentes conclusions en pensant hors des chemins habituels ! Son analogie entre l’aviation et le management de projets et de programmes est particulièrement pertinente et je suis certain que vous saurez en faire bon usage.

Alors, vous entez-vous davantage pilote de ligne, de chasse ou plutôt contrôleur aérien envers les projets que vous managez ?