Simyl
simylflow
Inicio del curso
Módulo 2: Nivel de Equipo
Lección 3 de 3
17 min

Backlog y Historias del Equipo

Cómo fluye el trabajo desde las funcionalidades hasta las historias, y cómo los equipos gestionan sus backlogs dentro del contexto del ART.

1De Funcionalidades a Historias

En SAFe, el trabajo fluye a través de una jerarquía:

ÉpicaFuncionalidadHistoria

  • Las Épicas son iniciativas grandes que abarcan múltiples PIs. Viven en el Kanban de Portafolio y requieren Casos de Negocio Lean.
  • Las Funcionalidades son incrementos de funcionalidad que entregan valor al usuario. Viven en el Backlog del Programa y están dimensionadas para caber dentro de un solo PI. La Gestión de Producto es dueña de la prioridad de las funcionalidades.
  • Las Historias son piezas de trabajo pequeñas e implementables que un equipo puede completar dentro de una iteración. Viven en el Backlog del Equipo. El Product Owner es dueño de la prioridad de las historias.

El flujo de descomposición: la Gestión de Producto divide las épicas en funcionalidades durante la Planificación del PI. Los Product Owners dividen las funcionalidades en historias durante la planificación de la iteración (y las sesiones de refinamiento).

Las buenas historias siguen los criterios INVEST:

  • Independiente — Puede desarrollarse sin depender de otras historias
  • Negociable — Los detalles se discuten, no se dictan
  • Valiosa — Entrega valor claro al usuario o sistema
  • Estimable — El equipo puede estimar el esfuerzo
  • Pequeña — Cabe dentro de una sola iteración
  • Comprobable — Criterios de aceptación claros

2Habilitadores

No todo el trabajo entrega valor directo al usuario. Los Habilitadores son historias (o funcionalidades, o épicas) que construyen la base técnica para capacidades futuras.

SAFe define cuatro tipos de habilitadores:

Habilitadores de arquitectura: Construyen pista de aterrizaje arquitectónica—servicios compartidos, APIs, infraestructura que las funcionalidades futuras necesitarán. Ejemplo: configurar un sistema de cola de mensajes antes de construir funcionalidades basadas en eventos.

Habilitadores de infraestructura: Configuran la infraestructura de desarrollo, pruebas y despliegue. Ejemplo: crear un pipeline de CI/CD, configurar monitoreo, aprovisionar ambientes.

Habilitadores de exploración: Investigan opciones y reducen la incertidumbre. Ejemplo: prototipar dos enfoques diferentes para ver cuál funciona mejor, historias spike.

Habilitadores de cumplimiento: Satisfacen requisitos regulatorios o de políticas. Ejemplo: implementar registro de auditoría, cifrado de datos o estándares de accesibilidad.

Gestión de habilitadores en el backlog:

Los habilitadores compiten por capacidad con las historias de funcionalidades. Un equipo saludable gasta aproximadamente:

  • 70-80% en historias de funcionalidades (entrega de valor directo)
  • 20-30% en habilitadores (pista de aterrizaje arquitectónica, deuda técnica, infraestructura)

Esta proporción no es rígida—depende de la madurez del sistema. Los productos nuevos necesitan más trabajo de habilitadores; los productos maduros pueden inclinarse hacia las funcionalidades. La clave es hacer visible el trabajo de habilitadores en lugar de ocultarlo.

Haz Visibles los Habilitadores

Nunca ocultes el trabajo de habilitadores dentro de historias de funcionalidades. Cuando la inversión técnica es invisible, es lo primero que se recorta bajo presión. Las historias de habilitadores separadas fuerzan conversaciones explícitas sobre el equilibrio entre el ahora y el después.

3Planificación de Capacidad y Compromiso

Durante la planificación de la iteración, los equipos determinan cuánto trabajo pueden comprometerse a realizar:

Capacidad = miembros del equipo disponibles × horas por día × días en la iteración, menos reuniones e interrupciones conocidas. Los equipos aprenden su capacidad real a través de la experiencia—es una medida empírica, no un cálculo.

Los puntos de historia estiman la complejidad relativa. Los equipos se calibran con el tiempo. La métrica clave es la velocidad—el promedio de puntos de historia completados por iteración. La velocidad se estabiliza después de 3-4 iteraciones y se convierte en una herramienta de planificación confiable.

Compromiso en el contexto de SAFe:

Los compromisos del equipo en una iteración se alinean con los Objetivos del PI establecidos durante la Planificación del PI. El objetivo de la iteración debe mapear al progreso en uno o más objetivos del PI. Esto crea alineación rastreable desde el trabajo del equipo hasta el valor del programa.

Cuando los equipos descubren a mitad de la iteración que no pueden cumplir un compromiso:

  1. Comunicar inmediatamente (transparencia)
  2. Trabajar con el PO para ajustar el alcance (negociación)
  3. Escalar al RTE si afecta a otros equipos (coordinación)
  4. Nunca sacrificar la calidad para cumplir una fecha (calidad integrada)

La medida de predictibilidad: SAFe rastrea qué tan bien los equipos entregan sus objetivos del PI. Esto no se trata de castigar los fallos—se trata de mejorar la precisión de la estimación y planificación con el tiempo. Un equipo que entrega confiablemente el 80% de los objetivos es más valioso que uno que promete el 100% y entrega de manera impredecible.

Conclusiones clave
  • El trabajo fluye desde Épicas → Funcionalidades → Historias, con cada nivel siendo propiedad de diferentes roles
  • Los Habilitadores (arquitectura, infraestructura, exploración, cumplimiento) construyen pista de aterrizaje técnica
  • Los equipos saludables asignan 20-30% de capacidad al trabajo de habilitadores
  • La predictibilidad importa más que el sobrecompromiso heroico