De la stratégie au plan opérationnel

Établir une stratégie produit

La vision du produit, constituée entre autres de ses objectifs et de sa valeur, représente un point ou une cible à atteindre. Ce point est le fruit d’une étude factuelle, basée sur des éléments existants aujourd’hui, et sur une conduite d’anticipation, basée sur des choses à venir.

La stratégie produit définit de quelle manière le Product Owner espère faire cheminer le produit de l’état actuel jusqu’à l’état cible. L’état actuel peut être représenté par un produit fonctionnel ou un produit imaginaire, tel un projet. Lorsque le Product Owner dispose d’une stratégie produit, il est capable de rassurer les équipes de développement et les parties prenantes. Cette capacité est essentielle quand la Scrum Team rencontrera des difficultés liées au développement du produit.

La vision du produit représente une cible, l’endroit où l’on souhaite amener le produit. La stratégie produit constitue la route à suivre.

1. Les spécificités d’une stratégie produit dans un cycle itératif et incrémental

Dans un cycle séquentiel, le chef de projet établit une stratégie de moyens sous la contrainte d’un budget et d’un délai. Ce faisant, il fige les moyens d’atteindre les objectifs, ce qui peut aller jusqu’à la production de spécifications détaillées illustrant la mise en œuvre des moyens retenus. La stratégie de moyens repose sur un organigramme des tâches et un plan de charge dont les informations seront consolidées dans un diagramme de Gantt.

L’organisation est contrainte par la charge estimée. Les moyens sont figés, et toute modification ultérieure a un impact sur le budget et le délai.

Dans un cycle itératif et incrémental, le Product Owner établit une stratégie produit. Il ne fige pas les moyens, mais se concentre au contraire sur les objectifs et leur priorisation. Il ne planifie pas l’activité par rapport à un plan de charge mais selon l’importance qu’il accorde à chaque objectif....

Un plan opérationnel

À partir de la vision du produit, s’appuyant sur la notion de valeur, le Product Owner dessine un chemin à suivre avec sa stratégie. Ce n’est pour l’instant qu’une vue théorique. Elle peut s’appuyer sur des éléments tangibles, très factuels, mais cela n’engage pas encore l’équipe. Un plan opérationnel (à ne pas confondre avec un organigramme des tâches ou un diagramme de Gantt) enjoint l’équipe à prendre le chemin tracé. Il comporte deux aspects : une vision à long terme décrivant comment l’équipe pourrait atteindre les objectifs fixés et quels sont les moyens alloués en matière de budget, de ressources ou de temps ; puis une vision à court terme affinant le cadre des prochains Sprints.

Le plan opérationnel n’est pas construit par le Product Owner, mais par la Scrum Team à partir de la stratégie qu’il a établie.

1. Une vision à long terme

Dans un projet reposant sur un cycle séquentiel, la vision à long terme est traduite par un diagramme de Gantt, de PERT ou un macroplanning. Ces éléments de planification reposent sur des estimations de charges et de durée portant sur ce qui doit être réalisé. Plus les moyens sont finement détaillés, plus la planification sera proche de la réalité. Cela force le chef de projet à figer durablement une stratégie de moyens.

Dans un cycle itératif et incrémental, la vision à long terme porte sur les objectifs. Le raisonnement du Product Owner est totalement différent de celui du chef de projet. Pourquoi devons-nous tenter d’atteindre cet objectif en priorité ? C’est une question qu’il se pose lorsqu’il établit sa stratégie. Dans quel ordre serait-il judicieux de les traiter ? Combien de fois allons-nous itérer ? Combien de temps peut-on consacrer à tenter d’atteindre au mieux cet objectif ? Ce sont des questions qu’il se pose au moment d’entrer dans la partie opérationnelle.

Le Product Owner planifie l’activité à long terme afin de s’assurer que sa stratégie est...

Affiner sa vision par rapport à la valeur du produit

Le Product Owner peut avoir une vision du produit avant même d’avoir rencontré les Developers ou la construire dans les tout premiers Sprints mais, dans tous les cas, il doit pouvoir affiner celle-ci, voire la modifier profondément en fonction des retours du marché, c’est-à-dire selon l’usage réel qui est fait des premières itérations par les consommateurs ou les utilisateurs, ou selon les bénéfices réels du produit à la date de l’inspection. C’est la base de l’empirisme.

S’il a élaboré sa vision sans avoir consulté la Scrum Team, ce travail d’affinage doit impérativement se faire avec elle, sans attendre les retours des utilisateurs, mais en se basant sur un affinage des coûts potentiels.

Dans tous les cas, cette démarche doit permettre au Product Owner de mieux prioriser ses objectifs, donc son plan de release, et de s’adapter à la situation actuelle, tout en restant focalisé sur les objectifs produit à long terme.

Afin d’affiner la valeur du produit, et donc la vision produit, le Product Owner peut mesurer les gains potentiels et réels, mais également les coûts, et en déduire un bénéfice. C’est sur le bénéfice que son attention est focalisée, car il représente la valeur du produit.

1. Les gains du produit

Il peut s’agir des gains financiers, mais également d’un accroissement de l’image de marque, du temps de parcours, de la performance, d’une meilleure sécurisation, etc.

a. À court terme

Dès la première mise en service ou release du produit, le Product Owner doit mesurer les gains réels et les comparer aux gains escomptés initialement. Il peut ainsi mesurer précisément et de manière empirique si les objectifs sont partiellement atteints ou dépassés.

Les écarts sont analysés avec les parties prenantes lors des revues de Sprint, en présence de l’équipe de développement ou, mieux encore, avec l’équipe de développement.

Il n’y a donc pas besoin de maintenir de comité de pilotage ou de direction de projet. La revue...