Las releases no están ligadas a Scrum

En desarrollo de software es habitual asumir que las releases forman parte natural del proceso de Scrum; que ocurren al final de un sprint, que agrupan todas las historias planificadas o que representan el último estado del flujo de trabajo. Sin embargo, esta asociación es más cultural que real. Aunque lo parezca, las releases no dependen de Scrum, ni del estado de tus historias, ni de lo que hayas decidido planificar en un sprint.

Una release es, ante todo, una decisión de entrega. Es el momento en el que decides poner una versión concreta de tu software en manos de usuarios o en producción. Scrum, en cambio, es un framework de gestión del trabajo. Te ayuda a estructurar cómo desarrollas el producto, a inspeccionar el progreso y a mejorar continuamente, pero scrum no define cuándo ni cómo debes entregar software.

Cuando trabajas con Scrum, cada sprint produce un incremento potencialmente liberable. Esa expresión es clave. Potencialmente significa que puede liberarse, no que deba liberarse. Que una funcionalidad esté terminada desde el punto de vista del equipo no implica que tenga que formar parte de una release inmediata, ni siquiera de la siguiente. Puedes tener software terminado que no se libera, o que se libera junto con otros cambios desarrollados en momentos completamente distintos.

El flujo de estados de las historias de usuario tampoco define las releases. Ese flujo existe para darte visibilidad y control del trabajo, no para gobernar la entrega. Una historia puede llegar a Done y quedarse ahí. Otra puede liberarse sin que el resto del sprint esté completo. Incluso puedes liberar cambios que no están asociados a una historia visible para negocio, como refactors, mejoras técnicas o correcciones internas. El tablero describe el trabajo; no decide la publicación.

Tampoco existe una obligación de sincronizar las releases con el cierre del sprint. Aunque muchas organizaciones lo hacen por comodidad o tradición, no hay nada en Scrum que lo exija. Puedes liberar a mitad del sprint, varias veces dentro del mismo sprint o después de varios sprints sin liberar nada. El sprint marca el ritmo de trabajo; la release responde a necesidades de negocio, riesgo o contexto operativo. Son relojes distintos y forzarlos a coincidir suele generar fricción innecesaria.

Esta separación se entiende con especial claridad cuando trabajas con entrega continua (Continuous Delivery). En este modelo, cada cambio que supera el pipeline de CI/CD queda listo para ser liberado. Si completas una historia el tercer día del sprint y pasa todas las pruebas automatizadas, puedes ponerla en producción inmediatamente, sin esperar al Sprint Review ni al cierre del sprint. El sprint continúa, el equipo sigue trabajando y la release ocurre cuando aporta valor, no cuando lo dicta el calendario.

En el desarrollo de backend esta independencia es todavía más evidente. Es habitual hacer múltiples releases al día, desplegar cambios invisibles para el usuario final o liberar funcionalidades protegidas por feature flags. Se utilizan técnicas como compatibilidad hacia atrás, despliegues progresivos o rollbacks rápidos. Nada de esto necesita alinearse con un sprint ni con el estado global del tablero.

Scrum sí juega un papel importante, pero no como mecanismo de entrega. Te ayuda a producir software de calidad, a mantener un ritmo sostenible y a tener claridad sobre qué está realmente terminado. Eso facilita decidir cuándo liberar, pero no te obliga a hacerlo de una forma concreta.

Entender esta diferencia te permite dejar de forzar releases artificiales, evitar acoplamientos innecesarios y asumir una idea fundamental: liberar software es una decisión consciente e independiente. Scrum te ayuda a construirlo bien; la release decide cuándo ese valor llega al mundo real.