Une technique pour aider à prioriser votre backlog - Historique des versions

Fabrice Aimetti le 18 avril 2020 à 14:04

2020-04-18T14:04:58Z

← Version précédente		Version du 18 avril 2020 à 14:04
Ligne 17 :		Ligne 17 :
	Nous avons une technique que nous enseignons aux Product Owners pour les aider à définir les priorités parmi les demandes des différentes parties prenantes. La matrice ci-dessous vous montre une manière de représenter tout le travail qui doit être réalisé dans votre backlog selon deux axes : le temps et les personnes à qui votre travail rend le plus grand service. Selon notre expérience, il est plus facile d'obtenir un accord de la part de vos parties prenantes si vous définissez que les fonctionnalités qui participent au support client ne représente que 50% maxi. (par exemple) de votre capacité, alors que ce sera plus difficile de justifier qu'un élément de dette technique soit plus important qu'une fonctionnalité client. Une fois que vous êtes d'accord sur le ratio de capacité à consacrer à une activité particulière (le total doit faire 100%), vous pouvez demander à vos parties prenantes de prioriser dans chaque quadrant de la matrice les choses les plus importantes sur lesquelles consacrer la part de capacité dédiée.<br />		Nous avons une technique que nous enseignons aux Product Owners pour les aider à définir les priorités parmi les demandes des différentes parties prenantes. La matrice ci-dessous vous montre une manière de représenter tout le travail qui doit être réalisé dans votre backlog selon deux axes : le temps et les personnes à qui votre travail rend le plus grand service. Selon notre expérience, il est plus facile d'obtenir un accord de la part de vos parties prenantes si vous définissez que les fonctionnalités qui participent au support client ne représente que 50% maxi. (par exemple) de votre capacité, alors que ce sera plus difficile de justifier qu'un élément de dette technique soit plus important qu'une fonctionnalité client. Une fois que vous êtes d'accord sur le ratio de capacité à consacrer à une activité particulière (le total doit faire 100%), vous pouvez demander à vos parties prenantes de prioriser dans chaque quadrant de la matrice les choses les plus importantes sur lesquelles consacrer la part de capacité dédiée.<br />
	<br />		<br />
	[[Image:Quadrant_PrioritisationSlide_fr.png\|Quadrant_PrioritisationSlide_fr.png\|border]]<br />		[[Image:Quadrant_PrioritisationSlide_fr.png\|Quadrant_PrioritisationSlide_fr.png\|border\|link=]]<br />
	<br />		<br />
	'''Passé et Métier (Quadrant 1).''' Ici le passé se réfère aux fonctionnalités existantes ou aux clients existants. Les parties prenantes Métier parlent d'éléments sur lesquels les clients sont en demande. Les éléments qui arrivent dans ce quadrant sont généralement appelés des éléments de support. Cela peut être des demandes de corrections d'anomalies qui ont été formulées par les clients, ou de petites évolutions sur une fonctionnalité existante pour améliorer la vie d'un client particulier. Les éléments de ce quadrant ne vous apporteront pas de nouveaux clients, mais ils auront une influence sur la fidélisation et le bonheur de vos clients existants. Ce quadrant repose souvent sur les contrats de maintenance et de support, donc c'est en fait un quadrant générateur de revenus.<br />		'''Passé et Métier (Quadrant 1).''' Ici le passé se réfère aux fonctionnalités existantes ou aux clients existants. Les parties prenantes Métier parlent d'éléments sur lesquels les clients sont en demande. Les éléments qui arrivent dans ce quadrant sont généralement appelés des éléments de support. Cela peut être des demandes de corrections d'anomalies qui ont été formulées par les clients, ou de petites évolutions sur une fonctionnalité existante pour améliorer la vie d'un client particulier. Les éléments de ce quadrant ne vous apporteront pas de nouveaux clients, mais ils auront une influence sur la fidélisation et le bonheur de vos clients existants. Ce quadrant repose souvent sur les contrats de maintenance et de support, donc c'est en fait un quadrant générateur de revenus.<br />

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

2018-08-17T09:16:34Z

