El framework Scrum: responsabilidades, eventos y artefactos

Scrum es el framework ágil más utilizado y también el peor descrito. El documento que lo define tiene unas trece páginas, se revisó por última vez en noviembre de 2020 y es incompleto a propósito: te dice qué eventos celebrar, quién es responsable de qué y qué hay que inspeccionar, y ahí se detiene. Todo lo demás (cómo estimas, cómo gestionas las ramas, si trabajas en pareja, qué aspecto tiene tu tablero) se deja al equipo de forma deliberada.

Ese minimalismo es a la vez la fuente de su utilidad y de sus problemas. Como el framework es pequeño, encaja en casi cualquier organización; como es pequeño, las organizaciones rellenan los huecos con lo que ya hacían antes y acaban con reuniones semanales de seguimiento llamadas stand-ups y un plan de proyecto llamado backlog. Esta guía describe lo que el framework especifica de verdad y después recorre un sprint de principio a fin. Las guías sobre el Scrum Master y el product owner profundizan en esas dos responsabilidades, y la de principios ágiles cubre los valores que Scrum pone en práctica.

El empirismo y los tres pilares

Scrum se define como un framework basado en el empirismo y el pensamiento lean. Empirismo significa tomar decisiones a partir de lo que se observa y no de lo que se suponía, y se apoya en tres pilares a cuyo servicio existen los eventos.

Transparencia. El estado del trabajo es visible y se representa con honestidad para todos los que lo necesitan. Un tablero que muestra seis elementos en curso cuando en realidad se está trabajando en nueve rompe la transparencia, y cualquier inspección que se base en él llega a la conclusión equivocada.

Inspección. El progreso y los artefactos se examinan con la frecuencia suficiente para detectar los problemas mientras todavía son baratos. Cada uno de los cinco eventos es un punto de inspección con un objeto definido.

Adaptación. Cuando la inspección revela una desviación, algo cambia: el plan, el producto, el proceso. Inspeccionar sin autoridad para adaptarse es puro teatro.

Tres responsabilidades

La revisión de 2020 eliminó el término «equipo de desarrollo» como subgrupo y lo sustituyó por un único Scrum Team, normalmente de diez personas o menos, que asume tres responsabilidades. Son responsabilidades, no puestos de trabajo; una persona puede asumir una mientras hace otras tareas.

Product owner. Responsable de maximizar el valor del producto que resulta del trabajo del equipo. Eso implica ser dueño del objetivo del producto, ordenar el product backlog y hacer transparentes su contenido y sus prioridades. Lo fundamental es que el product owner es una persona, no un comité, y que la organización debe respetar sus decisiones para que esta responsabilidad signifique algo.

Scrum Master. Responsable de la efectividad del equipo y de que Scrum se entienda y se aplique, tanto dentro del equipo como en el resto de la organización. Es un rol de liderazgo que sirve al equipo en lugar de dirigirlo, y que se extiende hacia fuera: acompañar a los stakeholders, eliminar impedimentos organizativos y ayudar al product owner con técnicas de gestión del backlog.

Developers. Todas las personas que realizan el trabajo de crear un incremento utilizable, sea cual sea su especialidad: programación, pruebas, diseño, análisis, operaciones. Son responsables de elaborar el plan del sprint, de asegurar la calidad cumpliendo la definición de terminado, de adaptar su plan cada día y de exigirse cuentas unos a otros como profesionales. El equipo es multifuncional: tiene todas las habilidades necesarias para pasar de un elemento del backlog a un incremento sin depender de personas externas.

Tres artefactos y sus compromisos

La revisión de 2020 asoció un compromiso a cada artefacto, para que cada uno tenga una referencia con la que medirse en lugar de ser una lista abierta sin fin.

El objetivo del producto da una dirección al backlog, de modo que las decisiones de orden se puedan discutir frente a algo concreto. El objetivo del sprint es la razón por la que merece la pena hacer el sprint; se elige en la planificación y da coherencia a elementos que, de otro modo, serían tickets sin relación entre sí. La definición de terminado es el listón de calidad: el trabajo que no la cumple no forma parte del incremento, no se puede publicar y no se puede presentar como completo.

Una definición de terminado solo sirve si es honesta y se hace cumplir. Una realista para un servicio web podría exigir que el código esté revisado y fusionado en la rama principal, que las pruebas unitarias y de integración pasen en el pipeline, que la funcionalidad esté detrás de un feature flag o desplegada en staging, que haya monitorización y logs para el nuevo flujo, que la documentación esté actualizada y que no quede abierto ningún defecto conocido de severidad media o superior. Si «probado» aparece en la lista pero las pruebas se hacen en realidad dos sprints después, la definición es ficción y cada incremento está inflado. La guía de fundamentos de testing explica qué contiene un listón de calidad defendible.

Cinco eventos

El sprint es el contenedor; los otros cuatro eventos ocurren dentro de él. Todos tienen un time-box, todos son puntos de inspección y ninguno es un informe de estado para la dirección.

Los time-boxes se reducen con la duración del sprint: un sprint de dos semanas tiene hasta cuatro horas de planificación, dos horas de review y noventa minutos de retrospectiva. Son máximos, no objetivos.

