Llevas un tiempo trabajando en equipos que dicen practicar Scrum, y algo no termina de cuadrarte. Los sprints avanzan, la demo sale en tiempo, el tablero se vacía cada dos semanas. Y aun así, al cabo de varios meses, el sistema tiene algo raro: funciona por partes, pero no tiene columna vertebral. Cada módulo fue una decisión tomada en el momento, sin conversación con las anteriores. Se ve ágil desde afuera. Se siente frágil desde adentro.

No es que el equipo sea poco disciplinado. Los rituales se hacen, el backlog está priorizado, el Product Owner participa. El problema es más silencioso que eso: nadie definió, antes de arrancar, qué parte del proyecto no puede improvisarse sprint a sprint. Y esa omisión, que parece menor al principio, se cobra con intereses compuestos.

Lo que nadie dice en la retrospectiva

El síntoma más claro aparece cuando alguien intenta cambiar algo que parecía simple. Un ajuste en el modelo de datos toca cuatro historias ya entregadas. Un nuevo servicio necesita un contrato que nadie documentó porque se asumió. Una integración que "ya estaba resuelta" resulta que cada equipo la resolvió a su manera. Cada uno de esos problemas tiene la misma raíz: una decisión estructural que se tomó con la misma liviandad que una tarea de sprint.

La fragilidad no nace de hacer sprints cortos. Nace de confundir dos tipos de decisiones que tienen costos de reversión completamente distintos, y tratarlas como si fueran iguales.

Hay decisiones de implementación —cómo se resuelve una historia de usuario específica, en qué orden se atacan las funcionalidades dentro de una misma capa, qué tan grande es cada tarea— que son baratas de revertir. Si una no funciona, la corriges en el siguiente sprint sin que nada estructural se rompa. Esas son exactamente las decisiones que se benefician de la flexibilidad ágil: se ajustan con la información más fresca posible, sprint a sprint, sin necesidad de comité.

Y hay decisiones estructurales —el modelo de datos central, los contratos entre servicios, los patrones de comunicación del sistema— que son caras de cambiar una vez que varios equipos ya construyeron sobre ellas. Cada sprint que pasa sin que esas decisiones estén tomadas es un sprint que agrega capas sobre cimientos que nadie inspeccionó. El costo de revertirlas no crece linealmente: crece con cada historia que asumió que esa decisión ya estaba resuelta.

El error que produce proyectos frágiles no es aplicar demasiado ágil. Es aplicar la flexibilidad de la capa barata en la capa cara.

La solución incómoda

La respuesta es que esa capa cara necesita el tratamiento opuesto: rigidez deliberada antes de que comience el primer sprint. Se define una vez, con la misma seriedad que un plano estructural, y cambiarla requiere un proceso formal, no una conversación de pasillo. Es, en ese tramo específico, exactamente lo que hace la cascada.

Decirlo así genera resistencia inmediata. "Eso es cascada" es la objeción más rápida, y es comprensible: el malestar con la rigidez de los proyectos tradicionales es real y justificado. Pero la objeción parte de una confusión sobre qué es lo que realmente distingue cascada de ágil, y vale la pena deshacerla antes de continuar.

Lo que define a la cascada no es tener fases, ni tener diseño antes de construcción, ni tener decisiones tomadas de antemano. Lo que la define es que el mapa completo de trabajo —qué se construye, en qué orden, con qué criterios— se cierra una sola vez al principio y no se vuelve a abrir con lo que se aprende en el camino. Un proyecto en cascada puede tener veinte subproyectos y entregas parciales. Sigue siendo cascada porque el subproyecto quince ya estaba escrito en el mes uno, aunque se ejecute en el mes diez, y lo que se aprendió construyendo el subproyecto tres no tuvo ningún efecto sobre él.

Lo que distingue a ágil es una sola cosa: cuando terminas de ejecutar una unidad de trabajo, lo que aprendiste ahí puede reescribir el contenido, el orden o la existencia de la unidad que sigue. Es un bit de información viajando en dirección contraria al plan. Ese bit es lo que mantiene vivo el aprendizaje. Y ese bit puede existir perfectamente en un proyecto que tiene una arquitectura base cerrada, contratos entre servicios definidos antes del primer sprint, y una Definition of Ready rigurosa. Nada de eso impide que lo aprendido en el sprint tres cambie el alcance del sprint seis. Solo impide que lo aprendido en el sprint tres destruya los cimientos sobre los que ya construyó el resto del equipo.

