Story Time, la réunion Scrum cachée - Historique des versions

Fabrice Aimetti le 17 août 2018 à 11:09

2018-08-17T11:09:35Z

← Version précédente		Version du 17 août 2018 à 11:09
Ligne 2 :		Ligne 2 :
	[[Category: User Story]]		[[Category: User Story]]
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteur : Kane Mar<br /> Source : [http://kanemar.com/2008/02/14/story-time-the-hidden-scrum-meeting/ Story-Time! The Hidden Scrum Meeting]<br /> Date : 14/02/2008<br />		Auteur : Kane Mar<br />
			Source : [http://kanemar.com/2008/02/14/story-time-the-hidden-scrum-meeting/ Story-Time! The Hidden Scrum Meeting]<br />
			Date : 14/02/2008<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 01/02/2011<br />		Traducteur : Fabrice Aimetti<br />
			Date : 01/02/2011<br />
	----		----
	Traduction :<br /> <br /> Est-ce que votre équipe a des difficultés à prévoir lorsque le projet sera terminé ? Avez-vous un grand nombre de stories non-estimées dans votre backlog produit ? Vos réunions de planification traînent-elles longuement sur plusieurs journées en générant beaucoup de discussions ? Si c'est le cas, il se pourrait que vous ayez tendance à oublier de "nettoyer" régulièrement votre backlog produit.<br /> <br /> Ken Schwaber conseille généralement que l'équipe consacre cinq pour cent de son temps (à chaque sprint) sur la préparation du backlog. Ce procédé est généralement connu sous le nom de "affinage" (NdT : ''grooming'') ou maintenance. Voici une bonne définition de ce que cela implique :<br /> <br /> ''"Il y a beaucoup de choses que l'on fait dans le backlog pour préparer les futurs travaux. On ajoute de nouvelles stories et epics , on découpe des epics en stories, on estime, on ajoute la valeur métier espérée, et ainsi de suite." Dr. Dan Rawsthorne, CST''<br /> <br /> J'ai récemment travaillé avec plusieurs clients qui approuvent la recommandation des cinq pour cent de Schwaber, mais qui en fait ne l'applique pas. Ils comprennent bien qu'ils ont besoin de passer cinq pour cent de leur temps sur la maintenance du backlog, mais ils ne le font pas et, par conséquent, leurs réunions de planification deviennent tendues et très longues.<br /> <br /> Depuis plusieurs années, je préconise explicitement la maintenance du backlog comme faisant partie intégrante du processus Scrum. Je conseille aux équipes de tenir périodiquement une réunion de deux heures chaque semaine. C'est une occasion de discuter et de maintenir le backlog, de sorte que la réunion de planification puisse être aussi efficace et productive que possible. J'appelle ces réunions "Story Time". Ce n'est pas un nouveau concept. Quand je travaillais exclusivement avec des équipes XP il y a plusieurs années, il était de pratique courante de tenir régulièrement une réunion Story Time. Bien que ça ne fasse pas officiellement partie de Scrum, j'ai découvert que le Story Time améliorait grandement la planification des projets et diminuait significativement les risques de discussions interminables qui apparaissent trop souvent dans de nombreuses équipes.<br /> <br /> Une réunion Story Time devrait se tenir à la même heure et au même endroit chaque semaine et impliquer toute l'équipe, y compris le Product Owner et le ScrumMaster. Le seul but de ces réunions hebdomadaires est de travailler sur le backlog produit pour préparer les futurs travaux. Ceci peut aussi inclure l'ajout de nouvelles stories et epics, le découpage de grosses stories et l'estimation.<br /> <br /> Donc, si le Product Owner et les Développeurs de votre équipe passent la majorité du temps de la réunion de planification à discuter sémantique, essayez les réunions de Story Time pour vous permettre d'être plus efficace dans vos prévisions. Je serais curieux de savoir comment cela impacte votre métier au jour le jour.		Traduction :<br />
			<br />
			Est-ce que votre équipe a des difficultés à prévoir lorsque le projet sera terminé ? Avez-vous un grand nombre de stories non-estimées dans votre backlog produit ? Vos réunions de planification traînent-elles longuement sur plusieurs journées en générant beaucoup de discussions ? Si c'est le cas, il se pourrait que vous ayez tendance à oublier de "nettoyer" régulièrement votre backlog produit.<br /> <br /> Ken Schwaber conseille généralement que l'équipe consacre cinq pour cent de son temps (à chaque sprint) sur la préparation du backlog. Ce procédé est généralement connu sous le nom de "affinage" (NdT : ''grooming'') ou maintenance. Voici une bonne définition de ce que cela implique :<br /> <br /> ''"Il y a beaucoup de choses que l'on fait dans le backlog pour préparer les futurs travaux. On ajoute de nouvelles stories et epics , on découpe des epics en stories, on estime, on ajoute la valeur métier espérée, et ainsi de suite." Dr. Dan Rawsthorne, CST''<br /> <br /> J'ai récemment travaillé avec plusieurs clients qui approuvent la recommandation des cinq pour cent de Schwaber, mais qui en fait ne l'applique pas. Ils comprennent bien qu'ils ont besoin de passer cinq pour cent de leur temps sur la maintenance du backlog, mais ils ne le font pas et, par conséquent, leurs réunions de planification deviennent tendues et très longues.<br /> <br /> Depuis plusieurs années, je préconise explicitement la maintenance du backlog comme faisant partie intégrante du processus Scrum. Je conseille aux équipes de tenir périodiquement une réunion de deux heures chaque semaine. C'est une occasion de discuter et de maintenir le backlog, de sorte que la réunion de planification puisse être aussi efficace et productive que possible. J'appelle ces réunions "Story Time". Ce n'est pas un nouveau concept. Quand je travaillais exclusivement avec des équipes XP il y a plusieurs années, il était de pratique courante de tenir régulièrement une réunion Story Time. Bien que ça ne fasse pas officiellement partie de Scrum, j'ai découvert que le Story Time améliorait grandement la planification des projets et diminuait significativement les risques de discussions interminables qui apparaissent trop souvent dans de nombreuses équipes.<br /> <br /> Une réunion Story Time devrait se tenir à la même heure et au même endroit chaque semaine et impliquer toute l'équipe, y compris le Product Owner et le ScrumMaster. Le seul but de ces réunions hebdomadaires est de travailler sur le backlog produit pour préparer les futurs travaux. Ceci peut aussi inclure l'ajout de nouvelles stories et epics, le découpage de grosses stories et l'estimation.<br /> <br /> Donc, si le Product Owner et les Développeurs de votre équipe passent la majorité du temps de la réunion de planification à discuter sémantique, essayez les réunions de Story Time pour vous permettre d'être plus efficace dans vos prévisions. Je serais curieux de savoir comment cela impacte votre métier au jour le jour.

Fabrice Aimetti le 23 juillet 2018 à 15:36

2018-07-23T15:36:32Z

← Version précédente		Version du 23 juillet 2018 à 15:36
Ligne 1 :		Ligne 1 :
	[[Category: Kane Mar]]		[[Category: Kane Mar]]
			[[Category: User Story]]
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : Kane Mar<br /> Source : [http://kanemar.com/2008/02/14/story-time-the-hidden-scrum-meeting/ Story-Time! The Hidden Scrum Meeting]<br /> Date : 14/02/2008<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : Kane Mar<br /> Source : [http://kanemar.com/2008/02/14/story-time-the-hidden-scrum-meeting/ Story-Time! The Hidden Scrum Meeting]<br /> Date : 14/02/2008<br />

Fabrice Aimetti le 1 juillet 2018 à 09:27

2018-07-01T09:27:54Z

← Version précédente		Version du 1 juillet 2018 à 09:27
Ligne 1 :		Ligne 1 :
	[[Category: Kane Mar]]		[[Category: Kane Mar]]
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : ~~[/Kane%20Mar~~ Kane Mar]<br /> Source : [http://kanemar.com/2008/02/14/story-time-the-hidden-scrum-meeting/ Story-Time! The Hidden Scrum Meeting]<br /> Date : 14/02/2008<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : Kane Mar<br /> Source : [http://kanemar.com/2008/02/14/story-time-the-hidden-scrum-meeting/ Story-Time! The Hidden Scrum Meeting]<br /> Date : 14/02/2008<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 01/02/2011<br />		Traducteur : Fabrice Aimetti<br /> Date : 01/02/2011<br />
	----		----
	Traduction :<br /> <br /> Est-ce que votre équipe a des difficultés à prévoir lorsque le projet sera terminé ? Avez-vous un grand nombre de stories non-estimées dans votre backlog produit ? Vos réunions de planification traînent-elles longuement sur plusieurs journées en générant beaucoup de discussions ? Si c'est le cas, il se pourrait que vous ayez tendance à oublier de "nettoyer" régulièrement votre backlog produit.<br /> <br /> Ken Schwaber conseille généralement que l'équipe consacre cinq pour cent de son temps (à chaque sprint) sur la préparation du backlog. Ce procédé est généralement connu sous le nom de "affinage" (NdT : ''grooming'') ou maintenance. Voici une bonne définition de ce que cela implique :<br /> <br /> ''"Il y a beaucoup de choses que l'on fait dans le backlog pour préparer les futurs travaux. On ajoute de nouvelles stories et epics , on découpe des epics en stories, on estime, on ajoute la valeur métier espérée, et ainsi de suite." Dr. Dan Rawsthorne, CST''<br /> <br /> J'ai récemment travaillé avec plusieurs clients qui approuvent la recommandation des cinq pour cent de Schwaber, mais qui en fait ne l'applique pas. Ils comprennent bien qu'ils ont besoin de passer cinq pour cent de leur temps sur la maintenance du backlog, mais ils ne le font pas et, par conséquent, leurs réunions de planification deviennent tendues et très longues.<br /> <br /> Depuis plusieurs années, je préconise explicitement la maintenance du backlog comme faisant partie intégrante du processus Scrum. Je conseille aux équipes de tenir périodiquement une réunion de deux heures chaque semaine. C'est une occasion de discuter et de maintenir le backlog, de sorte que la réunion de planification puisse être aussi efficace et productive que possible. J'appelle ces réunions "Story Time". Ce n'est pas un nouveau concept. Quand je travaillais exclusivement avec des équipes XP il y a plusieurs années, il était de pratique courante de tenir régulièrement une réunion Story Time. Bien que ça ne fasse pas officiellement partie de Scrum, j'ai découvert que le Story Time améliorait grandement la planification des projets et diminuait significativement les risques de discussions interminables qui apparaissent trop souvent dans de nombreuses équipes.<br /> <br /> Une réunion Story Time devrait se tenir à la même heure et au même endroit chaque semaine et impliquer toute l'équipe, y compris le Product Owner et le ScrumMaster. Le seul but de ces réunions hebdomadaires est de travailler sur le backlog produit pour préparer les futurs travaux. Ceci peut aussi inclure l'ajout de nouvelles stories et epics, le découpage de grosses stories et l'estimation.<br /> <br /> Donc, si le Product Owner et les Développeurs de votre équipe passent la majorité du temps de la réunion de planification à discuter sémantique, essayez les réunions de Story Time pour vous permettre d'être plus efficace dans vos prévisions. Je serais curieux de savoir comment cela impacte votre métier au jour le jour.		Traduction :<br /> <br /> Est-ce que votre équipe a des difficultés à prévoir lorsque le projet sera terminé ? Avez-vous un grand nombre de stories non-estimées dans votre backlog produit ? Vos réunions de planification traînent-elles longuement sur plusieurs journées en générant beaucoup de discussions ? Si c'est le cas, il se pourrait que vous ayez tendance à oublier de "nettoyer" régulièrement votre backlog produit.<br /> <br /> Ken Schwaber conseille généralement que l'équipe consacre cinq pour cent de son temps (à chaque sprint) sur la préparation du backlog. Ce procédé est généralement connu sous le nom de "affinage" (NdT : ''grooming'') ou maintenance. Voici une bonne définition de ce que cela implique :<br /> <br /> ''"Il y a beaucoup de choses que l'on fait dans le backlog pour préparer les futurs travaux. On ajoute de nouvelles stories et epics , on découpe des epics en stories, on estime, on ajoute la valeur métier espérée, et ainsi de suite." Dr. Dan Rawsthorne, CST''<br /> <br /> J'ai récemment travaillé avec plusieurs clients qui approuvent la recommandation des cinq pour cent de Schwaber, mais qui en fait ne l'applique pas. Ils comprennent bien qu'ils ont besoin de passer cinq pour cent de leur temps sur la maintenance du backlog, mais ils ne le font pas et, par conséquent, leurs réunions de planification deviennent tendues et très longues.<br /> <br /> Depuis plusieurs années, je préconise explicitement la maintenance du backlog comme faisant partie intégrante du processus Scrum. Je conseille aux équipes de tenir périodiquement une réunion de deux heures chaque semaine. C'est une occasion de discuter et de maintenir le backlog, de sorte que la réunion de planification puisse être aussi efficace et productive que possible. J'appelle ces réunions "Story Time". Ce n'est pas un nouveau concept. Quand je travaillais exclusivement avec des équipes XP il y a plusieurs années, il était de pratique courante de tenir régulièrement une réunion Story Time. Bien que ça ne fasse pas officiellement partie de Scrum, j'ai découvert que le Story Time améliorait grandement la planification des projets et diminuait significativement les risques de discussions interminables qui apparaissent trop souvent dans de nombreuses équipes.<br /> <br /> Une réunion Story Time devrait se tenir à la même heure et au même endroit chaque semaine et impliquer toute l'équipe, y compris le Product Owner et le ScrumMaster. Le seul but de ces réunions hebdomadaires est de travailler sur le backlog produit pour préparer les futurs travaux. Ceci peut aussi inclure l'ajout de nouvelles stories et epics, le découpage de grosses stories et l'estimation.<br /> <br /> Donc, si le Product Owner et les Développeurs de votre équipe passent la majorité du temps de la réunion de planification à discuter sémantique, essayez les réunions de Story Time pour vous permettre d'être plus efficace dans vos prévisions. Je serais curieux de savoir comment cela impacte votre métier au jour le jour.

Fabrice Aimetti : Page créée avec « Category: Kane Mar Category: Portail Product Owner
Auteur : [/Kane%20Mar Kane Mar]
Source : [htt... »

2018-07-01T09:27:41Z

Page créée avec « Category: Kane Mar Category: Portail Product Owner <div id="content_view" class="wiki" style="display: block"> Auteur : [/Kane%20Mar Kane Mar] Source : [htt... »

Nouvelle page

[[Category: Kane Mar]]
[[Category: Portail Product Owner]]
<div id="content_view" class="wiki" style="display: block"> Auteur : [/Kane%20Mar Kane Mar] Source : [http://kanemar.com/2008/02/14/story-time-the-hidden-scrum-meeting/ Story-Time! The Hidden Scrum Meeting] Date : 14/02/2008 
----
Traducteur : Fabrice Aimetti Date : 01/02/2011 
----
Traduction : Est-ce que votre équipe a des difficultés à prévoir lorsque le projet sera terminé ? Avez-vous un grand nombre de stories non-estimées dans votre backlog produit ? Vos réunions de planification traînent-elles longuement sur plusieurs journées en générant beaucoup de discussions ? Si c'est le cas, il se pourrait que vous ayez tendance à oublier de "nettoyer" régulièrement votre backlog produit. Ken Schwaber conseille généralement que l'équipe consacre cinq pour cent de son temps (à chaque sprint) sur la préparation du backlog. Ce procédé est généralement connu sous le nom de "affinage" (NdT : ''grooming'') ou maintenance. Voici une bonne définition de ce que cela implique : ''"Il y a beaucoup de choses que l'on fait dans le backlog pour préparer les futurs travaux. On ajoute de nouvelles stories et epics , on découpe des epics en stories, on estime, on ajoute la valeur métier espérée, et ainsi de suite." Dr. Dan Rawsthorne, CST'' J'ai récemment travaillé avec plusieurs clients qui approuvent la recommandation des cinq pour cent de Schwaber, mais qui en fait ne l'applique pas. Ils comprennent bien qu'ils ont besoin de passer cinq pour cent de leur temps sur la maintenance du backlog, mais ils ne le font pas et, par conséquent, leurs réunions de planification deviennent tendues et très longues. Depuis plusieurs années, je préconise explicitement la maintenance du backlog comme faisant partie intégrante du processus Scrum. Je conseille aux équipes de tenir périodiquement une réunion de deux heures chaque semaine. C'est une occasion de discuter et de maintenir le backlog, de sorte que la réunion de planification puisse être aussi efficace et productive que possible. J'appelle ces réunions "Story Time". Ce n'est pas un nouveau concept. Quand je travaillais exclusivement avec des équipes XP il y a plusieurs années, il était de pratique courante de tenir régulièrement une réunion Story Time. Bien que ça ne fasse pas officiellement partie de Scrum, j'ai découvert que le Story Time améliorait grandement la planification des projets et diminuait significativement les risques de discussions interminables qui apparaissent trop souvent dans de nombreuses équipes. Une réunion Story Time devrait se tenir à la même heure et au même endroit chaque semaine et impliquer toute l'équipe, y compris le Product Owner et le ScrumMaster. Le seul but de ces réunions hebdomadaires est de travailler sur le backlog produit pour préparer les futurs travaux. Ceci peut aussi inclure l'ajout de nouvelles stories et epics, le découpage de grosses stories et l'estimation. Donc, si le Product Owner et les Développeurs de votre équipe passent la majorité du temps de la réunion de planification à discuter sémantique, essayez les réunions de Story Time pour vous permettre d'être plus efficace dans vos prévisions. Je serais curieux de savoir comment cela impacte votre métier au jour le jour.

Story Time, la réunion Scrum cachée - Historique des versions

Fabrice Aimetti le 17 août 2018 à 11:09

Fabrice Aimetti le 23 juillet 2018 à 15:36

Fabrice Aimetti le 1 juillet 2018 à 09:27

Fabrice Aimetti : Page créée avec « Category: Kane Mar Category: Portail Product Owner Auteur : [/Kane%20Mar Kane Mar] Source : [htt... »

Fabrice Aimetti : Page créée avec « Category: Kane Mar Category: Portail Product Owner
Auteur : [/Kane%20Mar Kane Mar]
Source : [htt... »