PBI - Product Backlog Item vs Historias de Usuario

Un PBI (Product Backlog Item), o Elemento del Product Backlog, es cualquier elemento de trabajo que forma parte del Product Backlog en Scrum. Los PBIs representan todo el trabajo que el equipo necesita realizar para desarrollar, mejorar y mantener el producto.

Según la Guía de Scrum (2020), el Product Backlog es "una lista emergente y ordenada de lo que se necesita para mejorar el producto", y cada ítem en esa lista es un PBI. El Product Owner es el responsable de gestionar el Product Backlog, lo que incluye crear, ordenar, refinar y comunicar los PBIs al equipo.

Los PBIs son la unidad fundamental de planificación en Scrum. Durante el Sprint Planning, el equipo selecciona PBIs del Product Backlog para incluirlos en el Sprint Backlog, comprometiéndose a completarlos durante el Sprint. La cantidad de PBIs seleccionados se basa en la velocidad histórica del equipo y la capacidad disponible.

A diferencia de lo que muchos creen, un PBI no es solo una historia de usuario. Es un término más amplio que engloba cualquier tipo de elemento que el Product Owner considere necesario para el producto.

Historia de usuario (User Story)

El tipo de PBI más común. Describe una funcionalidad desde la perspectiva del usuario:

Como [tipo de usuario] Quiero [funcionalidad] Para [beneficio/valor] Ejemplo: Como comprador en la tienda online Quiero filtrar productos por rango de precio Para encontrar productos dentro de mi presupuesto rápidamente

Las historias de usuario incluyen criterios de aceptación que definen cuándo se considera completada.

Bug / Defecto

Problemas encontrados en el producto que necesitan corrección:

Bug: El botón "Añadir al carrito" no responde en Safari iOS Impacto: 15% de usuarios móviles no pueden completar compras Pasos para reproducir: 1. Abrir la página de producto en Safari (iOS 17+) 2. Seleccionar talla y color 3. Pulsar "Añadir al carrito" Resultado esperado: Producto añadido al carrito Resultado actual: No ocurre nada, sin mensaje de error

Tarea técnica (Technical Task)

Trabajo técnico que no aporta valor visible directamente al usuario pero es necesario para la salud del producto:

• Reducir deuda técnica
• Actualizar dependencias de seguridad
• Migrar base de datos
• Mejorar cobertura de tests
• Refactorizar código legacy
• Configurar CI/CD

Spike (Investigación)

Un spike es un PBI cuyo objetivo es investigar y aprender, no entregar funcionalidad:

Spike: Evaluar viabilidad de integración con API de pagos Stripe Timebox: 2 días Resultado esperado: Documento con: - Capacidades y limitaciones de la API - Estimación de esfuerzo para la integración - Riesgos identificados - Recomendación del equipo

Épica (Epic)

Un PBI de gran tamaño que necesita ser descompuesto en PBIs más pequeños antes de poder ser incluido en un Sprint:

Épica: Sistema de notificaciones multicanal ├── PBI: Notificaciones push en móvil ├── PBI: Notificaciones por email ├── PBI: Notificaciones in-app ├── PBI: Centro de preferencias de notificaciones └── PBI: Panel de administración de templates

Mejora (Enhancement)

Optimizaciones o mejoras a funcionalidades existentes:

Mejora: Optimizar tiempo de carga de la página de resultados Situación actual: 4.2 segundos Objetivo: < 2 segundos Enfoque: Lazy loading de imágenes, paginación server-side

Un PBI bien escrito contiene la información necesaria para que el equipo lo entienda, estime y desarrolle:

Campos esenciales

Campos complementarios

• Dependencias: otros PBIs que deben completarse antes o después.
• Mockups/Diseños: referencias visuales del resultado esperado.
• Notas técnicas: consideraciones de implementación identificadas durante el refinamiento.
• Valor de negocio: cuantificación del valor que aporta (puede ser numérico o cualitativo).

Ejemplo completo

TÍTULO: Recuperación de contraseña por email COMO usuario registrado QUIERO recuperar mi contraseña cuando la olvido PARA poder acceder a mi cuenta sin contactar a soporte CRITERIOS DE ACEPTACIÓN: ✅ El usuario puede solicitar un enlace de recuperación introduciendo su email registrado ✅ El email de recuperación se envía en menos de 30 segundos ✅ El enlace expira después de 24 horas ✅ El enlace solo puede usarse una vez ✅ La nueva contraseña debe cumplir las políticas de seguridad (mín. 8 caracteres, mayúscula, número) ✅ Se envía notificación al usuario confirmando el cambio ✅ Si el email no existe, se muestra mensaje genérico (sin revelar si el email está registrado) ESTIMACIÓN: 5 puntos de historia PRIORIDAD: Alta (requisito de seguridad básico) DEPENDENCIAS: Sistema de envío de emails (completado) NOTAS TÉCNICAS: Usar tokens JWT con expiración

Un PBI atraviesa varias etapas desde su creación hasta su entrega:

Creación → Refinamiento → Ready → Sprint Planning → Sprint Backlog → En progreso → Testing → Done

1. Creación

Cualquier persona puede proponer un PBI: el Product Owner, stakeholders, developers o usuarios. El PO decide si lo añade al Product Backlog.

2. Refinamiento

Durante las sesiones de refinamiento (grooming), el equipo:

• Aclara la descripción y los criterios de aceptación.
• Identifica dependencias y riesgos.
• Estima el esfuerzo.
• Descompone PBIs grandes en PBIs más pequeños.

