Antes de tu primer trabajo como programador, es muy probable que "Scrum" sea solo una palabra que aparece en las ofertas de empleo junto a "metodologías ágiles". El primer día en un equipo real, en cambio, se convierte en el marco que organiza literalmente todas tus semanas: qué haces cada día, cuándo entregas, con quién hablas y cómo se decide qué se construye primero.

Detrás del nombre no hay ni una tecnología ni un lenguaje que aprender: Scrum es un marco de trabajo para organizar equipos que construyen software (o cualquier producto) de forma incremental, entregando algo funcional cada pocas semanas en vez de todo de golpe al final de un proyecto largo.

Qué problema resuelve Scrum

Antes de que se popularizaran las metodologías ágiles, era habitual planificar un proyecto entero al inicio (metodología "en cascada" o waterfall) y no entregar nada hasta que estuviera completamente terminado, meses o años después. El problema es evidente: si los requisitos cambian por el camino —y casi siempre cambian—, todo el trabajo hecho sobre suposiciones antiguas se desperdicia. Scrum plantea lo contrario: dividir el trabajo en ciclos cortos, entregar algo funcional al final de cada ciclo, y ajustar la dirección constantemente según lo que se va aprendiendo.

Los tres roles de un equipo Scrum

Un equipo Scrum bien formado tiene tres roles claramente diferenciados, y confundirlos es una de las causas más comunes de que un equipo diga que "hace Scrum" pero en realidad no funcione de forma ágil:

Si vienes de un Grado Superior en DAM o de un bootcamp, es probable que tu primera experiencia real con estos roles llegue en tus primeras semanas de trabajo, no durante la formación. No pasa nada por no tenerlo interiorizado de antemano: se aprende rápido trabajando dentro de un equipo que ya tiene el proceso rodado.

El sprint: el corazón de Scrum

Un sprint es un periodo de tiempo fijo, normalmente entre una y cuatro semanas (dos es lo más habitual), durante el cual el equipo se compromete a completar un conjunto concreto de tareas extraídas del backlog del producto. Al final del sprint debería existir un incremento funcional del producto, aunque sea pequeño. La duración del sprint no cambia de un ciclo a otro: esa regularidad es justo lo que permite medir y mejorar el ritmo del equipo con el tiempo, algo que se conoce como velocidad.

python
sprints = [
    {"nombre": "Sprint 12", "puntos_completados": 34},
    {"nombre": "Sprint 13", "puntos_completados": 29},
    {"nombre": "Sprint 14", "puntos_completados": 38},
]

velocidad_media = sum(s["puntos_completados"] for s in sprints) / len(sprints)
print(f"Velocidad media del equipo: {velocidad_media:.1f} puntos por sprint")

Esa velocidad media no sirve para comparar equipos entre sí (cada equipo estima con su propia escala), pero sí es muy útil para que un equipo concreto planifique con realismo cuántas tareas puede comprometerse a terminar en el siguiente sprint.

Roles y ceremonias, explicados uno a uno

Además de los roles, Scrum define un puñado de reuniones (llamadas "eventos" o "ceremonias") con un propósito muy concreto cada una. Despliega cada bloque para ver el detalle:

Es responsable de maximizar el valor del producto. Gestiona y prioriza el product backlog (la lista de todo lo que se podría construir), y es la persona a la que el equipo pregunta cuando hay dudas sobre qué se espera de una funcionalidad. No es un rol técnico, aunque en equipos pequeños a veces lo asume alguien con perfil técnico.

Facilita que el equipo siga el marco Scrum correctamente y elimina impedimentos: si alguien está bloqueado esperando acceso a un servidor o una respuesta de otro departamento, el Scrum Master se encarga de desatascarlo. No es el jefe del equipo ni reparte tareas.

Reunión al inicio de cada sprint donde el equipo, junto al Product Owner, decide qué elementos del backlog se van a abordar en el sprint que empieza, y los descompone en tareas más pequeñas y manejables.

Reunión corta (10-15 minutos), normalmente de pie y siempre a la misma hora, donde cada miembro del equipo responde brevemente a: qué hice ayer, qué voy a hacer hoy, y si tengo algún bloqueo. No es una reunión de reporte al jefe, es sincronización entre compañeros.

Al final del sprint hay dos reuniones distintas: la review, donde se muestra el incremento completado a las partes interesadas y se recoge feedback; y la retrospectiva, donde el equipo (sin gente externa) habla de qué funcionó bien, qué no, y qué va a cambiar en el próximo sprint para mejorar como equipo.

Artefactos: dónde vive el trabajo

Scrum define también tres artefactos que dan visibilidad al trabajo: el product backlog (todo lo que podría construirse, ordenado por prioridad), el sprint backlog (lo que el equipo se comprometió a hacer en el sprint actual) y el incremento (la suma de todo lo completado hasta ahora, siempre en estado funcional). Herramientas como Jira o Trello son solo la representación visual de estos tres conceptos, no son Scrum en sí mismas.

Scrum no es solo teoría de gestión

Entender Scrum tiene un efecto práctico directo en tu día a día como programador: te ayuda a estimar mejor cuánto tiempo te va a llevar una tarea, a comunicar bloqueos pronto en vez de callártelos hasta el final del sprint, y a distinguir entre "terminado" (código escrito) y "hecho" (código escrito, probado y desplegable). Esa distinción, de hecho, es uno de los rasgos que diferencia claramente a un perfil junior de uno senior: quien lleva más tiempo trabajando en equipos ágiles rara vez dice que algo está "hecho" si no tiene pruebas ni ha pasado revisión de código.

Si te preguntan por Scrum en una entrevista de trabajo, no hace falta recitar la teoría de memoria: basta con explicar con tus propias palabras para qué sirve cada rol y cada ceremonia, algo que también conviene tener preparado junto al resto de preguntas habituales de una entrevista técnica.

JR

Javier Rodríguez Fernández

Programador con Grado Superior en Desarrollo de Aplicaciones Multiplataforma (DAM). Escribe en DevPulso sobre programación aplicada, sin relleno.