← Version précédente		Version du 17 août 2018 à 09:16
Ligne 1 :		Ligne 1 :
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	[[Category: Dette technique]]		[[Category: Dette technique]]
			[[Category: Growing Agile]]
	Auteur : Sam Laing<br />		Auteur : Sam Laing<br />
	Source : [http://www.growingagile.co.za/2014/06/a-technique-to-help-prioritise-your-backlog/ A technique to help Prioritise your Backlog]<br />		Source : [http://www.growingagile.co.za/2014/06/a-technique-to-help-prioritise-your-backlog/ A technique to help Prioritise your Backlog]<br />

Fabrice Aimetti le 15 août 2018 à 17:20

2018-08-15T17:20:37Z

@@ Ligne 10 : / Ligne 10 : @@
 Traduction :<br />
 <br />
-En tant que Product Owner, avez-vous déjà ressenti que vous aviez trop de travail et pas assez de temps, ou trop de parties prenantes réclamant à cor et à cri que leurs éléments de backlog soient réalisés en premier ? N'avez-vous jamais eu à vous attaquer à la dette technique ou à des innovations parce que la direction des ventes vous demande sans cesse de nouvelles fonctionnalités ?<br /> <br />  Savoir correctement prioriser des éléments du backlog est l'une des difficultés que nous constatons souvent. Disposer d'un backlog priorisé correctement est cependant précieux. Cela vous garantit que l'équipe est en train de travailler sur les éléments les plus importants pour le Métier et que votre produit va dans la bonne direction. Le travail le plus important que vous ayez en tant que Product Owner est de décider comment utiliser au mieux la capacité de votre équipe.<br /> <br />  Nous avons une technique que nous enseignons aux Product Owners pour les aider à définir les priorités parmi les demandes des différentes parties prenantes. La matrice ci-dessous vous montre une manière de représenter tout le travail qui doit être réalisé dans votre backlog selon deux axes : le temps et les personnes à qui votre travail rend le plus grand service. Selon notre expérience, il est plus facile d'obtenir un accord de la part de vos parties prenantes si vous définissez que les fonctionnalités qui participent au support client ne représente que 50% maxi. (par exemple) de votre capacité, alors que ce sera plus difficile de justifier qu'un élément de dette technique soit plus important qu'une fonctionnalité client. Une fois que vous êtes d'accord sur le ratio de capacité à consacrer à une activité particulière (le total doit faire 100%), vous pouvez demander à vos parties prenantes de prioriser dans chaque quadrant de la matrice les choses les plus importantes sur lesquelles consacrer la part de capacité dédiée.<br /> <br /> [[Image:Quadrant_PrioritisationSlide_fr.png|Quadrant_PrioritisationSlide_fr.png]]<br /> <br /> '''Passé et Métier (Quadrant 1).''' Ici le passé se réfère aux fonctionnalités existantes ou aux clients existants. Les parties prenantes Métier parlent d'éléments sur lesquels les clients sont en demande. Les éléments qui arrivent dans ce quadrant sont généralement appelés des éléments de support. Cela peut être des demandes de corrections d'anomalies qui ont été formulées par les clients, ou de petites évolutions sur une fonctionnalité existante pour améliorer la vie d'un client particulier. Les éléments de ce quadrant ne vous apporteront pas de nouveaux clients, mais ils auront une influence sur la fidélisation et le bonheur de vos clients existants. Ce quadrant repose souvent sur les contrats de maintenance et de support, donc c'est en fait un quadrant générateur de revenus.<br /> <br /> '''Futur et Métier (Quadrant 2).''' Ce quadrant est souvent celui sur lequel les gens se concentrent, surtout s'il y a un objectif de gagner de nouveaux clients. Les éléments de ce quadrant concerneront des choses qui permettent de gagner de nouveaux clients. Cela concerne les nouvelles fonctionnalités, la mise à l'échelle, la nouvelle plateforme de support pour un nouveau type d'utilisateur.<br /> <br /> '''Passé et Technique (Quadrant 3).''' Ce quadrant est souvent oublié. Il concerne essentiellement des éléments qui existent et qui impactent l'équipe technique. La dette technique constitue un bon exemple. Par exemple, une fonctionnalité peut être mal développée et donc ne pas être très robuste ; ce qui génère des anomalies à chaque fois que l'équipe travaille dessus. Ici les éléments n'apportent généralement pas de revenus, mais bien choisis ils peuvent générer de grandes économies. Un autre exemple peut-être un élément qui fasse gagner énormément de temps à l'équipe support. Par exemple, si votre équipe support doit analyser des sujets complexes, le fait de journaliser des informations supplémentaires peut aider l'équipe à réduire le temps qu'elle consacre globalement à ces sujets.<br /> <br /> '''Future et Technique (Quadrant 4).''' Ce quadrant est tourné vers l'avenir avec une connotation technique. Souvent, les architectes donnent des idées dans ce quadrant. Potentiellement, une nouvelle technologie est disponible et va significativement simplifier votre produit. D'autres éléments peuvent concerner la mise à jour de vos couches technologiques existantes, avant que la technologie que vous utilisiez devienne obsolète. Par exemple, la mise à jour avec la dernière version de Java. Ces éléments peuvent parfois générer des revenus, parce qu'ils séduisent les clients, mais généralement ils génèrent des économies puisque la nouvelle technologie simplifie les développements réalisés par l'équipe.
+En tant que Product Owner, avez-vous déjà ressenti que vous aviez trop de travail et pas assez de temps, ou trop de parties prenantes réclamant à cor et à cri que leurs éléments de backlog soient réalisés en premier ? N'avez-vous jamais eu à vous attaquer à la dette technique ou à des innovations parce que la direction des ventes vous demande sans cesse de nouvelles fonctionnalités ?<br />

Fabrice Aimetti le 15 août 2018 à 17:19

2018-08-15T17:19:30Z

← Version précédente		Version du 15 août 2018 à 17:19
Ligne 1 :		Ligne 1 :
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	[[Category: Dette technique]]		[[Category: Dette technique]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteur : Sam Laing<br /> Source : [http://www.growingagile.co.za/2014/06/a-technique-to-help-prioritise-your-backlog/ A technique to help Prioritise your Backlog]<br /> Date : 24/06/2014<br />		Auteur : Sam Laing<br />
			Source : [http://www.growingagile.co.za/2014/06/a-technique-to-help-prioritise-your-backlog/ A technique to help Prioritise your Backlog]<br />
			Date : 24/06/2014<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 16/09/2016<br />		Traducteur : Fabrice Aimetti<br />
			Date : 16/09/2016<br />
	----		----
	''Traduction :''<br /> <br /> En tant que Product Owner, avez-vous déjà ressenti que vous aviez trop de travail et pas assez de temps, ou trop de parties prenantes réclamant à cor et à cri que leurs éléments de backlog soient réalisés en premier ? N'avez-vous jamais eu à vous attaquer à la dette technique ou à des innovations parce que la direction des ventes vous demande sans cesse de nouvelles fonctionnalités ?<br /> <br /> Savoir correctement prioriser des éléments du backlog est l'une des difficultés que nous constatons souvent. Disposer d'un backlog priorisé correctement est cependant précieux. Cela vous garantit que l'équipe est en train de travailler sur les éléments les plus importants pour le Métier et que votre produit va dans la bonne direction. Le travail le plus important que vous ayez en tant que Product Owner est de décider comment utiliser au mieux la capacité de votre équipe.<br /> <br /> Nous avons une technique que nous enseignons aux Product Owners pour les aider à définir les priorités parmi les demandes des différentes parties prenantes. La matrice ci-dessous vous montre une manière de représenter tout le travail qui doit être réalisé dans votre backlog selon deux axes : le temps et les personnes à qui votre travail rend le plus grand service. Selon notre expérience, il est plus facile d'obtenir un accord de la part de vos parties prenantes si vous définissez que les fonctionnalités qui participent au support client ne représente que 50% maxi. (par exemple) de votre capacité, alors que ce sera plus difficile de justifier qu'un élément de dette technique soit plus important qu'une fonctionnalité client. Une fois que vous êtes d'accord sur le ratio de capacité à consacrer à une activité particulière (le total doit faire 100%), vous pouvez demander à vos parties prenantes de prioriser dans chaque quadrant de la matrice les choses les plus importantes sur lesquelles consacrer la part de capacité dédiée.<br /> <br /> [[Image:Quadrant_PrioritisationSlide_fr.png\|Quadrant_PrioritisationSlide_fr.png]]<br /> <br /> '''Passé et Métier (Quadrant 1).''' Ici le passé se réfère aux fonctionnalités existantes ou aux clients existants. Les parties prenantes Métier parlent d'éléments sur lesquels les clients sont en demande. Les éléments qui arrivent dans ce quadrant sont généralement appelés des éléments de support. Cela peut être des demandes de corrections d'anomalies qui ont été formulées par les clients, ou de petites évolutions sur une fonctionnalité existante pour améliorer la vie d'un client particulier. Les éléments de ce quadrant ne vous apporteront pas de nouveaux clients, mais ils auront une influence sur la fidélisation et le bonheur de vos clients existants. Ce quadrant repose souvent sur les contrats de maintenance et de support, donc c'est en fait un quadrant générateur de revenus.<br /> <br /> '''Futur et Métier (Quadrant 2).''' Ce quadrant est souvent celui sur lequel les gens se concentrent, surtout s'il y a un objectif de gagner de nouveaux clients. Les éléments de ce quadrant concerneront des choses qui permettent de gagner de nouveaux clients. Cela concerne les nouvelles fonctionnalités, la mise à l'échelle, la nouvelle plateforme de support pour un nouveau type d'utilisateur.<br /> <br /> '''Passé et Technique (Quadrant 3).''' Ce quadrant est souvent oublié. Il concerne essentiellement des éléments qui existent et qui impactent l'équipe technique. La dette technique constitue un bon exemple. Par exemple, une fonctionnalité peut être mal développée et donc ne pas être très robuste ; ce qui génère des anomalies à chaque fois que l'équipe travaille dessus. Ici les éléments n'apportent généralement pas de revenus, mais bien choisis ils peuvent générer de grandes économies. Un autre exemple peut-être un élément qui fasse gagner énormément de temps à l'équipe support. Par exemple, si votre équipe support doit analyser des sujets complexes, le fait de journaliser des informations supplémentaires peut aider l'équipe à réduire le temps qu'elle consacre globalement à ces sujets.<br /> <br /> '''Future et Technique (Quadrant 4).''' Ce quadrant est tourné vers l'avenir avec une connotation technique. Souvent, les architectes donnent des idées dans ce quadrant. Potentiellement, une nouvelle technologie est disponible et va significativement simplifier votre produit. D'autres éléments peuvent concerner la mise à jour de vos couches technologiques existantes, avant que la technologie que vous utilisiez devienne obsolète. Par exemple, la mise à jour avec la dernière version de Java. Ces éléments peuvent parfois générer des revenus, parce qu'ils séduisent les clients, mais généralement ils génèrent des économies puisque la nouvelle technologie simplifie les développements réalisés par l'équipe.		Traduction :<br />
			<br />
			En tant que Product Owner, avez-vous déjà ressenti que vous aviez trop de travail et pas assez de temps, ou trop de parties prenantes réclamant à cor et à cri que leurs éléments de backlog soient réalisés en premier ? N'avez-vous jamais eu à vous attaquer à la dette technique ou à des innovations parce que la direction des ventes vous demande sans cesse de nouvelles fonctionnalités ?<br /> <br /> Savoir correctement prioriser des éléments du backlog est l'une des difficultés que nous constatons souvent. Disposer d'un backlog priorisé correctement est cependant précieux. Cela vous garantit que l'équipe est en train de travailler sur les éléments les plus importants pour le Métier et que votre produit va dans la bonne direction. Le travail le plus important que vous ayez en tant que Product Owner est de décider comment utiliser au mieux la capacité de votre équipe.<br /> <br /> Nous avons une technique que nous enseignons aux Product Owners pour les aider à définir les priorités parmi les demandes des différentes parties prenantes. La matrice ci-dessous vous montre une manière de représenter tout le travail qui doit être réalisé dans votre backlog selon deux axes : le temps et les personnes à qui votre travail rend le plus grand service. Selon notre expérience, il est plus facile d'obtenir un accord de la part de vos parties prenantes si vous définissez que les fonctionnalités qui participent au support client ne représente que 50% maxi. (par exemple) de votre capacité, alors que ce sera plus difficile de justifier qu'un élément de dette technique soit plus important qu'une fonctionnalité client. Une fois que vous êtes d'accord sur le ratio de capacité à consacrer à une activité particulière (le total doit faire 100%), vous pouvez demander à vos parties prenantes de prioriser dans chaque quadrant de la matrice les choses les plus importantes sur lesquelles consacrer la part de capacité dédiée.<br /> <br /> [[Image:Quadrant_PrioritisationSlide_fr.png\|Quadrant_PrioritisationSlide_fr.png]]<br /> <br /> '''Passé et Métier (Quadrant 1).''' Ici le passé se réfère aux fonctionnalités existantes ou aux clients existants. Les parties prenantes Métier parlent d'éléments sur lesquels les clients sont en demande. Les éléments qui arrivent dans ce quadrant sont généralement appelés des éléments de support. Cela peut être des demandes de corrections d'anomalies qui ont été formulées par les clients, ou de petites évolutions sur une fonctionnalité existante pour améliorer la vie d'un client particulier. Les éléments de ce quadrant ne vous apporteront pas de nouveaux clients, mais ils auront une influence sur la fidélisation et le bonheur de vos clients existants. Ce quadrant repose souvent sur les contrats de maintenance et de support, donc c'est en fait un quadrant générateur de revenus.<br /> <br /> '''Futur et Métier (Quadrant 2).''' Ce quadrant est souvent celui sur lequel les gens se concentrent, surtout s'il y a un objectif de gagner de nouveaux clients. Les éléments de ce quadrant concerneront des choses qui permettent de gagner de nouveaux clients. Cela concerne les nouvelles fonctionnalités, la mise à l'échelle, la nouvelle plateforme de support pour un nouveau type d'utilisateur.<br /> <br /> '''Passé et Technique (Quadrant 3).''' Ce quadrant est souvent oublié. Il concerne essentiellement des éléments qui existent et qui impactent l'équipe technique. La dette technique constitue un bon exemple. Par exemple, une fonctionnalité peut être mal développée et donc ne pas être très robuste ; ce qui génère des anomalies à chaque fois que l'équipe travaille dessus. Ici les éléments n'apportent généralement pas de revenus, mais bien choisis ils peuvent générer de grandes économies. Un autre exemple peut-être un élément qui fasse gagner énormément de temps à l'équipe support. Par exemple, si votre équipe support doit analyser des sujets complexes, le fait de journaliser des informations supplémentaires peut aider l'équipe à réduire le temps qu'elle consacre globalement à ces sujets.<br /> <br /> '''Future et Technique (Quadrant 4).''' Ce quadrant est tourné vers l'avenir avec une connotation technique. Souvent, les architectes donnent des idées dans ce quadrant. Potentiellement, une nouvelle technologie est disponible et va significativement simplifier votre produit. D'autres éléments peuvent concerner la mise à jour de vos couches technologiques existantes, avant que la technologie que vous utilisiez devienne obsolète. Par exemple, la mise à jour avec la dernière version de Java. Ces éléments peuvent parfois générer des revenus, parce qu'ils séduisent les clients, mais généralement ils génèrent des économies puisque la nouvelle technologie simplifie les développements réalisés par l'équipe.

Fabrice Aimetti le 26 juillet 2018 à 11:53

2018-07-26T11:53:23Z

← Version précédente		Version du 26 juillet 2018 à 11:53
Ligne 1 :		Ligne 1 :
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
			[[Category: Dette technique]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : Sam Laing<br /> Source : [http://www.growingagile.co.za/2014/06/a-technique-to-help-prioritise-your-backlog/ A technique to help Prioritise your Backlog]<br /> Date : 24/06/2014<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : Sam Laing<br /> Source : [http://www.growingagile.co.za/2014/06/a-technique-to-help-prioritise-your-backlog/ A technique to help Prioritise your Backlog]<br /> Date : 24/06/2014<br />
	----		----

Fabrice Aimetti : Page créée avec « Category: Portail Product Owner
Auteur : Sam Laing
Source : [http://www.growingagile.co.za/2014/06/a... »

2018-07-11T08:21:19Z

Page créée avec « Category: Portail Product Owner <div id="content_view" class="wiki" style="display: block"> Auteur : Sam Laing Source : [http://www.growingagile.co.za/2014/06/a... »

Nouvelle page

[[Category: Portail Product Owner]]
<div id="content_view" class="wiki" style="display: block"> Auteur : Sam Laing Source : [http://www.growingagile.co.za/2014/06/a-technique-to-help-prioritise-your-backlog/ A technique to help Prioritise your Backlog] Date : 24/06/2014 
----
Traducteur : Fabrice Aimetti Date : 16/09/2016 
----
''Traduction :'' En tant que Product Owner, avez-vous déjà ressenti que vous aviez trop de travail et pas assez de temps, ou trop de parties prenantes réclamant à cor et à cri que leurs éléments de backlog soient réalisés en premier ? N'avez-vous jamais eu à vous attaquer à la dette technique ou à des innovations parce que la direction des ventes vous demande sans cesse de nouvelles fonctionnalités ? Savoir correctement prioriser des éléments du backlog est l'une des difficultés que nous constatons souvent. Disposer d'un backlog priorisé correctement est cependant précieux. Cela vous garantit que l'équipe est en train de travailler sur les éléments les plus importants pour le Métier et que votre produit va dans la bonne direction. Le travail le plus important que vous ayez en tant que Product Owner est de décider comment utiliser au mieux la capacité de votre équipe. Nous avons une technique que nous enseignons aux Product Owners pour les aider à définir les priorités parmi les demandes des différentes parties prenantes. La matrice ci-dessous vous montre une manière de représenter tout le travail qui doit être réalisé dans votre backlog selon deux axes : le temps et les personnes à qui votre travail rend le plus grand service. Selon notre expérience, il est plus facile d'obtenir un accord de la part de vos parties prenantes si vous définissez que les fonctionnalités qui participent au support client ne représente que 50% maxi. (par exemple) de votre capacité, alors que ce sera plus difficile de justifier qu'un élément de dette technique soit plus important qu'une fonctionnalité client. Une fois que vous êtes d'accord sur le ratio de capacité à consacrer à une activité particulière (le total doit faire 100%), vous pouvez demander à vos parties prenantes de prioriser dans chaque quadrant de la matrice les choses les plus importantes sur lesquelles consacrer la part de capacité dédiée. [[Image:Quadrant_PrioritisationSlide_fr.png|Quadrant_PrioritisationSlide_fr.png]] '''Passé et Métier (Quadrant 1).''' Ici le passé se réfère aux fonctionnalités existantes ou aux clients existants. Les parties prenantes Métier parlent d'éléments sur lesquels les clients sont en demande. Les éléments qui arrivent dans ce quadrant sont généralement appelés des éléments de support. Cela peut être des demandes de corrections d'anomalies qui ont été formulées par les clients, ou de petites évolutions sur une fonctionnalité existante pour améliorer la vie d'un client particulier. Les éléments de ce quadrant ne vous apporteront pas de nouveaux clients, mais ils auront une influence sur la fidélisation et le bonheur de vos clients existants. Ce quadrant repose souvent sur les contrats de maintenance et de support, donc c'est en fait un quadrant générateur de revenus. '''Futur et Métier (Quadrant 2).''' Ce quadrant est souvent celui sur lequel les gens se concentrent, surtout s'il y a un objectif de gagner de nouveaux clients. Les éléments de ce quadrant concerneront des choses qui permettent de gagner de nouveaux clients. Cela concerne les nouvelles fonctionnalités, la mise à l'échelle, la nouvelle plateforme de support pour un nouveau type d'utilisateur. '''Passé et Technique (Quadrant 3).''' Ce quadrant est souvent oublié. Il concerne essentiellement des éléments qui existent et qui impactent l'équipe technique. La dette technique constitue un bon exemple. Par exemple, une fonctionnalité peut être mal développée et donc ne pas être très robuste ; ce qui génère des anomalies à chaque fois que l'équipe travaille dessus. Ici les éléments n'apportent généralement pas de revenus, mais bien choisis ils peuvent générer de grandes économies. Un autre exemple peut-être un élément qui fasse gagner énormément de temps à l'équipe support. Par exemple, si votre équipe support doit analyser des sujets complexes, le fait de journaliser des informations supplémentaires peut aider l'équipe à réduire le temps qu'elle consacre globalement à ces sujets. '''Future et Technique (Quadrant 4).''' Ce quadrant est tourné vers l'avenir avec une connotation technique. Souvent, les architectes donnent des idées dans ce quadrant. Potentiellement, une nouvelle technologie est disponible et va significativement simplifier votre produit. D'autres éléments peuvent concerner la mise à jour de vos couches technologiques existantes, avant que la technologie que vous utilisiez devienne obsolète. Par exemple, la mise à jour avec la dernière version de Java. Ces éléments peuvent parfois générer des revenus, parce qu'ils séduisent les clients, mais généralement ils génèrent des économies puisque la nouvelle technologie simplifie les développements réalisés par l'équipe.