Aplicar rigidez en la capa cara no es cascada. Es reconocer que no todas las decisiones tienen el mismo costo de reversión, y tratarlas en consecuencia.

Dónde vive esa rigidez dentro de Scrum

Lo interesante es que no necesitas inventar nada por fuera del framework. Ágil ya tiene nombre para cada capa de este sistema de gobernanza, y los tres elementos son igual de obligatorios.

El primero es el walking skeleton: antes de que arranque el primer sprint de construcción, el equipo define un esqueleto funcional y liviano que recorre el sistema de punta a punta. No es el diseño completo — es lo mínimo necesario para que todos los equipos construyan sobre la misma base sin pisarse. Incluye las decisiones que son caras de revertir: el modelo de datos central, los contratos entre servicios, los patrones de comunicación, las convenciones técnicas que el resto del proyecto va a asumir como dadas. Quién lo construye es el equipo técnico completo, antes del sprint uno, con la misma formalidad con que un arquitecto firma un plano estructural. Lo que viene después puede crecer y cambiar libremente — precisamente porque ese esqueleto existe.

El segundo y el tercero viven dentro de cada sprint y protegen ese esqueleto historia por historia: la Definition of Ready es la puerta de entrada —ninguna historia entra a un sprint sin demostrar que respeta los contratos que el walking skeleton estableció—, y la Definition of Done es la puerta de salida —ninguna historia se declara terminada sin haber verificado que sigue encajando con el sistema completo, no solo con el módulo recién construido.

Dicho así suena razonable. El problema es que la mayoría de los equipos tratan esa puerta de entrada como un trámite: "la historia tiene criterios de aceptación, ya está lista". Eso responde apenas una parte de la pregunta. Antes de que una historia entre a un sprint, alguien tiene que haber respondido, con la misma seriedad con que un ingeniero civil revisa un plano antes de excavar, qué depende de qué.

No basta con saber que la historia es viable en abstracto. Hay que identificar explícitamente qué habilitadores necesita para poder construirse: un endpoint que todavía no existe, un cambio en el modelo de datos que otra historia debe entregar primero, un permiso o una integración externa que tarda en aprobarse. Y aquí está el punto que casi siempre se salta: no puedes nombrar esas dependencias con honestidad si nadie diseñó, aunque sea a nivel de solución técnica, cómo se va a construir esa historia en concreto.

Decir "esto depende de X" sin haber bajado al menos un boceto de la solución —qué componentes toca, qué contrato de datos necesita, por dónde entra y por dónde sale la información— no es identificar una dependencia, es adivinarla. Y las dependencias adivinadas son exactamente las que aparecen a mitad del sprint disfrazadas de sorpresa.

Lo que una DoR seria realmente exige

Por eso la rigidez concreta no está en agregar más preguntas a un checklist de planning. Está en aceptar que ninguna historia entra a un sprint sin haber pasado antes por un ejercicio de diseño de solución propio, específico para esa actividad. No el diseño de arquitectura completo del sistema —eso vive en el walking skeleton y rara vez se toca. Es un diseño más modesto pero igual de innegociable: la DoR deja de ser una intención difusa en el momento en que se convierte en un entregable verificable con campos obligatorios.

Ninguna historia entra a Sprint Planning sin esos campos completos, y no admite medias respuestas. Como mínimo:

• El diseño de solución específico de esa actividad: qué componentes toca, por dónde entra y sale la información, qué contratos consume o expone.
• La lista explícita de dependencias y habilitadores identificados a partir de ese diseño, no adivinados desde la descripción funcional.
• La estimación de esfuerzo apoyada en esa lista. Construir algo que necesita tres piezas ajenas no cuesta lo mismo que construir algo autocontenido, aunque la descripción funcional suene igual de simple.
• Los criterios de aceptación funcionales: lo que ve el usuario.
• Los criterios no funcionales: rendimiento, seguridad, manejo de errores, mantenibilidad. Una historia puede cumplir su criterio funcional y aun así ser un desastre para el sistema si nadie exigió que respetara los estándares que el resto del proyecto ya adoptó.
• Dos validaciones distintas: la del dueño de producto, que confirma que resuelve el problema del usuario; y la del responsable técnico, que confirma que la solución respeta la arquitectura y los lineamientos que el walking skeleton estableció.

