Scrum Burndown Chart de Release Amélioré - Historique des versions

Fabrice Aimetti le 23 août 2018 à 14:44

Fabrice Aimetti — Thu, 23 Aug 2018 14:44:16 GMT

← Version précédente		Version du 23 août 2018 à 14:44
Ligne 1 :		Ligne 1 :
	[[Category: Mike Cohn]]		[[Category: Mike Cohn]]
	[[Category: Portail Planification]]		[[Category: Portail Planification]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteur : Mike Cohn<br /> Source : [http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown Alternative Scrum Release Burndown Chart]<br />		Auteur : Mike Cohn<br />
			Source : [http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown Alternative Scrum Release Burndown Chart]<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />		Traducteur : Fabrice Aimetti<br />
			Date : 03/07/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif\|left]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><br /><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><br /><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].		Traduction :<br />
			<br />
			<span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif\|left]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><br /><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><br /><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].

Fabrice Aimetti le 17 juillet 2018 à 07:47

Fabrice Aimetti — Tue, 17 Jul 2018 07:47:42 GMT

← Version précédente		Version du 17 juillet 2018 à 07:47
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><br /><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><br /><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif\|left]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><br /><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><br /><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].

Fabrice Aimetti le 1 juillet 2018 à 11:32

Fabrice Aimetti — Sun, 01 Jul 2018 11:32:56 GMT

← Version précédente		Version du 1 juillet 2018 à 11:32
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><br /><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span~~><span style="display: block; text-align: justify"~~><br /~~> </span><span style="display: block; text-align: justify"><br /> </span~~><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><br /><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><br /><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].

Fabrice Aimetti le 1 juillet 2018 à 11:32

Fabrice Aimetti — Sun, 01 Jul 2018 11:32:26 GMT

← Version précédente		Version du 1 juillet 2018 à 11:32
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><br /><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].

Fabrice Aimetti le 1 juillet 2018 à 11:31

Fabrice Aimetti — Sun, 01 Jul 2018 11:31:52 GMT

← Version précédente		Version du 1 juillet 2018 à 11:31
Ligne 1 :		Ligne 1 :
	[[Category: Mike Cohn]]		[[Category: Mike Cohn]]
	[[Category: Portail Planification]]		[[Category: Portail Planification]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : ~~[/Mike%20Cohn~~ Mike Cohn]<br /> Source : [http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown Alternative Scrum Release Burndown Chart]<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : Mike Cohn<br /> Source : [http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown Alternative Scrum Release Burndown Chart]<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].

Fabrice Aimetti le 1 juillet 2018 à 11:31

Fabrice Aimetti — Sun, 01 Jul 2018 11:31:36 GMT

← Version précédente		Version du 1 juillet 2018 à 11:31
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span~~></span><span style="display: block; text-align: justify"~~><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].

Fabrice Aimetti le 1 juillet 2018 à 11:31

Fabrice Aimetti — Sun, 01 Jul 2018 11:31:09 GMT

← Version précédente		Version du 1 juillet 2018 à 11:31
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span></span><span style="display: block; text-align: justify"><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :~~</span>~~</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span></span><span style="display: block; text-align: justify"><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].

Fabrice Aimetti le 1 juillet 2018 à 11:30

Fabrice Aimetti — Sun, 01 Jul 2018 11:30:34 GMT

← Version précédente		Version du 1 juillet 2018 à 11:30
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span></span><span style="display: block; text-align: justify"><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span></span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]~~</span><br />~~ </span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span></span><span style="display: block; text-align: justify"><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span></span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].

Fabrice Aimetti le 1 juillet 2018 à 11:29

Fabrice Aimetti — Sun, 01 Jul 2018 11:29:54 GMT

← Version précédente		Version du 1 juillet 2018 à 11:29
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span></span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span><br /> </span>~~<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br />~~ Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span></span><span style="display: block; text-align: justify"><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span></span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span><br /> </span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].

Fabrice Aimetti le 1 juillet 2018 à 11:28

Fabrice Aimetti — Sun, 01 Jul 2018 11:28:29 GMT

← Version précédente		Version du 1 juillet 2018 à 11:28
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span></span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span><br /> </span><br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif\|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif\|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span></span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif\|altrelburndown3.gif]]</span><br /> </span><br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel].