Les features représentent des parties du produit qui apportent une valeur significative à ses utilisateurs. Les features sont généralement trop importantes pour être traitées directement, elles sont donc divisées en unités commerciales plus petites: les stories. En ce qui concerne la planification, la production d’une feature dure généralement plusieurs sprints. Les features aident à concrétiser une vision et à partager celle-ci avec l’équipe agile et les parties prenantes (Stakeholders).

Dans iceScrum, les features peuvent recevoir une couleur unique et chaque story associée à une feature obtiendra automatiquement la même couleur. C’est un moyen efficace de distinguer visuellement les stories et par exemple de connaître la feature qui recevra le plus d’effort durant un sprint.

Le workflow des features comprend trois états:

• A faire: n’a pas de story avec un état plus avancé que Planifiée,
• En cours: n’a pas été passée à Finie et a au moins une story à un état plus avancé que Planifiée,
• Fini: a toutes ses stories Finies et a été passée à Finie (soit manuellement soit automatiquement). Il n’est pas possible de créer des stories sur une feature Finie.

Vous pouvez en apprendre plus sur les permission des features dans la documentation dédiée.

Le concept d’un item métier de haut niveau est parfois appelé « Epique » ou « Epic », dans iceScrum on l’appelle « Feature ». Le mot « épique » existe dans iceScrum mais il a un sens différent: les stories épiques sont des stories trop grosses pour être réalisées dans un sprint et doivent donc être découpée en stories plus petites. Alors que les features restent au côté de leurs stories, les stories épiques sont temporaires : elles sont remplacées par les stories résultantes.

Une story doit être réalisable lors d’un sprint, elle doit donc être aussi petite que possible.

Dans iceScrum une story peut être de 3 types :

• Story d’utilisateur: une story qui apporte de la valeur aux parties prenantes (Stakeholders) / utilisateurs, comme une nouvelle fonction ou une amélioration du produit
• Défaut: quelque chose qui enlève de la valeur et qui doit être réparé, ce qu’on appelle habituellement un bug.
• Story technique: une story qui apporte de la valeur à l’équipe, par exemple qui réduit les risques, augmente les connaissances techniques, améliore la qualité technique…
• Story épique: story trop grosse pour être réalisée dans un sprint et qui doit donc être découpée en stories plus petites.

Durant sa vie dans iceScrum une story passera par au plus 8 états :

• Suggérée : Chaque idée est d’abord soumise dans le bac à sable
• Acceptée : Si elle est reconnue comme une idée valable pour le projet par le Product Owner, elle est acceptée dans le backlog de produit
• Estimée : Une fois que l’équipe a estimé l’effort pour réaliser la story, elle est prête à être planifiée
• Planifiée : La story est planifiée dans un sprint qui n’est pas encore en cours.
• En cours : La story fait partie du sprint en cours
• En validation : Le développement est terminé et la story est en cours de test / validation (disponible avec l’App Workflow des stories)
• Finie : La story a été validée par le Product Owner
• Gelée : La story apporte de la valeur, mais ne correspond pas à la vision actuelle (disponible avec l’App Workflow des stories)

Voici une représentation simplifiée du workflow de story. Il inclut les états de la story, l’emplacement de la story pour chaque état, et les rôles qui sont autorisés changer d’état. Certaines actions permettent de sauter plusieurs états, mais pour des raisons de simplicité, elles ne sont pas représentées dans ce diagramme.

Vous pourrez en savoir plus sur les permissions en lisant la documentation dédiée.

Les tests d’acceptation (souvent nommés critères d’acceptation) sont attachés à une story pour définir ce que l’on attend exactement de cette story. Ils sont l’endroit où sont définies les règles métier et les contraintes liées à cette story. Ils devraient être écrits pour chaque story d’utilisateur avant le début du sprint. L’équipe est donc consciente du résultat attendu dès qu’ils commencent à travailler sur la story.

Lorsque le sprint est en cours, l’état d’un test d’acceptation peut être modifié manuellement:

• A vérifier (default)
• Échec
• Succès

Jusqu’à ce qu’une story soit, En cours, tous ses tests d’acceptation sont A vérifier. Une fois qu’une story est Finie, tous ses tests d’acceptation sont passés à Succès.

Pour en savoir plus sur les autorisations de test d’acceptation vous pouvez lire la documentation dédiée.

Afin de réaliser une story, l’équipe doit effectuer certaines activités structurées telles que des tâches. Contrairement aux autres items présentés ici, une tâche ne fait pas partie des résultats du projet, c’est plutôt le moyen de produire le résultat. Une tâche peut être effectuée par un seul membre de l’équipe, tandis que la réalisation d’une story est la responsabilité de toute l’équipe. En plus des tâches de story, des tâches peuvent être créées en dehors d’une story en tant que tâches urgentes et tâches récurrentes. Les tâches attachées à une story peuvent évoluer à mesure qu’elle progresse.

Lorsque le sprint est en cours, l’état d’une tâche peut être modifié manuellement par glisser-déposer :

• A faire (par défaut)
• En cours
• Terminé

une fois qu’une story est Terminée, toutes ses tâches sont à l’état Fini.

Vous pouvez en apprendre plus sur les autorisations de tâches dans la documentation dédiée.