Estimation user story t-shirt sizing

---
name: estimation-user-story-tshirt
description: "Estime la taille d'une user story en t-shirt sizing (XS, S, M, L, XL) à partir d'une description courte, en explicitant les critères d'estimation (incertitude technique, périmètre, tests, dépendances) et en signalant les zones de doute à clarifier en refinement. À utiliser quand un dev, tech lead, product manager ou scrum master prépare un refinement, un sprint planning ou une roadmap trimestrielle, et veut une estimation calibrée plutôt que des story points aléatoires."
metadata:
  iaskills_title: "Estimation user story t-shirt sizing"
  metier_slug: dev
  metiers:
    - Mode technique
  secteur: "Tech & DSI"
  tier: free
  compatible:
    - claude-code
    - cowork
    - cursor
    - codex
  version: "1.0.0"
  author: "iaskills"
  editorial:
    pitch: "Estime une user story en t-shirt sizing (XS à XL) avec critères explicites, équivalent jours dev et zones de doute à clarifier en refinement."
    long_description: "Le t-shirt sizing est un outil d'estimation plus rapide et moins faussement précis que les story points. Ce skill prend en entrée la description d'une user story et produit une estimation XS, S, M, L ou XL, justifiée par 4 critères explicites : incertitude technique, périmètre fonctionnel, effort de test, dépendances externes. Il propose un équivalent jours dev (calibré sur une équipe senior fullstack), signale les zones de doute à clarifier en refinement et suggère un découpage si la story est XL. Aligne sur les conventions agiles (INVEST, refinement, definition of done) sans imposer une méthodo précise."
    bullets:
      - "5 tailles XS S M L XL"
      - "4 critères d'estimation explicites"
      - "Équivalent jours dev fourchette basse haute"
      - "Zones de doute à clarifier"
      - "Suggestion de découpage si XL"
    exemple_avant: "Le dev répond « 5 points » sans pouvoir justifier, le PM compare avec d'autres stories de même taille mais sans logique partagée. L'estimation est invalidée 2 semaines plus tard, le sprint dérape."
    exemple_apres: "Story estimée M (3 à 5 jours dev), 4 critères justifiés, 2 zones de doute identifiées en refinement (mécanisme de retry, format des erreurs API tierce), découpage en 2 stories proposé pour réduire le risque."
    recommended_metiers:
      - consultant
      - dirigeant-pme
    secteurs:
      - tech-dsi
      - startup-vc
      - conseil-audit
      - assurance-banque
      - medias-publishing
      - communication-rp
    metiers_individuels:
      - dev-backend
      - dev-frontend
      - product-manager
      - chef-de-projet-it
      - scrum-master
      - qa-engineer
      - architecte-si
      - cto
      - devops
    connecteurs:
      - notion
      - slack
---

# Estimation user story t-shirt sizing

## Quand utiliser ce skill

Déclencher quand un dev fullstack, backend, frontend, tech lead, product manager, chef de projet IT ou scrum master prépare un refinement, un sprint planning ou une roadmap trimestrielle, et veut estimer une user story. Le skill cible des stories techniques B2B (SaaS, API, app interne) sur un stack moderne (TypeScript, Python, Go, Postgres, cloud). Ne pas utiliser pour estimer un projet entier (downscope vers une story ou un epic), pour de l'effort marketing ou design (autre logique), ou pour des bugs critiques en production (workflow d'incident, pas d'estimation).

## Ce que tu dois faire

1. Demander la description de la user story au format INVEST si elle n'est pas fournie : en tant que [persona], je veux [action], afin de [bénéfice]. Critères d'acceptation listés. Si l'utilisateur ne fournit qu'un titre, demander les détails minimums : périmètre, comportement attendu, comportement en cas d'erreur, surface UI touchée si frontend.
2. Évaluer la story selon 4 critères, chacun noté de 1 (trivial) à 5 (très incertain) : incertitude technique (techno connue ou nouvelle, niveau de complexité algo), périmètre fonctionnel (nombre de comportements, surface UI ou API), effort de test (unitaire, intégration, e2e, charge), dépendances externes (API tierce, équipe autre, migration BD).
3. Sommer les 4 scores et mapper sur une taille : 4-6 → XS (moins de 0.5 jour), 7-9 → S (0.5 à 1.5 jour), 10-13 → M (2 à 5 jours), 14-17 → L (1 à 2 sprints), 18-20 → XL (plus de 2 sprints, à découper).
4. Identifier les zones de doute à clarifier en refinement. Ces zones doivent être posées comme questions ouvertes (« quel comportement attendu si l'API tierce répond 500 ? », pas « gérer les erreurs »). Lister 2 à 4 questions maximum.
5. Si la taille est L ou XL, proposer un découpage en 2 ou 3 stories plus petites avec critères d'acceptation distincts. Ne pas découper artificiellement (toujours respecter INVEST : Independent, Negotiable, Valuable, Estimable, Small, Testable).
6. Préciser les hypothèses de calibration : équipe senior fullstack, stack maîtrisée, code review intégrée, tests obligatoires dans la definition of done. Si l'équipe diffère, ajuster à la hausse.