Dans Scrum, un incrément de produit est ce que vous avez précédemment construit, plus tout ce que vous venez de terminer dans le dernier sprint, le tout intégré, testé et prêt à être livré ou déployé.

https://resources.scrumalliance.org/Article/product-increment par Fadi Stephan

Dans Scrum, les équipes interfonctionnelles construisent des produits et des services en cycles courts en décomposant les gros produits et services en petits morceaux appelés incréments de produits qui peuvent être réalisés par une équipe interfonctionnelle dans un court laps de temps. Le livrable de chaque sprint est un incrément de produit fonctionnel.

Le Guide Scrum 2020 définit un incrément comme « une étape concrète vers l’objectif du produit. Chaque incrément s’ajoute à tous les incréments précédents et il est soigneusement vérifié, garantissant que tous les incréments fonctionnent ensemble. Pour fournir de la valeur, l’incrément doit être utilisable… Toute l’équipe Scrum est responsable de la création d’un incrément précieux et utile à chaque sprint ».

De nombreuses équipes ne comprennent pas ce concept et abordent toujours le développement de produits de la manière traditionnelle avec construire, construire, construire, puis intégrer, tester et déployer. Les équipes développent les sprints 1, 2 et 3, et ainsi de suite et dans un sprint « spécial » ultérieur, elles intègrent le tout, testent, emballent et livrent.

Dans cette approche traditionnelle, les équipes peuvent découper leur travail en fonction des fonctionnalités, des composants, des services ou des blocs de construction d’architecture tels que la construction du back-end d’abord, puis de la logique métier de niveau intermédiaire, puis de l’interface utilisateur (le front-end). Dans chaque scénario, ils atteignent la fin du sprint avec un incrément incomplet qui n’est pas utilisable. Ce n’est qu’après le sprint « spécial » beaucoup plus tardif que l’équipe fournit un incrément intégré et fonctionnel.

Dans Scrum, un incrément de produit est ce que vous avez précédemment construit, plus tout ce que vous venez de terminer dans le dernier sprint, le tout intégré, testé et prêt à être livré ou déployé.

Sans incrément de produit utilisable, les équipes de développement retardent la livraison de la valeur et manquent des opportunités d’obtenir de réels retours des utilisateurs et d’adapter le produit pour garantir la satisfaction du client. D’autre part, les versions incrémentales permettent un retour immédiat, une innovation plus rapide, une amélioration continue, une adaptation au changement et des clients plus satisfaits.

Ainsi, dans Scrum, vous générez et testez un élément dans le sprint 1, puis dans le sprint suivant, vous continuez à ajouter de nouvelles fonctionnalités intégrées et entièrement testées à cet élément. Ce que l’équipe publie après chaque sprint est souvent appelé itération. Lorsque vous construisez des choses de cette manière, de manière itérative et incrémentale, vous avez toujours une version utilisable de votre produit prête. Avec le développement itératif, vous pouvez toujours apprendre de ce que vous avez déjà, l’améliorer et y ajouter.

Vous pouvez commencer avec un squelette très mince de fonctionnalités intégrées de base de bout en bout, puis avec le temps, le rendre plus riche en fonctionnalités en fonction de l’apprentissage et des commentaires que vous obtenez de chaque sprint.

Rappelez-vous, si vous faites quelque chose qu’une seule fois, vous n’itérez pas. Si vous n’ajoutez pas à ce que vous avez déjà, vous n’incrémentez pas.

Lorsque vous commencez avec Scrum, cette approche itérative consistant à fournir un incrément de produit fonctionnel, testé, de haute qualité et potentiellement utilisable à chaque sprint semble impossible. Le simple fait d’essayer de terminer le code dans le sprint est déjà assez difficile. Comment êtes-vous censé gérer également l’exécution de tests unitaires, d’intégration et de régression au sein du même sprint ?

Y arriver prend du temps, vous devrez diviser le travail en petites tranches verticales et établir une forte culture d’ingénierie agile qui se concentre sur l’amélioration de la qualité dans chaque incrément au lieu de vérifier la qualité plus tard.

Article connexe:  How to Integrate Bug Fixes into your Product Backlog

Pour en savoir plus à ce sujet, consultez ces 8 steps to guide your team to technical excellence. Vous pouvez également renforcer votre définition de Done en utilisant cette définition de Done Canvas de Rickard Jones et John Barratt ou utiliser celle-ci dans vos rétrospectives. La clé est d’améliorer continuellement la qualité de votre incrément de produit afin que vos équipes puissent fournir un incrément de produit potentiellement utilisable à la fin de chaque sprint.

Recevez des articles et des vidéos de scrum et de pros agiles dans votre boîte de réception, y compris l’e-mail mensuel Practical Agility, abonnez-vous.