Découpage des User Stories - Historique des versions

Fabrice Aimetti le 6 octobre 2025 à 10:17

2025-10-06T10:17:32Z

← Version précédente		Version du 6 octobre 2025 à 10:17
Ligne 12 :		Ligne 12 :
	Traduction :<br />		Traduction :<br />
	<br />		<br />
	[[Image:splitting-user-stories-matryoshka.jpg\|border\|left\|link=]]Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose.<br /> <br /> Et cette étude a identifié quatre problématiques principales :<br /> - comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ;<br /> - comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ;<br /> - comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ;<br /> - comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story.<br /> <br /> Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* :<br /> <br /> '''Spikes :''' vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème.<br /> <br /> '''Parcours :''' S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ...<br /> <br /> '''Interfaces :''' Peut-être que votre première user story sera juste pour ~~Androïd~~, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités.<br /> <br /> '''Données :''' Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ...<br /> <br /> '''Règles :''' Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles.<br /> <br /> Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est ''How to Split User Story'' de Richard Lawrence (http://agileforall.com/author/rlawrence/).<br /> <br /> J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous.<br /> <br /> J'espère que ça vous aide.<br />		[[Image:splitting-user-stories-matryoshka.jpg\|border\|left\|link=]]Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose.<br /> <br /> Et cette étude a identifié quatre problématiques principales :<br /> - comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ;<br /> - comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ;<br /> - comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ;<br /> - comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story.<br /> <br /> Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* :<br /> <br /> '''Spikes :''' vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème.<br /> <br /> '''Parcours :''' S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ...<br /> <br /> '''Interfaces :''' Peut-être que votre première user story sera juste pour Android, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités.<br /> <br /> '''Données :''' Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ...<br /> <br /> '''Règles :''' Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles.<br /> <br /> Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est ''How to Split User Story'' de Richard Lawrence (http://agileforall.com/author/rlawrence/).<br /> <br /> J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous.<br /> <br /> J'espère que ça vous aide.<br />
	<br />		<br />
	(*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017)<br />		(*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017)<br />

Fabrice Aimetti le 29 août 2025 à 09:48

2025-08-29T09:48:16Z

← Version précédente		Version du 29 août 2025 à 09:48
Ligne 2 :		Ligne 2 :
	[[Category: User Story]]		[[Category: User Story]]
	[[Category: SPIDR]]		[[Category: SPIDR]]
			[[Category:Mike Cohn]]
	Auteur : Clear Systems<br />		Auteur : Clear Systems<br />
	Source : [http://www.clearsystemsllc.com/2017/04/03/splitting-user-stories/ Splitting User Stories]<br />		Source : [http://www.clearsystemsllc.com/2017/04/03/splitting-user-stories/ Splitting User Stories]<br />

Fabrice Aimetti le 18 août 2025 à 15:41

2025-08-18T15:41:51Z

← Version précédente		Version du 18 août 2025 à 15:41
Ligne 16 :		Ligne 16 :
	https://www.betteruserstories.com/training/videos/2<br />		https://www.betteruserstories.com/training/videos/2<br />
	<br />		<br />
	(**) Utiliser Lumberjack™		(**) Utiliser [https://ai.mountaingoatsoftware.com/storysplitting/ Lumberjack™ AI Story Splitting with SPIDR]

Fabrice Aimetti le 18 août 2025 à 15:41

2025-08-18T15:41:02Z

← Version précédente		Version du 18 août 2025 à 15:41
Ligne 11 :		Ligne 11 :
	Traduction :<br />		Traduction :<br />
	<br />		<br />
	[[Image:splitting-user-stories-matryoshka.jpg\|border\|left\|link=]]Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose.<br /> <br /> Et cette étude a identifié quatre problématiques principales :<br /> - comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ;<br /> - comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ;<br /> - comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ;<br /> - comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story.<br /> <br /> Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* :<br /> <br /> '''Spikes :''' vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème.<br /> <br /> '''Parcours :''' S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ...<br /> <br /> '''Interfaces :''' Peut-être que votre première user story sera juste pour Androïd, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités.<br /> <br /> '''Données :''' Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ...<br /> <br /> '''Règles :''' Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles.<br /> <br /> Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est ''How to Split User Story'' de Richard Lawrence (http://agileforall.com/author/rlawrence/).<br /> <br /> J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous.<br /> <br /> J'espère que ça vous aide.<br /> <br /> (*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017)<br /> https://www.betteruserstories.com/training/videos/2<br /> <br />		[[Image:splitting-user-stories-matryoshka.jpg\|border\|left\|link=]]Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose.<br /> <br /> Et cette étude a identifié quatre problématiques principales :<br /> - comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ;<br /> - comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ;<br /> - comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ;<br /> - comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story.<br /> <br /> Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* :<br /> <br /> '''Spikes :''' vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème.<br /> <br /> '''Parcours :''' S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ...<br /> <br /> '''Interfaces :''' Peut-être que votre première user story sera juste pour Androïd, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités.<br /> <br /> '''Données :''' Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ...<br /> <br /> '''Règles :''' Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles.<br /> <br /> Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est ''How to Split User Story'' de Richard Lawrence (http://agileforall.com/author/rlawrence/).<br /> <br /> J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous.<br /> <br /> J'espère que ça vous aide.<br />
			<br />
			(*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017)<br />
			https://www.betteruserstories.com/training/videos/2<br />
			<br />
			(**) Utiliser Lumberjack™

Fabrice Aimetti le 18 avril 2020 à 14:16

2020-04-18T14:16:10Z

← Version précédente		Version du 18 avril 2020 à 14:16
Ligne 11 :		Ligne 11 :
	Traduction :<br />		Traduction :<br />
	<br />		<br />
	[[Image:splitting-user-stories-matryoshka.jpg\|border\|left]]Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose.<br /> <br /> Et cette étude a identifié quatre problématiques principales :<br /> - comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ;<br /> - comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ;<br /> - comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ;<br /> - comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story.<br /> <br /> Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* :<br /> <br /> '''Spikes :''' vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème.<br /> <br /> '''Parcours :''' S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ...<br /> <br /> '''Interfaces :''' Peut-être que votre première user story sera juste pour Androïd, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités.<br /> <br /> '''Données :''' Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ...<br /> <br /> '''Règles :''' Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles.<br /> <br /> Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est ''How to Split User Story'' de Richard Lawrence (http://agileforall.com/author/rlawrence/).<br /> <br /> J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous.<br /> <br /> J'espère que ça vous aide.<br /> <br /> (*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017)<br /> https://www.betteruserstories.com/training/videos/2<br /> <br />		[[Image:splitting-user-stories-matryoshka.jpg\|border\|left\|link=]]Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose.<br /> <br /> Et cette étude a identifié quatre problématiques principales :<br /> - comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ;<br /> - comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ;<br /> - comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ;<br /> - comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story.<br /> <br /> Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* :<br /> <br /> '''Spikes :''' vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème.<br /> <br /> '''Parcours :''' S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ...<br /> <br /> '''Interfaces :''' Peut-être que votre première user story sera juste pour Androïd, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités.<br /> <br /> '''Données :''' Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ...<br /> <br /> '''Règles :''' Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles.<br /> <br /> Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est ''How to Split User Story'' de Richard Lawrence (http://agileforall.com/author/rlawrence/).<br /> <br /> J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous.<br /> <br /> J'espère que ça vous aide.<br /> <br /> (*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017)<br /> https://www.betteruserstories.com/training/videos/2<br /> <br />

Fabrice Aimetti le 9 septembre 2018 à 10:04

2018-09-09T10:04:59Z

← Version précédente		Version du 9 septembre 2018 à 10:04
Ligne 1 :		Ligne 1 :
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	[[Category: User Story]]		[[Category: User Story]]
			[[Category: SPIDR]]
	Auteur : Clear Systems<br />		Auteur : Clear Systems<br />
	Source : [http://www.clearsystemsllc.com/2017/04/03/splitting-user-stories/ Splitting User Stories]<br />		Source : [http://www.clearsystemsllc.com/2017/04/03/splitting-user-stories/ Splitting User Stories]<br />

Fabrice Aimetti le 9 septembre 2018 à 09:56

2018-09-09T09:56:08Z

← Version précédente		Version du 9 septembre 2018 à 09:56
Ligne 1 :		Ligne 1 :
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
			[[Category: User Story]]
	Auteur : Clear Systems<br />		Auteur : Clear Systems<br />
	Source : [http://www.clearsystemsllc.com/2017/04/03/splitting-user-stories/ Splitting User Stories]<br />		Source : [http://www.clearsystemsllc.com/2017/04/03/splitting-user-stories/ Splitting User Stories]<br />

Fabrice Aimetti le 9 septembre 2018 à 09:53

2018-09-09T09:53:47Z

← Version précédente		Version du 9 septembre 2018 à 09:53
Ligne 1 :		Ligne 1 :
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteur : Clear Systems<br /> Source : [http://www.clearsystemsllc.com/2017/04/03/splitting-user-stories/ Splitting User Stories]<br /> Date : 03/04/2017<br />		Auteur : Clear Systems<br />
			Source : [http://www.clearsystemsllc.com/2017/04/03/splitting-user-stories/ Splitting User Stories]<br />
			Date : 03/04/2017<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 06/05/2017<br />		Traducteur : Fabrice Aimetti<br />
			Date : 06/05/2017<br />
	----		----
	''Traduction :''<br /> <br /> [[Image:splitting-user-stories-matryoshka.jpg\|~~splitting-user-stories-matryoshka.jpg~~\|left]]Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose.<br /> <br /> Et cette étude a identifié quatre problématiques principales :<br /> - comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ;<br /> - comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ;<br /> - comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ;<br /> - comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story.<br /> <br /> Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* :<br /> <br /> '''Spikes :''' vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème.<br /> <br /> '''Parcours :''' S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ...<br /> <br /> '''Interfaces :''' Peut-être que votre première user story sera juste pour Androïd, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités.<br /> <br /> '''Données :''' Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ...<br /> <br /> '''Règles :''' Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles.<br /> <br /> Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est ''How to Split User Story'' de Richard Lawrence (http://agileforall.com/author/rlawrence/).<br /> <br /> J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous.<br /> <br /> J'espère que ça vous aide.<br /> <br /> (*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017)<br /> https://www.betteruserstories.com/training/videos/2<br /> <br />		Traduction :<br />
			<br />
			[[Image:splitting-user-stories-matryoshka.jpg\|border\|left]]Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose.<br /> <br /> Et cette étude a identifié quatre problématiques principales :<br /> - comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ;<br /> - comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ;<br /> - comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ;<br /> - comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story.<br /> <br /> Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* :<br /> <br /> '''Spikes :''' vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème.<br /> <br /> '''Parcours :''' S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ...<br /> <br /> '''Interfaces :''' Peut-être que votre première user story sera juste pour Androïd, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités.<br /> <br /> '''Données :''' Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ...<br /> <br /> '''Règles :''' Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles.<br /> <br /> Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est ''How to Split User Story'' de Richard Lawrence (http://agileforall.com/author/rlawrence/).<br /> <br /> J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous.<br /> <br /> J'espère que ça vous aide.<br /> <br /> (*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017)<br /> https://www.betteruserstories.com/training/videos/2<br /> <br />

Fabrice Aimetti le 11 juillet 2018 à 07:20

2018-07-11T07:20:52Z

← Version précédente		Version du 11 juillet 2018 à 07:20
Ligne 4 :		Ligne 4 :
	Traducteur : Fabrice Aimetti<br /> Date : 06/05/2017<br />		Traducteur : Fabrice Aimetti<br /> Date : 06/05/2017<br />
	----		----
	''Traduction :''<br /> <br /> [[Image:splitting-user-stories-matryoshka.jpg\|splitting-user-stories-matryoshka.jpg]]Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose.<br /> <br /> Et cette étude a identifié quatre problématiques principales :<br /> - comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ;<br /> - comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ;<br /> - comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ;<br /> - comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story.<br /> <br /> Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* :<br /> <br /> '''Spikes :''' vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème.<br /> <br /> '''Parcours :''' S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ...<br /> <br /> '''Interfaces :''' Peut-être que votre première user story sera juste pour Androïd, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités.<br /> <br /> '''Données :''' Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ...<br /> <br /> '''Règles :''' Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles.<br /> <br /> Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est ''How to Split User Story'' de Richard Lawrence (http://agileforall.com/author/rlawrence/).<br /> <br /> J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous.<br /> <br /> J'espère que ça vous aide.<br /> <br /> (*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017)<br /> https://www.betteruserstories.com/training/videos/2<br /> <br />		''Traduction :''<br /> <br /> [[Image:splitting-user-stories-matryoshka.jpg\|splitting-user-stories-matryoshka.jpg\|left]]Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose.<br /> <br /> Et cette étude a identifié quatre problématiques principales :<br /> - comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ;<br /> - comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ;<br /> - comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ;<br /> - comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story.<br /> <br /> Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* :<br /> <br /> '''Spikes :''' vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème.<br /> <br /> '''Parcours :''' S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ...<br /> <br /> '''Interfaces :''' Peut-être que votre première user story sera juste pour Androïd, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités.<br /> <br /> '''Données :''' Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ...<br /> <br /> '''Règles :''' Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles.<br /> <br /> Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est ''How to Split User Story'' de Richard Lawrence (http://agileforall.com/author/rlawrence/).<br /> <br /> J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous.<br /> <br /> J'espère que ça vous aide.<br /> <br /> (*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017)<br /> https://www.betteruserstories.com/training/videos/2<br /> <br />

Fabrice Aimetti : Page créée avec « Category: Portail Product Owner
Auteur : Clear Systems
Source : [http://www.clearsystemsllc.com/2017... »

2018-07-11T07:20:37Z

Page créée avec « Category: Portail Product Owner <div id="content_view" class="wiki" style="display: block"> Auteur : Clear Systems Source : [http://www.clearsystemsllc.com/2017... »

Nouvelle page

[[Category: Portail Product Owner]]
<div id="content_view" class="wiki" style="display: block"> Auteur : Clear Systems Source : [http://www.clearsystemsllc.com/2017/04/03/splitting-user-stories/ Splitting User Stories] Date : 03/04/2017 
----
Traducteur : Fabrice Aimetti Date : 06/05/2017 
----
''Traduction :'' [[Image:splitting-user-stories-matryoshka.jpg|splitting-user-stories-matryoshka.jpg]]Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose. Et cette étude a identifié quatre problématiques principales : - comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ; - comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ; - comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ; - comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story. Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* : '''Spikes :''' vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème. '''Parcours :''' S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ... '''Interfaces :''' Peut-être que votre première user story sera juste pour Androïd, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités. '''Données :''' Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ... '''Règles :''' Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles. Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est ''How to Split User Story'' de Richard Lawrence (http://agileforall.com/author/rlawrence/). J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous. J'espère que ça vous aide. (*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017) https://www.betteruserstories.com/training/videos/2

Découpage des User Stories - Historique des versions

Fabrice Aimetti le 6 octobre 2025 à 10:17

Fabrice Aimetti le 29 août 2025 à 09:48

Fabrice Aimetti le 18 août 2025 à 15:41

Fabrice Aimetti le 18 août 2025 à 15:41

Fabrice Aimetti le 18 avril 2020 à 14:16

Fabrice Aimetti le 9 septembre 2018 à 10:04

Fabrice Aimetti le 9 septembre 2018 à 09:56

Fabrice Aimetti le 9 septembre 2018 à 09:53

Fabrice Aimetti le 11 juillet 2018 à 07:20

Fabrice Aimetti : Page créée avec « Category: Portail Product Owner Auteur : Clear Systems Source : [http://www.clearsystemsllc.com/2017... »

Fabrice Aimetti : Page créée avec « Category: Portail Product Owner
Auteur : Clear Systems
Source : [http://www.clearsystemsllc.com/2017... »