La Guía de Scrum recomienda que el refinamiento no consuma más del 10% del tiempo del Sprint.

3. Ready (Definition of Ready)

Un PBI está "Ready" cuando cumple los criterios acordados por el equipo para ser seleccionado en un Sprint. Criterios típicos:

• Descripción clara y completa.
• Criterios de aceptación definidos.
• Estimado por el equipo.
• Sin dependencias bloqueantes.
• Suficientemente pequeño para completarse en un Sprint.
• Diseños/mockups disponibles (si aplica).

4. Selección en Sprint Planning

El equipo selecciona PBIs del Product Backlog durante el Sprint Planning, moviéndolos al Sprint Backlog. La selección se basa en el Sprint Goal, la prioridad y la capacidad del equipo.

5. Desarrollo y Done

Los Developers trabajan en los PBIs durante el Sprint. Un PBI se considera "Done" cuando cumple la Definition of Done del equipo.

El Product Owner ordena el Product Backlog según el valor que cada PBI aporta. Técnicas comunes:

WSJF (Weighted Shortest Job First)

Usado en SAFe, calcula la prioridad como:

WSJF = Coste del Retraso / Duración del Trabajo Coste del Retraso = Valor de usuario + Urgencia + Reducción de riesgo

MoSCoW

Clasifica los PBIs en:

• Must have: Imprescindibles para el Sprint Goal.
• Should have: Importantes pero no críticos.
• Could have: Deseables si hay capacidad.
• Won't have: Fuera de este Sprint.

Valor vs. Esfuerzo

Matriz 2x2 donde se priorizan primero los PBIs de alto valor y bajo esfuerzo (quick wins).

Los PBIs se gestionan típicamente en herramientas de gestión ágil:

Principio INVEST

Los PBIs de tipo historia de usuario deben cumplir el criterio INVEST:

• Independent: no depende de otros PBIs.
• Negotiable: el cómo es negociable, no el qué.
• Valuable: aporta valor al usuario o al negocio.
• Estimable: el equipo puede estimar su esfuerzo.
• Small: suficientemente pequeño para un Sprint.
• Testable: se puede verificar que cumple los criterios de aceptación.

Tamaño adecuado

Un PBI bien dimensionado debería poder completarse en 2-3 días de trabajo como máximo. Si es más grande:

• Descomponer en PBIs más pequeños.
• Usar vertical slicing para mantener el valor en cada trozo.

Backlog sano

• Los 20-30 PBIs superiores deben estar refinados y listos.
• Los PBIs inferiores pueden ser más vagos (serán refinados cuando se acerquen al top).
• Eliminar regularmente PBIs que ya no son relevantes.
• El backlog no debe crecer indefinidamente.

¿Cuál es la diferencia entre PBI y User Story?

Una User Story es un tipo de PBI, pero no todos los PBIs son User Stories. Un PBI puede ser un bug, una tarea técnica, un spike o una mejora. "PBI" es el término genérico de Scrum para cualquier elemento del Product Backlog.

¿Quién crea los PBIs?

Cualquiera puede proponer PBIs, pero el Product Owner decide qué se incluye en el Product Backlog y cómo se prioriza. Los developers frecuentemente crean PBIs de tipo técnico (deuda técnica, refactoring) y los stakeholders proponen PBIs basados en necesidades de negocio.

¿Cuántos PBIs debería tener un Product Backlog?

No hay un número fijo, pero un backlog saludable típicamente tiene entre 40 y 80 PBIs. Menos de 20 puede indicar falta de visión a medio plazo. Más de 150 sugiere que el backlog necesita limpieza: muchos PBIs antiguos probablemente ya no son relevantes.

¿Se deben estimar todos los PBIs?

Solo los PBIs que estén cerca de ser seleccionados para un Sprint necesitan estimación precisa. Los PBIs en la parte inferior del backlog pueden tener estimaciones de alto nivel (T-shirt sizing) que se refinarán cuando asciendan en prioridad.

¿Cómo manejo PBIs que bloquean otros PBIs?

Las dependencias entre PBIs deben ser visibles. Usa campos de "bloqueado por" en Jira u otras herramientas. El Product Owner debe ordenar el backlog teniendo en cuenta las dependencias para evitar bloqueos durante el Sprint. Si las dependencias son con otros equipos, gestionarlas durante eventos como el PI Planning o Scrum of Scrums.

¿Los PBIs técnicos necesitan aprobación del Product Owner?

Sí. El Product Owner prioriza todo el Product Backlog, incluyendo PBIs técnicos. Sin embargo, el equipo de desarrollo debe educar al PO sobre la importancia de la deuda técnica y su impacto en la velocidad futura. Un buen acuerdo es reservar un porcentaje fijo de la capacidad del Sprint (ej: 20%) para trabajo técnico.

Una historia de usuario es una convención utilizada en el desarrollo de software para capturar una descripción de una funcionalidad de software desde la perspectiva del usuario final.

Están destinadas a ser concisas, enfocándose en los detalles esenciales y evitando la documentación extensa.

Típicamente siguen el formato COMO tipo de usuario, QUIERO algún objetivo PARA alguna razón. Por ejemplo: COMO comprador QUIERO filtrar por precio PARA encontrar productos que encajen con mi presupuesto.

Cada historia de usuario incluye criterios de aceptación específicos que deben cumplirse para que la funcionalidad se considere completa.