Convertir un cahier des charges traditionnel en User Stories ?

De nombreux projets gérés de manière traditionnelle commencent par une Software Requirements Specification (SRS). À un moment donné au cours du projet, la décision est prise de passer à une approche agile. Dans ce cas, la question se pose naturellement de savoir si une SRS peut servir de nouveau Product Backlog agile. Certaines équipes envisagent même de réécrire la SRS en un Product Backlog avec des User Stories. Mais est-ce vraiment nécessaire ?

Avant d'aborder cette question, j'aimerais expliquer brièvement ce que j'entends exactement par Requirements Specification ou SRS. J'ai constaté que ces documents peuvent varier considérablement d'une entreprise à l'autre. Fondamentalement, je fais référence à un document typique contenant des énoncés comme « Le système devrait… ».

Mon conseil s'applique cependant à pratiquement tous les documents de spécification traditionnels. Cela vaut bien sûr pour tout document comportant des exigences intégrées et numérotées, que tous les énoncés soient formulés comme « Le système devrait… » ou non.

Quelques inconvénients de l'utilisation d'une SRS comme Product Backlog

Pour un produit agile, le Product Backlog remplit deux fonctions importantes :
- Il sert d'archive pour tous les travaux à réaliser
- Il facilite la priorisation du travail

Le Product Backlog indique donc à une équipe quels travaux doivent être accomplis, et peut également être utilisé comme outil de planification pour séquencer le travail. En revanche, une SRS traditionnelle indique simplement quels travaux doivent être réalisés dans un projet.

Une SRS ne vise ni à rédiger des exigences pouvant être intégrées dans un Sprint, ni à les prioriser. Rédiger des exigences indépendantes est au mieux un objectif secondaire, ce qui se voit bien dans l'organisation hiérarchique de la plupart des documents SRS avec leurs exigences numérotées (1.0, 1.1, 1.1.1, etc.).

Tant qu'une SRS est considérée comme un simple document d'exigences, cela ne pose aucun problème. Cependant, si les éléments d'une SRS doivent servir de Product Backlog Items et être priorisés, cela entraînera des difficultés.

Avec une SRS, il est souvent impossible pour une équipe de développer l'exigence 1.1.1 sans développer simultanément les exigences 1.1.2 et 1.1.5. Ces dépendances compliquent beaucoup plus les choses que si l'on pouvait simplement sélectionner et traiter une Story après l'autre à partir d'un Product Backlog bien élaboré.

La priorisation des éléments subordonnés est tout aussi difficile dans une SRS que l'identification des fonctionnalités secondaires pour créer un Minimum Viable Product.

Une Software Requirements Specification est bien adaptée comme spécification d'exigences. Elle est efficace pour décrire ce qu'un système ou un produit doit faire. (Bien sûr, elle n'aborde pas tous les aspects agiles comme les exigences émergentes (Emergent Requirements), la collaboration, les apprentissages, etc. Je pars néanmoins du principe que ces éléments se produisent.)

Ma recommandation concernant les SRS dans le Sprint

En principe, je ne recommanderais pas de sacrifier son temps pour réécrire une SRS impeccable. Bien sûr, au regard des problèmes mentionnés précédemment, il pourrait être utile de transformer la SRS en User Stories et en un beau Product Backlog, mais généralement l'effort n'en vaut tout simplement pas la peine.

Quelqu'un devrait prendre le temps de le faire, mais cette personne peut normalement utiliser ce temps de manière bien plus judicieuse. Je déconseille particulièrement de réécrire une SRS si d'autres membres de l'équipe devaient attendre le nouveau Product Backlog pour pouvoir commencer leur travail.

Le Scrum Master ou un autre membre de l'équipe doit trouver un moyen de mesurer la progression même avec une SRS, et s'assurer qu'aucune exigence ne passe à la trappe. Normalement, c'est une bonne idée d'impliquer l'assurance qualité pour garantir que tout dans la SRS a été traité ou listé dans le backlog.

De plus, il est important de transmettre à ceux qui participent à la création des documents SRS de le faire, dans les projets futurs, d'une manière plus compatible avec Agile. Si tu y parviens, tu pourras éviter dans ton prochain projet les problèmes qui surgissent d'un décalage entre Agile et un document SRS traditionnel.

Ce texte provient du blog de Mike Cohn et a été traduit par nos soins en français.

Exigences non fonctionnelles

=> Découvre ici comment transformer les exigences non fonctionnelles en User Stories.

Sprint Planning orienté engagement

=> Ici tu découvriras pourquoi je préfère le Sprint Planning orienté engagement au Sprint Planning orienté vélocité.