Si a la historia le falta cualquiera de esos ítems, no está lista, sin importar qué tan urgente parezca meterla al sprint. No es un principio abstracto: es un documento con campos obligatorios que nadie puede saltarse por falta de tiempo, exactamente igual que un plano estructural no se salta porque la obra vaya con retraso.

Esa segunda validación —la del responsable técnico— es la que casi nunca se sienta en la conversación. El usuario final valida si la historia resuelve su problema, pero eso es necesario y no suficiente. Falta quien evalúe si el modo en que se va a construir mantiene viva la coherencia del sistema completo. Puedes tener una historia perfectamente aprobada por el producto y absolutamente inaceptable para quien tiene que mantener esa base de código dentro de un año. Si tu Definition of Ready solo mira la primera validación, ya sembraste el mismo desacople que estás intentando evitar.

La Definition of Done cierra el ciclo: exigir pruebas de integración contra el sistema completo —y no solo contra el módulo recién construido— garantiza que lo que se declara terminado realmente encaja con todo lo demás. Ninguna de estas tres piezas rompe el Scrum Guide. Todas simplemente convierten en obligatorio, para ese proyecto específico, algo que el framework siempre dejó como decisión de cultura de equipo —y que la mayoría, por prisa o por comodidad, nunca llegó a decidir en serio.

De vuelta al tablero

Lo que hace funcionar este sistema no es la cantidad de rigor que aplicas, sino dónde lo aplicas. La mayor parte del proyecto —reglas de negocio, funcionalidades, flujos de usuario— se beneficia de decidirse tarde, con la información más fresca posible. Solo una fracción pequeña necesita el tratamiento opuesto: definirse antes, con formalidad, y no tocarse sin proceso. El walking skeleton, la DoR y la DoD son exactamente los tres puntos donde esa fracción vive.

Cuando vuelves al tablero de ese sprint en el que todo se veía bien —los puntos avanzaban, la demo salía en tiempo, nadie levantaba la mano— y lo comparas con el sistema que quedó meses después, frágil, sin columna vertebral, con cada módulo viviendo en su propia realidad, la distancia entre los dos momentos ya tiene explicación. No fueron los rituales, ni la disciplina del equipo, ni el framework. Fue que nadie definió los tres puntos donde el rigor no es opcional: el walking skeleton que estableciera la base común, la DoR que obligara a diseñar antes de construir, y la DoD que verificara que cada pieza encajaba con el resto.

Eso no es traicionar el manifiesto ágil. Es leerlo con más cuidado.

Durante años, las metodologías ágiles —y Scrum en particular— han demostrado ser eficaces para organizar el trabajo y acelerar la entrega de valor. Sin embargo, muchas de sus prácticas nacieron en un contexto tecnológico muy distinto al actual: aplicaciones monolíticas, equipos pequeños y despliegues centralizados. En ese escenario, asumir que una historia de usuario equivalía a una funcionalidad completa y visible para el usuario final era no solo razonable, sino práctico.

Hoy, esa premisa se pone en tensión cuando las organizaciones adoptan arquitecturas de microservicios con frontend desacoplado. La funcionalidad de negocio ya no reside en un único lugar ni se entrega como una sola pieza. Se construye de forma distribuida, a través de múltiples servicios, repositorios y equipos que avanzan a ritmos distintos. Este documento nace precisamente para abordar esa fricción: cómo seguir siendo ágiles sin ignorar la realidad técnica, y cómo reconocer valor allí donde tradicionalmente no se ha sabido mirar.

El objetivo no es redefinir Scrum ni entrar en debates dogmáticos, sino establecer una base clara y compartida que permita gestionar el ciclo de vida del desarrollo de software de forma coherente, predecible y sostenible en entornos distribuidos.

