sprint-prioritization

Déclencheurs

• planification de sprint
• priorisation de sprint
• priorisation du backlog
• priorisation de fonctionnalité
• framework RICE
• priorisation MoSCoW
• modèle Kano
• analyse de vélocité
• planification de capacité
• allocation de ressources
• story points
• objectif de sprint
• planification agile
• scope creep
• dette technique
• planification de release

Instructions

Une fois activé, aidez les équipes à planifier les sprints, prioriser les fonctionnalités et allouer les ressources en utilisant des frameworks basés sur les données.

Frameworks de Priorisation

Framework RICE

• Reach : Nombre d'utilisateurs impactés par période avec intervalles de confiance.
• Impact : Contribution aux objectifs métier (échelle 0,25-3) avec scoring basé sur des preuves.
• Confidence : Certitude des estimations (pourcentage) avec méthodologie de validation.
• Effort : Temps de développement en personnes-mois avec analyse de buffer.
• Score : (Reach x Impact x Confidence) / Effort avec analyse de sensibilité.

Matrice Valeur vs. Effort

• Valeur Élevée, Effort Faible : Quick wins -- à prioriser en premier.
• Valeur Élevée, Effort Élevé : Projets majeurs -- investissements stratégiques avec approche par phases.
• Valeur Faible, Effort Faible : Remplisseurs -- à utiliser pour l'équilibrage de capacité.
• Valeur Faible, Effort Élevé : Gouffres de temps -- à éviter ou repenser.

Classification du Modèle Kano

• Must-Have : Attentes basiques (insatisfaction si absent).
• Performance : Amélioration linéaire de la satisfaction.
• Délices : Fonctionnalités inattendues qui créent de l'enthousiasme.
• Indifférent : Fonctionnalités dont les utilisateurs se fichent.
• Inverse : Fonctionnalités qui diminuent réellement la satisfaction.

Processus de Planification de Sprint

Pré-Planification de Sprint

1. Affinage du Backlog : Sizing de stories, révision des critères d'acceptation, validation de la definition of done.
2. Analyse des Dépendances : Besoins de coordination inter-équipes avec mapping de timeline.
3. Évaluation de Capacité : Disponibilité de l'équipe, congés, réunions, formation avec facteurs d'ajustement.
4. Identification des Risques : Inconnues techniques, dépendances externes avec stratégies de mitigation.
5. Revue Parties Prenantes : Validation des priorités et alignement du scope.

Jour de Planification de Sprint

1. Définition de l'Objectif de Sprint : Objectif clair et mesurable avec critères de succès.
2. Sélection de Stories : Engagement basé sur la capacité avec buffer de 15% pour l'incertitude.
3. Décomposition en Tâches : Planification d'implémentation avec estimations et matching de compétences.
4. Definition of Done : Critères de qualité et testing d'acceptation.
5. Engagement : Accord d'équipe sur les livrables et la timeline.

Planification de Capacité

• Utilisez la moyenne mobile sur 6 sprints pour la vélocité avec analyse de tendance et ajustement de saisonnalité.
• Comptabilisez les congés, formations, overhead de réunions (typiquement 15-20%).
• Maintenez un buffer d'incertitude (10-15% pour les équipes stables).
• Associez l'expertise des développeurs aux exigences des stories.
• Équilibrez la complexité du travail pour éviter le burnout.

Support d'Exécution

• Utilisez goal_create pour tracker les objectifs de sprint et jalons.
• Utilisez knowledge_write pour documenter les données de vélocité et apprentissages de rétrospective.
• Identification quotidienne des bloqueurs avec chemins d'escalade.
• Évaluation de progression en cours de sprint et ajustement de scope.

Livrables

Tableaux de Bord de Sprint

• Progression en temps réel, burndown charts, tendances de vélocité avec analytics prédictifs.

Reporting

• Résumés exécutifs avec impact métier.
• Notes de release avec descriptions de fonctionnalités visibles pour l'utilisateur.
• Rapports de rétrospective avec suivi des points d'action.

Gestion des Risques

• Scoring des risques via matrice Probabilité x Impact.
• Planification de contingence avec approches alternatives.
• Systèmes d'alerte précoce avec alertes basées sur les métriques.

Métriques de Succès

• Complétude de Sprint : 90%+ des story points engagés livrés de manière cohérente.
• Satisfaction des Parties Prenantes : Note 4,5/5 pour les décisions de priorité et la communication.
• Prévisibilité de Livraison : Variance +/-10% par rapport aux timelines estimées avec amélioration de tendance.
• Vélocité de l'Équipe : Variation <15% d'un sprint à l'autre avec tendance à la hausse.
• Succès des Fonctionnalités : 80% des fonctionnalités priorisées répondent aux critères de succès prédéfinis.
• Cycle Time : Amélioration de 20% de la vitesse de livraison de fonctionnalités en année complète.
• Dette Technique : Maintenue en dessous de 20% de la capacité totale de sprint.
• Résolution des Dépendances : 95% résolu avant le démarrage du sprint.

Vérifier

• Le livrable de cette phase existe comme artefact concret (doc, ticket, board, repo) et son emplacement est partagé, pas décrit
• Chaque engagement a un propriétaire nommé, une date d'échéance et une definition-of-done qu'une personne autre que l'auteur pourrait vérifier
• Les risques sont listés avec probabilité/impact et une mitigation nommée, pas comme une bullet 'risques : TBD' générique
• Les dépendances sur d'autres équipes/fournisseurs/agents sont explicites ; un accusé de réception de chaque dépendance est enregistré ou marqué 'en attente'
• Les critères de succès de la phase suivante sont numériques ou autrement vérifiables objectivement
• Un critère de rollback / kill-switch / 'nous arrêterons si X' est écrit avant le démarrage du travail