Ejemplos de puntos de historia: una escala de referencia de 1 a 13
Seis ejemplos de backlog para ayudar a tu equipo a comparar trabajo, cuestionar suposiciones y elegir sus propias historias de referencia.
Una estimación en puntos de historia expresa el tamaño relativo del trabajo para un equipo, considerando esfuerzo, complejidad e incertidumbre. Esto convierte un ítem completado y familiar en una referencia útil para discutir el siguiente. La guía de estimación de Atlassian explica este enfoque relativo.
Por ejemplo, un equipo podría asignar 2 puntos a un cambio familiar en configuraciones y 5 a un nuevo flujo de notificaciones. La pregunta útil es: ¿qué trabajo adicional explica la diferencia?
Los ejemplos a continuación pertenecen a un equipo ficticio que construye un espacio de trabajo compartido para documentos. Son puntos de partida para una conversación, no precios estándar para funciones. Tu equipo puede elegir valores diferentes razonablemente.
Seis ejemplos en la escala de un equipo
Supongamos que este equipo ya dispone de una biblioteca de componentes, permisos del espacio de trabajo, un servicio de notificaciones y verificaciones automatizadas en sus flujos de trabajo existentes. Cada estimación incluye implementación, revisión y las verificaciones necesarias para cumplir la definición de terminado del equipo.
| Puntos | Ítem de backlog | Incluido en este ejemplo | Por qué este equipo lo coloca aquí |
|---|---|---|---|
| 1 | Explicar un feed de actividad vacío | Texto aprobado y un componente de estado vacío existente; sin comportamiento nuevo | Un cambio pequeño y familiar con pocos estados afectados |
| 2 | Permitir a administradores del espacio cambiar el nombre compartido | Formulario de configuración existente, API y chequeo de permisos de administrador; validación y estados guardados/error | Un camino familiar con algunas verificaciones de comportamiento; ítem de referencia del equipo |
| 3 | Filtrar documentos por su propietario | Componente de filtro existente y soporte de API; comportamiento de reinicio y resultados vacíos | Más estados de UI interactivos que la referencia, con una ruta de datos conocida |
| 5 | Notificar al propietario de un documento cuando alguien solicita acceso | Servicio de entrega existente; comprobaciones de permisos, contenido de la notificación, manejo de duplicados y enlace a la solicitud | Varias partes existentes deben trabajar juntas correctamente |
| 8 | Transferir la propiedad del documento dentro de un espacio de trabajo | Nueva operación de transferencia; cambios de permisos, ediciones concurrentes y una entrada de auditoría | Una transición de estado más amplia con casos de fallo que requieren acuerdo cuidadoso |
| 13 | Mover una carpeta y sus documentos a otro espacio de trabajo | Permisos de destino, enlaces, fallos parciales y comportamiento de recuperación | Demasiadas decisiones conectadas para que este equipo lo mantenga como un ítem cómodo; discutir dividir |
Las suposiciones sobre la infraestructura importan. Un equipo sin un servicio de notificaciones estimaría trabajo adicional en el ejemplo de 5 puntos. Un equipo con una operación probada de transferencia de propiedad podría asignar ese ítem a un nivel inferior.
Estos números no son una fórmula. Contar pantallas de UI, endpoints o criterios de aceptación no reproducirá las estimaciones de forma fiable.
Cómo el alcance cambia la estimación
Considera “cambiar el nombre visible de un espacio de trabajo.” La tabla asume que un administrador edita la etiqueta compartida mostrada en configuraciones, con un endpoint de actualización y verificación de permiso existentes.
Ahora cambia las condiciones de aceptación:
| Versión | Alcance | Estimación ilustrativa |
|---|---|---|
| A | Cambiar la etiqueta mostrada en la configuración del espacio; usar la operación de guardado existente | 2 |
| B | También actualizar el contenido de invitaciones y navegación en caché; mantener estas superficies coherentes si una actualización solo tiene éxito parcialmente | 5 |
| C | El nombre también determina la URL pública del espacio; preservar enlaces antiguos y manejar colisiones | Pausar para clarificar, luego posiblemente 8 o dividir |
La versión C plantea una cuestión de producto antes que de tamaño: ¿debería el cambio de nombre modificar la URL? Decidir mantener una URL estable podría eliminar gran parte del trabajo adicional.
Si un participante vota 2 y otro 8, pide a cada uno que describa el comportamiento que incluyó. Ambos pueden estar razonando de forma coherente sobre versiones diferentes. Reescribe las condiciones de aceptación antes de volver a votar.
Elige historias de referencia que tu equipo recuerde
Elige dos o tres ítems completados con límites claros. Un cambio pequeño y familiar, un flujo de trabajo moderado y un cambio más grande pero entendido ofrecen al equipo comparaciones más útiles que un solo número abstracto.
Para cada referencia, guarda una nota breve:
- ¿Qué resultado para el usuario entregó?
- ¿Qué sistemas y estados cambiaron?
- ¿Qué trabajo de revisión y verificación se incluyó?
- ¿Qué suposiciones lo hicieron sencillo o difícil?
Luego compara el trabajo nuevo con la referencia más cercana. “Esto se asemeja a nuestro cambio en configuraciones, pero añade dos rutas de permisos” ofrece algo concreto para cuestionar.
Si el equipo no tiene historial compartido de entregas, elige un ítem bien comprendido como referencia provisional. Revísalo tras la entrega y mantén visibles las suposiciones. No es necesario crear una escala perfecta antes de que el equipo haya aprendido conjuntamente.
Copia esta nota de estimación en un ítem de backlog
Usa lo siguiente como ayuda para la discusión en tu backlog o notas de equipo:
Resultado para el usuario:
Comportamiento incluido:
Excluido explícitamente:
Referencia completada más cercana:
Qué lo hace más pequeño o más grande:
Incógnitas que podrían cambiar el alcance:
Decisión: estimar / dividir / investigar
Estimación acordada, si está lista:
Próxima aclaración y responsable, si es necesaria:
Aquí tienes un ejemplo completo para el ítem de notificación de acceso:
Resultado para el usuario: el propietario del documento se entera de que un miembro del espacio de trabajo ha solicitado acceso y puede abrir la solicitud.
Incluye: usar el servicio de notificaciones existente, verificar permisos del destinatario, enlazar a la solicitud pendiente y evitar notificaciones duplicadas al reintentar la entrega.
Excluye: correos recordatorios, resúmenes diarios y otorgar acceso automáticamente.
Referencia: nuestro cambio de configuración de 2 puntos utiliza una ruta de guardado familiar. Este ítem une las rutas de solicitud, permiso y entrega, por lo que implica más coordinación y casos de fallo.
Pregunta abierta: ¿el servicio ya previene entregas duplicadas? El responsable del servicio de notificaciones confirmará antes de concretar la estimación.
En el escenario ficticio de la tabla, esa comprobación confirma soporte reusable de entrega y el equipo acuerda 5. Sin ella, el equipo debe discutir el trabajo adicional antes de usar el mismo número. La referencia explica la comparación; no calcula la respuesta.
Para la secuencia de la reunión, usa la guía paso a paso de Planning Poker. Cubre votación privada, discusión de diferencias y elección del resultado de la siguiente ronda.
Cuando un número aún no es útil
Vuelve a la aclaración cuando una incógnita cambia la naturaleza del trabajo. “¿Qué texto debe usar la notificación?” es una incertidumbre diferente de “¿Permite el espacio de destino usuarios externos?”
En el ejemplo de mover carpeta, el equipo podría primero acordar un resultado de usuario más pequeño: mover un documento entre espacios que el usuario administra. Ese primer fragmento aún necesita permisos claros en destino, reglas de acceso preservadas y manejo seguro de fallos para que un movimiento interrumpido no pierda el documento ni lo exponga a personas incorrectas. Mover lotes de documentos puede ser un ítem separado. Reducir el tamaño del lote reduce el trabajo; no elimina la necesidad de manejar fallos.
Tras dividir, estima cada ítem por separado. Los nuevos números no tienen que sumar 13: el equipo ha cambiado el alcance y ha aprendido más sobre el trabajo.
Preguntas frecuentes de los equipos
¿Cuántas horas representa una historia de 3 puntos?
No existe una conversión universal. Los ejemplos aquí comparan trabajo dentro de un equipo ficticio. Si necesitas una previsión de entrega, utiliza tu propio historial de entregas y capacidad actual, y discute la incertidumbre separada de la etiqueta del punto.
¿Cada error es un ítem de 1 punto?
No. Un error reproducible de visualización con causa conocida es diferente de una pérdida intermitente de datos cuya causa aún es desconocida. Aclara qué estás estimando: la corrección, una investigación o ambos.
¿Debe cada equipo dividir una historia de 13 puntos?
No. Aquí, 13 señala trabajo que este equipo en particular quiere examinar y dividir. El límite de tu equipo depende de sus referencias y capacidad para entender y entregar un ítem.
Lleva tus referencias a Planning Poker
Elige algunos ítems próximos, escribe sus límites de aceptación y mantén tus historias de referencia junto a ellos. Usa Agilo Planning Poker para la sesión de estimación del equipo.
Crea una sala de Planning Poker cuando los ítems estén listos para discutir.