El problema de fondo: cuando una historia ya no contiene toda la funcionalidad

En una aplicación monolítica, la relación entre código, despliegue y experiencia de usuario era directa. Una historia de usuario solía implicar cambios en la interfaz, la lógica de negocio y la base de datos, todo dentro del mismo repositorio y liberado al mismo tiempo. El resultado era una funcionalidad tangible y visible para el usuario final.

Aplicación Monolítica:

┌────────────────────────────────────────┐
│  Una Historia = Una Funcionalidad      │
│  Visible en Pantalla                   │
│                                        │
│  Código UI + Lógica + BD en mismo repo │
│  Desplegado todo junto                 │
└────────────────────────────────────────┘

Al pasar a una arquitectura de microservicios, esta equivalencia se rompe. Una misma funcionalidad de negocio depende ahora de un frontend independiente, varios servicios backend y, en muchos casos, integraciones externas. Cada uno de estos elementos tiene su propio ciclo de desarrollo, su propio backlog y su propia cadencia de despliegue.

Arquitectura Distribuida:

┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│  Frontend   │─────▶│  Backend 1  │─────▶│  Backend 2  │
│  (Repo A)   │      │  (Repo B)   │      │  (Repo C)   │
│  Deploy 1   │      │  Deploy 2   │      │  Deploy 3   │
└─────────────┘      └─────────────┘      └─────────────┘

      ▲                    ▲                    ▲
      │                    │                    │
   3 equipos           3 backlogs         3 velocidades

Insistir en que cada historia de usuario debe representar valor inmediato y visible para el usuario final genera consecuencias previsibles: bloqueos entre equipos, dependencia constante de integraciones y una percepción distorsionada de la velocidad real. El trabajo backend queda “invisible”, la calidad técnica se resiente y la entrega se vuelve errática.

La pregunta incómoda: ¿una API puede tener valor?

Uno de los puntos de fricción más habituales aparece cuando se cuestiona si una API backend, por sí sola, puede considerarse valor. Desde una interpretación estricta de Scrum, la respuesta suele ser negativa: si el usuario final no puede interactuar con ella, no hay valor entregado.

El problema de esta visión es que ignora cómo se construyen realmente los sistemas complejos. En un entorno distribuido, el valor no aparece de golpe al final del proceso, sino que se va materializando en forma de activos técnicos que reducen incertidumbre, habilitan trabajo paralelo y evitan retrabajo futuro.

De este modo, es necesario distinguir entre dos tipos de valor que coexisten en el flujo de entrega. Por un lado, el valor de negocio directo, que se manifiesta cuando una funcionalidad completa está integrada de extremo a extremo y disponible para el usuario final. Por otro, el valor de activo técnico, que se entrega cuando un componente queda listo, probado y certificado para ser usado por otros equipos.

Timeline de Entrega de Valor:

Día 1-3: Habilitadores completos
         └─ Valor: equipos desbloqueados

Día 4-6: HU Backend completa
         └─ Valor de ACTIVO: API certificada

Día 5-7: HU Frontend completa
         └─ Valor de ACTIVO: UI certificada

Día 8-9: Integración E2E en QA
         └─ Valor de NEGOCIO

Día 10: Producción
         └─ Valor capturado por usuarios

Reconocer este segundo tipo de valor no implica bajar el estándar, sino hacerlo explícito. Una API bien diseñada y validada antes de la integración final reduce riesgos, acelera la entrega y mejora la calidad global del sistema.

Una analogía necesaria para entender el enfoque

La lógica detrás de este modelo resulta más evidente cuando se traslada al mundo físico. En una fábrica de automóviles, el motor, la transmisión y el chasis se construyen por separado. Cada uno de estos componentes tiene valor una vez que ha sido fabricado y probado, incluso aunque el coche completo todavía no exista.

Nadie consideraría desperdicio construir un motor certificado solo porque el vehículo aún no puede circular. De la misma manera, una API backend validada y desplegada en un entorno de pruebas tiene valor real, aunque el usuario final todavía no la vea. Ese valor reside en su capacidad de integrarse sin sorpresas y de servir como base sólida para el resto del sistema.

