4.4Backlog, historias de usuario & estimación (planning poker)
Lo esencial en 30 segundos
- Backlog : lista priorizada y viva de todo lo que aportaría valor.
- Historia de usuario : « Como…, quiero…, para… » — el valor antes que la técnica.
- Reflejo : estimar en puntos (relativo) en planning poker (Fibonacci), no en días.
Mini-caso hilado — Bilal escribe el backlog con el cliente
Para nutrir sus sprints (4.2) y su flujo (4.3), Bilal debe clarificar la necesidad : con el cliente, reformula 5 solicitudes en historias de usuario (« Como…, quiero…, para… »), las prioriza por valor, y luego el equipo las estima en puntos en planning poker. El backlog ha nacido — y seguirá vivo.
Continuación del caso 4.1-4.3 — Bilal equipa el valor antes de equipar el seguimiento.
1. El backlog y las historias de usuario
En ágil, el trabajo por hacer vive en el backlog de producto : una lista priorizada y evolutiva de todo lo que aportaría valor. Sus elementos se expresan a menudo en historias de usuario : « Como [rol], quiero [acción] para [beneficio] ».
Esta formulación mantiene el foco en el valor para el usuario, no en la solución técnica.
2. Estimar en puntos
Para estimar, lo ágil prefiere a menudo los puntos (medida relativa de complejidad/esfuerzo) a las duraciones absolutas, vía el planning poker : cada uno estima con cartas (serie de Fibonacci), se discuten las diferencias, se converge.
Se estima en equipo, se prioriza por valor, y se ajusta a lo largo de los sprints.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Por qué puntos, no días
Comparar más que predecir.
El humano compara mejor (« es 2× más grande ») que predice duraciones.
Puntos = esfuerzo relativo, independiente de quién hace y de las interrupciones.
→ la velocidad (puntos/sprint) permite luego prever sin falsa precisión.Resultado : un pilotaje por el valor, sin falsa precisión.
Reflejo : una buena historia es INVEST (incluido « probable »).
Vocabulario de la sección
- Backlog de producto
- Lista priorizada y evolutiva de todo el trabajo de valor del producto. El PO es responsable.
Ejemplo sencillo: El backlog de Bilal, llevado por Amine, ordena las 5 historias por valor.
Lo que no es: un pliego de condiciones fijado firmado de una vez por todas.
Reflejo: en cada sprint : reordenar y afinar, nunca fijar.
- Historia de usuario
- Expresión de una necesidad del lado del usuario : « Como…, quiero…, para… ». Centrada en el valor.
Ejemplo sencillo: « Como cliente, quiero seguir mi solicitud para evitar las llamadas ».
Lo que no es: una especificación técnica que describe la solución a codificar.
Reflejo: sin « para » creíble, la historia no está lista.
- Puntos (story points)
- Medida RELATIVA del esfuerzo/complejidad de una historia, preferida a las duraciones absolutas en ágil.
Ejemplo sencillo: Esta historia vale 5 puntos : 2 veces más grande que una historia de 2.
Lo que no es: un número de días prometido al cliente.
Reflejo: comparar las historias entre ellas, nunca convertir 1 punto = 1 día.
- Planning poker
- Técnica de estimación colectiva donde cada uno propone un valor (cartas Fibonacci), luego se discute y se converge.
Ejemplo sencillo: El equipo de Bilal vota 3, 5, 8 : se hace hablar a los extremos y luego se revota.
Lo que no es: el PO que impone solo sus cifrados en días.
Reflejo: las diferencias son oro : hacer hablar los votos extremos.
- Priorización
- Ordenar el backlog por valor (y esfuerzo), para trabajar siempre primero en lo que más importa.
Ejemplo sencillo: Bilal hace primero la historia de fuerte valor y bajo esfuerzo.
Lo que no es: tratar las solicitudes por orden de llegada.
Reflejo: saber siempre qué está arriba del backlog — y por qué.
En la práctica — En la práctica — Redactar y estimar un backlog
- Formula 5 necesidades en historias de usuario : « Como [rol], quiero [acción] para [beneficio] ».
- Priorízalas por valor para el usuario (y esfuerzo) : ¿qué aporta más, más rápido?
- Estímalas en puntos vía un planning poker : cada uno propone (Fibonacci : 1,2,3,5,8…), discutid las diferencias, converged.
- Mantén vivo el backlog : se reordena y se afina en cada sprint según los aprendizajes.
Script listo para decir — hacer escribir una verdadera historia de usuario (30 s)
« Reformulemos esta necesidad del lado del usuario : ¿como quién? ¿Quiere hacer qué? ¿Para obtener qué beneficio? Mientras el “para” no esté claro, no priorizamos ni estimamos. ¿Quién propone la primera versión? »
Para decir en taller backlog : el « para » es la prueba que separa la historia de la spec técnica.
Modelo copiar-pegar — ficha backlog + estimación
HISTORIA : Como ___, quiero ___ para ___.
VALOR (fuerte / medio / bajo) : ___ | RANGO : ___
ESTIMACIÓN (planning poker, Fibonacci) : ___ puntos
VELOCIDAD EQUIPO (puntos/sprint) : ___ | PREVISIÓN : ___ sprints
AFINADO PREVISTO (fecha) : ___TPE / presupuesto pequeño
5 historias en tarjetas de papel, estimación a mano alzada en Fibonacci : el ritual cuenta más que la herramienta.
Equipo a distancia
Votos simultáneos en línea (cartas ocultas y luego reveladas) para evitar el anclaje en la primera opinión.
Pyme Argelia
Bilal hace validar cada « para » por un verdadero usuario local, no por un intermediario.
Backlog enorme
Estimar fino solo lo alto del backlog ; lo bajo queda en grano grueso hasta que suba.
✓ Buenas prácticas
- Formula las necesidades del lado del usuario (el « para » es esencial).
- Estima colectivamente en puntos, no en duraciones absolutas.
- Mantén vivo el backlog y priorizado por valor.
✗ Errores frecuentes
- Redactar specs técnicas en vez de historias de usuario.
- Estimar en días absolutos (falsa precisión).
- Congelar el backlog en vez de afinarlo en cada sprint.
Puntos clave
- El backlog de producto es la lista priorizada y evolutiva del trabajo de valor.
- Las historias de usuario expresan la necesidad del lado del usuario (rol/acción/beneficio).
- Lo ágil estima a menudo en puntos (esfuerzo relativo), no en duraciones absolutas.
- El planning poker hace estimar al equipo colectivamente (Fibonacci).
Reto 48h — aplica mañana
Escribe 5 necesidades reales en historias de usuario con su « para », priorízalas por valor, y luego estímalas en planning poker (modelo anterior).
- Sé escribir una historia de usuario completa (rol/acción/beneficio).
- Distingo puntos (relativo) y días (falsa precisión).
- Mi backlog de 5 historias está priorizado y estimado.
Preguntas frecuentes
¿Por qué estimar en puntos más que en días?
Porque el humano es mejor comparando (« es dos veces más grande que eso ») que prediciendo duraciones absolutas. Los puntos miden el esfuerzo relativo, independientemente de quién hace el trabajo y de las interrupciones. A lo largo de los sprints, el equipo mide su « velocidad » (puntos realizados por sprint), lo que permite prever sin atraparse con falsas precisiones en días. Una estimación en días da una ilusión de precisión que los azares desmienten rápido.
¿Qué hace una buena historia de usuario?
Una buena historia está centrada en el valor de usuario (el « para » es esencial), es independiente, negociable, estimable, bastante pequeña para caber en un sprint, y probable (se sabe decir cuándo está « hecha »). A menudo se resumen esas cualidades con el acrónimo INVEST. Una historia no es una especificación técnica : es una conversación a tener alrededor de una necesidad. El « para » recuerda permanentemente por qué se hace la cosa.
¿Cómo se expresa una necesidad en un backlog ágil?