Ejemplos de estimación con story points: 12 historias resueltas

Las escalas abstractas se entienden más rápido con ejemplos concretos que con más teoría. Esta página recorre doce elementos realistas del backlog (una mezcla de funcionalidades, bugs y trabajo técnico), cada uno dimensionado con el razonamiento que un equipo real podría usar, tanto en la escala de Fibonacci como en la de tallas de camiseta. Para la teoría detrás de todo esto, empieza con la guía completa de story points.

Una nota antes de los ejemplos: ninguno de estos números es "correcto" en ningún sentido universal. Son ilustraciones del razonamiento, no una tabla de referencia para copiar en tu propio backlog: la estimación real de tu equipo depende de tu código, tu historia y tu calibración, exactamente como explica la guía completa.

1. Añadir una casilla de "recordarme" al formulario de inicio de sesión

Fibonacci: 1 · Talla de camiseta: XS

El cambio de UI es trivial, la lógica subyacente de extensión de sesión ya existe para otros flujos, y los criterios de aceptación son inequívocos. Nada aquí requiere discusión: una historia así normalmente obtiene votos casi unánimes en la primera ronda.

2. Permitir que los usuarios exporten su historial de pedidos como CSV

Fibonacci: 3 · Talla de camiseta: S

Moderado pero bien entendido: una consulta sobre datos existentes, un paso de serialización a CSV, un botón de descarga. La dispersión del equipo en una historia así suele ser ajustada (2-3-3-5), con quizás un votante señalando "¿qué pasa con los pedidos con más de 10,000 líneas?", algo que vale la pena aclarar antes de finalizar.

3. Integrar el flujo de pago de un nuevo proveedor

Fibonacci: 8 · Talla de camiseta: L

Complejidad real: API poco familiar, nuevos estados de error, manejo relacionado con PCI, y pruebas que probablemente requieren un entorno sandbox con sus propias particularidades. Este es el tipo de historia donde preguntar primero al que estimó más alto normalmente saca a la luz el riesgo real, a menudo algo como "el sandbox no soporta los casos de fallo que necesitamos probar".

4. Migrar el servicio de checkout a una nueva puerta de enlace de API interna

Fibonacci: ? (spike primero) · Talla de camiseta: aún no se puede estimar

El alcance es genuinamente desconocido hasta que alguien investigue qué requiere la nueva puerta de enlace y qué se rompe. Votar un número aquí sería teatro; la jugada honesta es un spike acotado en tiempo para producir un alcance, seguido de una estimación real sobre la historia de entrega resultante, ya entendida.

5. Corregir un error de redondeo en los cálculos del total del carrito

Fibonacci: 2 · Talla de camiseta: XS

Causa conocida (un problema de redondeo de punto flotante), solución conocida (redondear en el paso correcto del cálculo), bajo riesgo de regresión si la corrección está bien acotada. La estimación de bugs suele ser así de simple cuando la causa ya está diagnosticada; la complejidad solo aparece cuando la causa es desconocida.

6. Investigar por qué el checkout falla ocasionalmente para direcciones internacionales

Fibonacci: dimensionado en horas, no en puntos (historia de investigación) · Talla de camiseta: n/a

Este es un bug con causa desconocida; la jugada honesta es una investigación acotada en tiempo ("dedicar hasta 3 horas a identificar el patrón de fallo"), no una estimación de puntos sobre una corrección que nadie ha diagnosticado todavía. Una vez que la investigación produce un diagnóstico, la corrección resultante obtiene su propia historia, ahora sí estimable.

7. Refactorizar el servicio de notificaciones para eliminar una dependencia obsoleta

Fibonacci: 5 · Talla de camiseta: M

Deuda técnica con un alcance razonablemente bien entendido: el equipo sabe qué necesita cambiar, más o menos cuántos puntos de llamada están afectados, y ha hecho refactorizaciones similares antes. Si el alcance fuera más confuso ("no estamos seguros de qué tan profunda es esta dependencia"), esto empezaría con un spike centrado en la deuda en su lugar.

8. Añadir permisos basados en roles al panel de administración

Fibonacci: 13 (marcar para dividir) · Talla de camiseta: XL (marcar para dividir)

Un 13 o una XL es una señal, no una estimación cómoda. Esta historia probablemente abarca varios roles, varias pantallas, y cambios tanto de frontend como de backend. Buenas divisiones aquí: por rol (primero admin, luego editor, luego visor), o por pantalla (primero permisos en la lista de usuarios, luego permisos en configuración). Ver dividir historias de usuario para la lista completa de patrones.