Cómo se traduce este modelo al desarrollo con microservicios

Cuando este razonamiento se aplica al desarrollo de software, la estructura se vuelve más clara. Una feature representa el objetivo de negocio final, pero su construcción requiere distintos niveles de trabajo que no pueden mezclarse sin generar confusión.

Primero aparecen los habilitadores, como la definición del contrato de la API o la configuración de la infraestructura. Estos elementos no tienen narrativa de usuario final, pero son imprescindibles para que el desarrollo avance sin bloqueos. A continuación, las historias de usuario de backend y frontend entregan componentes certificados de forma independiente. Solo cuando estos componentes se integran se materializa el valor de negocio directo.

FEATURE: "Transferir dinero entre cuentas"

Habilitador:
- Contrato OpenAPI definido y validado

HU Backend:
- API desplegada en QA
- Tests de contrato pasando
- Lista para consumo inmediato

HU Frontend:
- UI validada contra stubs
- Flujos de error implementados

Feature Completa:
- Integración E2E certificada
- Funcionalidad disponible en producción

Este enfoque no fragmenta la entrega; la hace explícita. Cada equipo sabe qué está entregando, para quién y con qué criterio de calidad.

Por qué esto no es waterfall encubierto

Una crítica frecuente es que esta separación recuerda a un modelo en cascada. La diferencia fundamental es que aquí no existen fases bloqueantes. Frontend y backend trabajan en paralelo, desacoplados mediante contratos y stubs, obteniendo feedback temprano y continuo.

En un modelo waterfall, los equipos esperan a que otros terminen para empezar. En este enfoque, los componentes se certifican de forma independiente y la integración se convierte en un paso predecible, no en un cuello de botella tardío.

Un concepto de usuario más amplio

Otro cambio clave es la evolución del concepto de “usuario”. En arquitecturas modernas, no solo las personas consumen funcionalidades. También lo hacen otros sistemas y los desarrolladores que integran servicios.

Una pasarela de pagos como Stripe lo ilustra con claridad: tiene compradores finales, aplicaciones que consumen la API y desarrolladores que necesitan documentación clara para integrar el servicio. Cada uno de ellos recibe valor distinto, y todos son usuarios legítimos. Ignorar alguno de estos niveles degrada el producto y ralentiza su adopción.

Cuando el dogma supera a la realidad

La experiencia demuestra que aplicar Scrum de forma rígida en sistemas distribuidos suele generar efectos contraproducentes. Organizaciones que solo reconocen valor cuando el cliente final ve algo en pantalla tienden a invisibilizar el trabajo técnico, acumular deuda y sufrir bloqueos constantes.

En contraste, aquellas que distinguen claramente entre valor de activo y valor de negocio logran reducir defectos, mejorar la previsibilidad y aumentar la motivación de los equipos. Reconocer el valor técnico no es una concesión, sino una condición necesaria para la sostenibilidad.

Niveles de trabajo como marco común

Para evitar ambigüedades, este enfoque distingue cuatro niveles de trabajo: Feature, Habilitador, Historia de Usuario y Tarea. Cada uno cumple una función específica y tiene criterios de finalización distintos, lo que permite planificar y medir el progreso sin mezclar expectativas.

Relación jerárquica:

1 Feature
 ├─ Habilitadores
 ├─ Historias de Usuario (Frontend / Backend)
 │   └─ Tareas técnicas

Esta jerarquía no añade burocracia; añade claridad. Permite que cada equipo sepa cuándo su trabajo está realmente terminado y cómo contribuye al objetivo global.

Conclusión

La adopción de arquitecturas de microservicios exige una reinterpretación pragmática de los principios ágiles. El valor ya no aparece en un único momento ni en una sola capa del sistema. Se construye progresivamente, a través de activos técnicos certificados que habilitan la entrega final de valor de negocio.

Este documento establece una base para trabajar con esa realidad, permitiendo desacoplar equipos, visibilizar el trabajo técnico y mejorar la calidad global del sistema. A partir de aquí, el marco puede evolucionar hacia métricas más avanzadas, automatización de certificaciones y una gestión aún más madura de dependencias e integraciones.