sinraQu’est-ce qu’une Capability ?
Une capability est une fonctionnalité produit concrète : quelque chose que votre produit sera capable de faire une fois livré. Elle se situe au niveau d’abstraction que les product managers, développeurs et parties prenantes peuvent tous comprendre.
“Export CSV des rapports” est une capability. Soit elle est livrée, soit elle ne l’est pas. Il n’y a pas d’état ambigu “partiellement terminé”.
Capabilities vs Epics
La différence clé réside dans les critères de complétion :
| Epic | Capability | |
|---|---|---|
| Défini par | Des user stories regroupées | Une fonctionnalité produit concrète |
| Terminé quand | Tous les tickets enfants sont fermés | La fonctionnalité fonctionne comme défini |
| État | Reste souvent ouvert indéfiniment | Binaire : livré ou non |
| Communicable aux parties prenantes | Rarement | Oui, directement |
Un epic peut rester ouvert des mois au fur et à mesure que de nouveaux tickets s’ajoutent. Une capability a une décision de périmètre au départ : quand cette fonctionnalité est livrée, la capability se ferme.
Les Capabilities dans la Planification
Les capabilities sont l’unité de planification au niveau de la release. Quand vous définissez une release, vous lui assignez des capabilities. Cela répond à “que contiendra la version 2.4 ?” au niveau des fonctionnalités, pas au niveau des tickets.
Cela rend la planification des releases communicable :
“La version 2.4 inclut : export CSV, notifications email et gestion des rôles.”
Cette phrase fonctionne dans un standup d’équipe, une réunion avec les parties prenantes et un changelog produit.
Lier des Capabilities
Chaque capability se connecte à :
- Projet : l’initiative de haut niveau à laquelle elle appartient
- Release : quelle version livrera cette fonctionnalité
- Issues : les spécifications, plans, tâches et bugs qui la décrivent et la réalisent
- Testings : les cas de test QA qui la valident, éventuellement spécification par spécification
Cette chaîne assure une traçabilité complète depuis l’objectif stratégique (projet) jusqu’aux tâches individuelles (issues) et la validation (testings). Voir Traçabilité.
Les Issues par Spécification
La page d’une capability n’affiche pas une liste d’issues à plat. Chaque spécification forme un groupe qui contient ses plans et ses tâches, dans l’ordre de la chaîne, dessiné comme un arbre à raison d’une ligne par issue. Chaque ligne porte ses propres repères à droite :
- le statut de l’issue et, pour une spécification ou un plan, sa réalisation (Not started, In progress, Done) avec les tâches terminées sur le total
- le nombre de tests qui vérifient une spécification, ou No test yet
- le temps estimé d’une spécification, quand il n’est pas nul
Une spécification sans aucune tâche le dit clairement. Les issues sans parent (bugs, tâches isolées, plans orphelins) sont regroupées à part, après les spécifications (“Without parent”). Les issues d’autres capabilities qui Concern celle-ci sont listées séparément sous Concerned issues et ne comptent jamais dans son avancement.
La Release d’une Capability
Une capability appartient à une release au plus, et elle décide de la release de toutes ses issues. Déplacez la capability vers une autre release, ou retirez-la de toute release, et chaque issue suit dans la même opération, terminée ou non. Une capability n’est jamais à cheval sur deux releases. Quand vous placez une capability dans une release pour la première fois et qu’elle n’a pas encore de release souhaitée, Sinra recopie aussi cette release dans la release souhaitée. Voir Releases.
Corps de la Capability
Le corps de la capability utilise un éditeur riche. Les équipes écrivent généralement :
- Description de la fonctionnalité destinée aux utilisateurs
- Critères d’acceptation
- Notes techniques et contraintes
- Liens vers les ressources de design
Comme les capabilities sont partagées entre le produit et l’ingénierie, ce corps devient la spécification vivante de la fonctionnalité.
Suivi de Progression
La progression d’une capability est visible via :
- Tâches et bugs terminés sur le total. Les spécifications et les plans n’y comptent pas : leur propre avancement est la réalisation affichée sur chaque ligne.
- Temps estimé vs passé
- Statut d’acceptation des testings
La phase d’une capability sur le tableau de bord produit suit la même logique. Spécifications et plans sont du travail de rédaction, tâches et bugs du travail de développement. Une capability dont les spécifications sont écrites mais dont le plan est encore en rédaction est en phase de spécification. Elle passe en développement dès qu’une tâche ou un bug est en cours.
Cela donne une lecture rapide et honnête pour savoir si la capability est vraiment proche de la complétion ou si la plupart des tickets sont juste fermés.
La livraison à côté du statut d’écriture
Le statut d’écriture d’une capability dit seulement si sa spec est écrite. À côté, Livraison 2/5 issues compte les issues de développement terminées sur l’ensemble, pour qu’une capability dont la spec est faite ne passe pas pour livrée.