La sprint planning responde a tres preguntas. ¿Por qué este sprint aporta valor? El product owner hace una propuesta y el equipo formula el objetivo del sprint. ¿Qué se puede hacer? Los developers seleccionan los elementos que creen poder terminar según la definición de terminado. ¿Cómo se va a hacer? Con la descomposición suficiente para que el equipo se sienta seguro, normalmente en un plan de elementos de trabajo, aunque la guía no impone el formato.

La Daily Scrum es una sesión de trabajo de quince minutos en la que los developers inspeccionan el progreso hacia el objetivo del sprint y ajustan el plan del día. La guía de 2020 eliminó deliberadamente las tres preguntas predefinidas porque habían convertido el evento en una ronda de informes de estado individuales. Si al terminar nadie cambia su plan, el evento no está cumpliendo su función.

La sprint review es una sesión de trabajo con los stakeholders en la que se muestra el incremento y el grupo conversa sobre qué hacer a continuación a la luz de lo que ahora sabe. Es una conversación sobre el producto, no un trámite de aprobación, y su resultado alimenta directamente el orden del backlog.

La sprint retrospective cierra el sprint examinando cómo ha ido el trabajo (procesos, herramientas, interacciones, definición de terminado) e identificando mejoras. El resultado es un número reducido de cambios concretos, idealmente uno que el equipo se compromete a probar en el siguiente sprint. Las retrospectivas que generan una larga lista de quejas y ningún cambio son la causa más habitual de que un equipo abandone el evento sin hacer ruido.

Un sprint de principio a fin

Pensemos en un sprint de dos semanas de un equipo que construye un panel de pagos.

El primer día el equipo dedica tres horas a la planificación. El product owner explica que el siguiente paso más valioso es que los usuarios de finanzas puedan ver las discrepancias de liquidación sin exportar a una hoja de cálculo, y el equipo formula el objetivo del sprint: los usuarios de finanzas pueden identificar y explicar una discrepancia de liquidación dentro del panel. Seleccionan cinco elementos del backlog que sirven a ese objetivo y dejan fuera un sexto, una exportación de informes: tiene valor, pero no guarda relación con el objetivo, e incluirlo lo diluiría.

Cada mañana los developers se reúnen quince minutos delante del tablero. El cuarto día descubren que el feed de liquidaciones omite el código de divisa, lo que hace imposible uno de los elementos tal como está redactado. En lugar de escalarlo, lo renegocian ese mismo día con el product owner: el elemento se limita a cuentas de una sola divisa, lo que sigue sirviendo al objetivo. El sprint backlog cambia; el objetivo del sprint, no.

El noveno día llega un defecto urgente de producción. El equipo lo corrige y saca del sprint el elemento de menor valor para hacerle hueco. En la review del décimo día muestran la vista de discrepancias funcionando a dos usuarios de finanzas, que enseguida piden filtrar por contraparte: una petición que se convierte en un nuevo elemento del backlog en lugar de un cambio sobre el trabajo terminado. La retrospectiva de esa tarde saca a la luz que el código de divisa ausente costó un día y medio, y el equipo acuerda un cambio: las sesiones de refinamiento incluirán una comprobación de cinco minutos del contrato de datos real del sistema de origen antes de dar un elemento por listo.

Lo que Scrum no dice a propósito

Scrum es un framework, no un método, y sus omisiones son intencionadas. No dice nada sobre cómo estimar, si usar story points, cuánto debe durar el refinamiento, cómo gestionar ramas y merges, qué aspecto tiene un tablero, cómo tratar los bugs, cuántos equipos pueden compartir un producto ni sobre ninguna práctica técnica. Eso lo tienen que aportar los equipos, y esas decisiones importan más que el propio framework: un equipo que sigue todas las reglas de la guía sin pruebas automatizadas y con un ciclo de publicación de dos meses no entregará un incremento utilizable en cada sprint, por muy bien que lleve sus eventos. Un pipeline de entrega es el requisito práctico para que el incremento sea realmente publicable.

El framework, además, se declara explícitamente innegociable como un todo: la guía afirma que cada elemento de Scrum cumple una función y que quitar partes manteniendo el nombre produce algo que oculta los problemas en lugar de sacarlos a la luz. En la práctica, la mayoría de las organizaciones sí quitan partes, y no pasa nada mientras todo el mundo reconozca con honestidad que lo que resulta es un proceso propio y no Scrum.

Conclusiones clave

• La Guía de Scrum actual es de noviembre de 2020 y define un único equipo con tres responsabilidades, cinco eventos, tres artefactos y tres compromisos; nada más.
• Cada artefacto tiene un compromiso: el objetivo del producto para el product backlog, el objetivo del sprint para el sprint backlog y la definición de terminado para el incremento.
• El sprint es un contenedor; los otros cuatro eventos son puntos de inspección con un objeto definido y time-boxes que se ajustan a la duración del sprint.
• El sprint backlog puede cambiar cada día, pero el objetivo del sprint se mantiene fijo durante todo el sprint; solo el product owner puede cancelar un sprint.
• Una definición de terminado que no se hace cumplir convierte cada incremento en una exageración, y ninguna disciplina de proceso lo compensa.
• Scrum omite a propósito la estimación, las prácticas de ingeniería y las herramientas; son esas decisiones las que determinan si el framework produce algo útil.