> For the complete documentation index, see [llms.txt](https://guide-agile.wishtack.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guide-agile.wishtack.io/priorisation-and-planning/release-planning.md).

# Release Planning

## Objectifs du Release Planning

L'agilité n'empêche pas la planification à moyen ou long terme.

Le Release Planning est une **"macro" planification** *(ou planification haut niveau)* permettant de **définir une ligne directrice** en **se projetant sur plusieurs semaines ou plusieurs mois**.

Le Release Planning permet :

* ⏱D'estimer les **dates de disponibilité** des nouvelles fonctionnalités *(fixed scope)* ou inversement, les fonctionnalités disponibles à une certaine date *(fixed deadline)*.
* 🚨De **déceler les problèmes et retards** puis réagir le plus tôt possible.
* 🎯De **partager une vision d'ensemble**.
* 📦Synchroniser les équipes en cas d'interdépendance.

## Durée Couverte par le Release Planning

{% hint style="warning" %}
Plus la **durée couverte par le planning est longue**, plus la planification sera complexe et **moins elle sera précise**.

Une planification à plus de 6 mois est rarement rentable *(rapport : énergie de planification vs précision)*.
{% endhint %}

{% hint style="info" %}
**Le Release Planning n'est pas nécessaire.**

La plupart du temps, une planification à 3 ou 4 itérations *(avec des itérations d'une semaine)* suffit largement.

Cela est d'autant plus vrai dans le cadre d'une approche Lean Management.
{% endhint %}

## Release Planning vs Deployment

{% hint style="warning" %}
Contrairement à une idée communément reçue, le Release Planning **n'est pas lié au déploiement** des fonctionnalités implémentées.

Idéalement, l'équipe de développement devrait déployer ses changements en continu jusqu'à plusieurs fois par jour. Les fonctionnalités sont ensuite activées et déployées progressivement via des Feature Flags *(Cf.* [*Déploiement Continu*](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/deploiement-continu.md)*)*.
{% endhint %}

## Prérequis

* Un [*Product Backlog*](/scrum/artefacts/product-backlog.md) priorisé et estimé *(cette priorisation est généralement effectuée progressivement lors du* [*Backlog Refinement*](/scrum/evenements/backlog-refinement.md)*)*.
* La vélocité de l'équipe.
* La disponibilité de l'équipe *(i.e. : workforce)*.

## Release Planning

Grâce aux prérequis définis ci-dessus, il suffit de déduire les dates de livraison en distribuant les [User Stories](/scrum/artefacts/user-story.md) sur les itérations en fonction de la [vélocité](/scrum/mesures-et-outils/velocite.md) de l'équipe.

![Exemple de Release Planning continu sur Pivotal Tracker](/files/-LbJSVWst6BjGMWBUUPq)

![Exemple de Release Planning avec releases sur Pivotal Tracker](/files/-LbJSYqybxpsi-GMbUKu)

{% hint style="info" %}
Grâce au calcul de vélocité et l'estimation des *User Stories* à venir, on constate à l'avance qu'il ne sera pas possible d'inclure la fonctionnalité "...share wishlist" à la date du 5 mai.

Deux possibilités s'offrent à nous :\
\- Reporter la Release "v3" à la semaine suivante.\
\- Reporter la fonctionnalité à une autre Release.\
\- Reporter ou annuler une autre fonctionnalité.
{% endhint %}