9. Actualizar el texto del correo de onboarding para mayor claridad

Fibonacci: 1 · Talla de camiseta: XS

Un cambio de contenido sin lógica detrás. Historias así a veces reciben un voto inesperadamente alto de alguien que sabe que el sistema de plantillas de correo es frágil, que es exactamente el tipo de conocimiento oculto que la conversación de estimación existe para sacar a la luz.

10. Añadir cursores colaborativos en tiempo real al editor de documentos compartido

Fibonacci: 21 → dividir antes de estimar · Talla de camiseta: XXL → dividir antes de estimar

Esto no debería estimarse como una sola historia en absoluto: es una épica disfrazada de historia. Una primera división: (a) transmitir la posición del cursor propio de un usuario a los demás, (b) renderizar los cursores de otros usuarios en el editor, (c) manejar la posición del cursor durante ediciones concurrentes, (d) manejar la reconexión y la obsolescencia de datos. Cada una de esas es independientemente estimable; el conjunto tal como está escrito no lo es.

11. Añadir un interruptor de "modo oscuro" a la configuración de la cuenta

Fibonacci: 5 · Talla de camiseta: M

La complejidad interesante aquí normalmente no es el interruptor en sí, sino auditar cada pantalla existente en busca de colores fijos que no respetarán un cambio de tema. Un equipo que ya ha integrado el soporte de modo oscuro en su sistema de diseño podría votar esto un 2; un equipo que lo está retrofiteando sobre años de estilos improvisados podría votar un 8. La dispersión en esta historia exacta, más que casi cualquier otra en esta página, depende enteramente de lo que el código ya tiene implementado, que es exactamente por qué la misma historia produce estimaciones honestas diferentes en equipos diferentes.

12. Enviar una notificación de Slack cuando se crea un ticket de alta prioridad

Fibonacci: 3 · Talla de camiseta: S

Trabajo de integración bien acotado: un webhook, una plantilla de mensaje, una condición para "alta prioridad". La fuente más común de desacuerdo en una historia así no es el código, es los criterios de aceptación. "Alta prioridad" necesita una definición precisa antes de empezar a votar, o el equipo termina estimando tres versiones imaginarias distintas del mismo ticket. Este es un caso de manual para una compuerta de Definición de Listo.

Tabla resumen

Qué tienen en común estas doce historias

Nota el patrón: toda historia que obtuvo un voto limpio, rápido y con poca dispersión tenía criterios de aceptación claros y un enfoque técnico conocido. Toda historia que produjo una dispersión amplia, un spike, o una señal de "por favor divide esto" carecía de una de esas dos cosas. No es una coincidencia: es todo el mecanismo detrás de una estimación confiable. El refinamiento del backlog existe específicamente para convertir historias de la segunda categoría en la primera antes de que lleguen a una sesión de planificación de sprint.

Un segundo patrón que vale la pena notar: los tamaños de Fibonacci y de tallas de camiseta se corresponden bastante de cerca entre los doce ejemplos: un 1 casi siempre es una XS, un 5 casi siempre es una M. Esa correlación es normal y esperada; es por qué los equipos pueden moverse entre las dos escalas sin mucha fricción. Donde las dos realmente divergen es en los extremos: la talla de camiseta no tiene un equivalente de "hazlo un spike" o "horas, no puntos" para los elementos más complicados (el 6 y el 4 de arriba), porque la talla de camiseta nunca fue diseñada para capturar ese tipo de incertidumbre de alcance; está construida para la velocidad en trabajo aproximadamente entendido, no para señalar trabajo que no se entiende en absoluto. Esa brecha es una de las razones prácticas por las que el Scrum Poker con Fibonacci sigue siendo la opción por defecto para las historias listas para el sprint, incluso en equipos que usan tallas de camiseta más arriba en el backlog. La comparación completa entre las siete técnicas principales, no solo estas dos, está en técnicas de estimación agile.

Estima tu propio backlog

Leer ejemplos resueltos solo llega hasta cierto punto: la calibración real de tu equipo viene de estimar tus propias historias, no las de alguien más. Crea una sala gratuita, toma cinco elementos reales de tu backlog, y llévalos por una ronda apropiada: votos privados, revelación simultánea, discusión solo sobre las dispersiones. Si quieres un punto de partida rápido antes de que el equipo vote, la calculadora de story points convierte unas cuantas calificaciones en una carta sugerida.