# 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 %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://guide-agile.wishtack.io/priorisation-and-planning/release-planning.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.