Framework Scrum: Roles, Eventos y Artefactos Explicados (Con Ejemplos)

La mayoría de las personas aprende Scrum de forma incorrecta. Lo tratan como una lista de reuniones que programar y roles que asignar, ejecutan algunos sprints y luego se preguntan por qué el equipo sigue entregando con lentitud y el Product Backlog nunca mengua. El framework Scrum no es una metodología que se implementa una vez y se olvida. Es un ciclo de retroalimentación que se adapta en cada sprint, y esa distinción tiene una importancia enorme.

Scrum es ligero por diseño. Ofrece justo la estructura suficiente para hacer visibles los problemas rápidamente y resolverlos antes de que se multipliquen. Los equipos que obtienen un valor real de Scrum son los que se toman en serio el principio de inspección y adaptación, no los que simplemente cambian el nombre de sus reuniones a "Daily Scrum."

¿Qué es el framework Scrum?

Scrum es un framework Agile ligero para entregar productos complejos a través de iteraciones cortas con tiempo acotado llamadas Sprints. No prescribe prácticas de ingeniería ni herramientas específicas. En cambio, define un conjunto mínimo de roles, eventos y artefactos diseñados para crear transparencia, habilitar la inspección frecuente y hacer que la adaptación sea ágil.

Jeff Sutherland y Ken Schwaber desarrollaron Scrum a principios de la década de 1990, tomando conceptos de la manufactura Lean y el control de procesos empírico. Lo presentaron públicamente por primera vez en la conferencia OOPSLA de 1995. La primera Scrum Guide formal se publicó en 2010. La versión más reciente, la Scrum Guide 2020, redujo aún más el framework, eliminando elementos prescriptivos y afinando el enfoque en los tres pilares del empirismo: transparencia, inspección y adaptación.

El pensamiento Lean recorre todo el framework. Los equipos Scrum eliminan el desperdicio trabajando en ciclos cortos, obteniendo retroalimentación real sobre software funcional y deteniendo el trabajo que no avanza el producto hacia su objetivo.

Datos clave

• Sutherland y Schwaber presentaron Scrum públicamente por primera vez en la conferencia OOPSLA en 1995, introduciendo el concepto de iteraciones con tiempo acotado y roles definidos.
• La Scrum Guide 2020 (disponible en scrumguides.org) es la fuente canónica. Eliminó el término "Development Team" y simplificó el framework de forma significativa respecto a versiones anteriores.
• Según el 17.° Informe sobre el Estado de Agile (Digital.ai, 2023), Scrum sigue siendo el enfoque Agile más utilizado, con el 87% de los equipos ágiles usando Scrum o un híbrido de Scrum.

El ciclo Scrum visualizado

El ciclo Scrum es un bucle empírico. Comienza con el Product Backlog, una lista ordenada de todo aquello en lo que el equipo podría trabajar. Cada ciclo empieza con la planificación del Sprint, en la que el equipo selecciona elementos del Product Backlog y crea el Sprint Backlog: el trabajo específico que completarán durante el próximo Sprint.

El Sprint tiene una duración de una a cuatro semanas. Durante él, el equipo celebra un Daily Scrum cada día: una reunión de coordinación de 15 minutos en la que los Developers inspeccionan el progreso y replanifican su trabajo para las próximas 24 horas.

Al final del Sprint, el equipo entrega un Increment funcional, algo que cumple con la Definition of Done y que, en principio, podría lanzarse al mercado. La revisión del Sprint es una sesión informal en la que el equipo y las partes interesadas inspeccionan el Increment y debaten los próximos pasos. Después llega la retrospectiva del Sprint, donde el equipo se examina a sí mismo: cómo trabajó, qué mejorar y qué llevar al próximo sprint.

Y luego se repite. Product Backlog -> planificación del Sprint -> Sprint -> Increment -> revisión -> retro -> Product Backlog. El bucle es el framework. Es corto para que los errores sean baratos y el aprendizaje sea rápido.

Los 3 roles de Scrum (el Scrum Team)

La Scrum Guide 2020 eliminó el concepto de subequipos. Existe un único Scrum Team, sin jerarquía, y tres responsabilidades dentro de él.

Product Owner

El Product Owner es responsable de maximizar el valor del producto. Es el dueño del Product Backlog: lo crea, lo ordena y se asegura de que los Developers comprendan su contenido. Una restricción crítica de la Scrum Guide: el Product Owner es una sola persona, no un comité. Las decisiones sobre qué se construye deben provenir de una única voz.

En la práctica, el Product Owner trabaja en la intersección entre la estrategia de negocio y el trabajo de desarrollo. Toma decisiones constantemente: qué funcionalidad vale la pena construir primero, qué necesidad del usuario priorizar, qué elemento del Backlog recortar. Un Product Owner débil que no puede tomar esas decisiones con rapidez crea un cuello de botella que todo el Scrum Team sentirá en cada sprint.

El Product Owner no es un intermediario. Cuando las partes interesadas quieren algo, trabajan a través del Product Owner, no alrededor de él. Si la organización no respeta ese límite, Scrum no funcionará bien.

Scrum Master

El Scrum Master sirve al Scrum Team y a la organización en general. Es responsable de la efectividad del equipo: ayuda a los Developers a trabajar bien juntos, asesora al Product Owner en técnicas de gestión del Backlog, elimina impedimentos y orienta a la organización en la adopción de Scrum.

El Scrum Master no es un gerente de proyecto. No asigna tareas, no registra horas ni reporta al liderazgo sobre el rendimiento del equipo. Su rol se asemeja más al de un entrenador y líder al servicio del equipo. Protege al equipo de las distracciones, facilita los eventos y se opone cuando alguien (incluida la alta dirección) intenta eludir el framework de formas que perjudican al equipo.

Un error frecuente es tratar el rol del Scrum Master como una función a tiempo parcial, algo que un desarrollador gestiona en paralelo a su trabajo habitual en el sprint. Puede funcionar en equipos maduros, pero un equipo nuevo que adopta Scrum por primera vez se beneficia de contar con un Scrum Master dedicado que pueda observar el sistema de forma efectiva.

Developers

Los Developers son las personas que crean el Increment en cada Sprint. La Scrum Guide 2020 cambió el nombre de "Development Team" a "Developers" para señalar que la responsabilidad pertenece a todos los que realizan el trabajo, no a un subequipo.

Los Developers son multifuncionales. El Scrum Team en su conjunto dispone de todas las habilidades necesarias para entregar un Increment de producto funcional. Eso puede incluir diseñadores, ingenieros, evaluadores y redactores en el mismo equipo, pero la Scrum Guide no exige un conjunto de habilidades específico.

Los Developers son dueños del Sprint Backlog y gestionan su propio trabajo. Nadie fuera del Scrum Team les dice cómo hacer su trabajo ni asigna tareas a los individuos. Ellos deciden cómo convertir los elementos del Sprint Backlog en el Increment.

Los 5 eventos de Scrum

Cada evento de Scrum tiene un tiempo acotado y un propósito definido. El tiempo acotado no es solo una cuestión de eficiencia. Crea un ritmo predecible y obliga a tomar decisiones. A continuación se presentan los cinco eventos con sus duraciones máximas oficiales.

Sprint

El Sprint es el contenedor de todos los demás eventos de Scrum. Es una iteración de duración fija de un mes o menos. Durante un Sprint, no se realizan cambios que pongan en riesgo el objetivo del Sprint, el alcance puede aclararse a medida que el equipo aprende y el Sprint no se cancela salvo que el objetivo del Sprint quede obsoleto.

La duración constante de un Sprint crea un latido regular. El equipo sabe cuándo es la planificación, cuándo es la revisión y cuándo llega la próxima oportunidad de entregar. La mayoría de los equipos trabaja con sprints de dos semanas, aunque la duración adecuada depende de la tolerancia al riesgo, la frecuencia con la que cambia el producto y la cantidad de retroalimentación que necesita el equipo.

Planificación del Sprint

La planificación del Sprint lanza el Sprint y responde a dos preguntas: ¿qué se puede entregar en este Sprint y cómo se realizará el trabajo? El Product Owner presenta la parte superior del Product Backlog y el equipo selecciona el trabajo que considera que puede completar.

El resultado es el objetivo del Sprint, un único objetivo que da cohesión al Sprint, y el Sprint Backlog, los elementos específicos seleccionados más un plan para entregarlos.

Tiempo acotado: hasta 8 horas para un Sprint de un mes. Los sprints más cortos utilizan proporcionalmente menos tiempo.

Daily Scrum

El Daily Scrum es un evento de 15 minutos para que los Developers inspeccionen el progreso hacia el objetivo del Sprint y adapten su plan para las próximas 24 horas. No es un informe de estado para el Scrum Master. Es coordinación entre los Developers.

La Scrum Guide 2020 eliminó las tres preguntas prescritas (¿qué hice ayer?, ¿qué haré hoy?, ¿hay algún obstáculo?) y otorgó a los equipos flexibilidad en la forma de ejecutarlo, siempre que se cumpla el propósito. El objetivo es que los Developers terminen la reunión sabiendo qué está haciendo cada uno y dónde están los obstáculos.

Revisión del Sprint

La revisión del Sprint es una inspección del Increment y una adaptación del Product Backlog. El Scrum Team y las partes interesadas revisan lo que se logró, analizan qué cambió en el mercado o el negocio y acuerdan los próximos pasos.

No es una demostración, aunque las demostraciones suelen ocurrir en ella. La distinción importa: una demostración es una presentación; una revisión del Sprint es una sesión de trabajo. Las partes interesadas no son un público; son participantes.

Tiempo acotado: hasta 4 horas para un Sprint de un mes.

Retrospectiva del Sprint

La retrospectiva del Sprint es el momento en que el Scrum Team se examina a sí mismo. ¿Qué salió bien, qué no salió bien y qué una o dos cosas harán de forma diferente en el próximo sprint? El resultado es un plan de mejora concreto al que el equipo se compromete a poner en práctica.

Este evento es el motor de la mejora continua en Scrum. Los equipos que omiten las retrospectivas o las tratan como un trámite dejan de mejorar. El valor se acumula con el tiempo, por lo que los equipos con las mejores prácticas de retrospectiva tienden a ser los de mejor rendimiento a lo largo de un año o más.

Tiempo acotado: hasta 3 horas para un Sprint de un mes.

Los 3 artefactos de Scrum y sus compromisos

La Scrum Guide 2020 asoció cada artefacto con un compromiso, un objetivo medible que le da al artefacto una dirección y contra el cual se puede inspeccionar el progreso.

Product Backlog (compromiso: objetivo del producto)

El Product Backlog es una lista ordenada y emergente de todo lo que podría hacerse para mejorar el producto. Nunca está completo. Se añaden nuevos elementos, se eliminan los antiguos y las prioridades cambian a medida que el equipo aprende.

El compromiso del Product Backlog es el objetivo del producto: el objetivo a largo plazo hacia el que trabaja el Scrum Team. Cada Sprint debe acercar el producto al objetivo del producto, y el Product Backlog existe para describir el camino hacia allí.

El Product Owner es dueño del Product Backlog y es responsable de su ordenación y claridad.

Sprint Backlog (compromiso: objetivo del Sprint)

El Sprint Backlog es el conjunto de elementos del Product Backlog seleccionados para el Sprint, más el plan para entregarlos, más el objetivo del Sprint. Es una imagen en tiempo real del trabajo que los Developers planean completar en este Sprint.

El compromiso es el objetivo del Sprint: un único objetivo que le da propósito al Sprint. Si durante el Sprint surge trabajo nuevo, los Developers lo añaden al Sprint Backlog solo si no pone en riesgo el objetivo del Sprint.

Increment (compromiso: Definition of Done)

Un Increment es un paso concreto hacia el objetivo del producto. Cada Sprint debe producir al menos un Increment. Debe ser utilizable y cumplir con los estándares del equipo.

El compromiso es la Definition of Done (DoD): un entendimiento compartido de lo que significa "terminado." Si un elemento no cumple con la Definition of Done, no forma parte del Increment. La DoD crea transparencia y consistencia. No es una lista de verificación por elemento; es un estándar de calidad que aplica a todos los Increments.

Un vistazo general: roles + eventos + artefactos

Los 11 elementos son todo lo que Scrum prescribe. Ese es el framework completo. Todo lo que vaya más allá de estos 11 elementos es una práctica complementaria (como el desarrollo guiado por pruebas o el mapeo de historias de usuario) o una adición organizacional que se gestiona por separado.

Una cadencia típica de sprint de 2 semanas

Así es como se ve en la práctica un sprint estándar de dos semanas, día a día.

Día 1: Planificación del Sprint. El equipo se reúne, revisa la parte superior del Product Backlog con el Product Owner, establece el objetivo del Sprint y construye el Sprint Backlog. Para un sprint de dos semanas, la planificación suele durar entre 2 y 4 horas.

Del día 1 al día 10: Desarrollo. Cada día, incluido el día 1, el equipo celebra un Daily Scrum de 15 minutos. Los Developers se coordinan, hacen visibles los obstáculos y replanifican según sea necesario. El Scrum Master elimina los impedimentos. El Product Owner está disponible para aclaraciones.

Mañana del día 10: Revisión del Sprint. El equipo presenta el Increment a las partes interesadas, recibe retroalimentación y actualiza el Product Backlog. Esto suele durar entre 1 y 2 horas para un sprint de dos semanas.

Tarde del día 10: Retrospectiva del Sprint. El Scrum Team mira hacia adentro. Qué funcionó, qué no, qué cambios probar en el próximo sprint. Hasta 1,5 horas.

Día 11: Comienza el nuevo sprint. Misma estructura, misma cadencia, con una o dos mejoras surgidas de la retro.

La consistencia es el objetivo. Cuando cada sprint tiene la misma forma, la carga de coordinación disminuye y el equipo puede centrarse en el trabajo real. Consulte la planificación de proyectos para ver cómo conectar las cadencias de sprints con los cronogramas de proyectos más amplios.

Scrum vs. Kanban vs. Waterfall

Con frecuencia se compara Scrum con Kanban y la metodología Waterfall tradicional. Las diferencias van más allá de si se tienen sprints o un tablero.

En resumen: use Scrum cuando esté construyendo algo complejo y los requisitos cambiarán a medida que aprenda. Use Kanban cuando el trabajo llegue de forma continua y necesite optimizar el flujo en lugar de la iteración. Use Waterfall cuando el alcance sea fijo, el riesgo de cambio sea bajo y necesite un plan completo de antemano (común en construcción, industrias con fuertes requisitos de cumplimiento normativo o contratos de precio fijo).

Muchos equipos utilizan un híbrido Scrum/Kanban: cadencia de sprints para el trabajo de desarrollo planificado, tablero Kanban para bugs y solicitudes no planificadas. Está bien, siempre que el equipo tenga claro qué sistema rige qué trabajo.

Para herramientas de planificación estructurada que complementen Scrum, consulte la estructura de desglose del trabajo, el método de la ruta crítica, los gráficos Gantt y los gráficos PERT.

Errores comunes que arruinan Scrum

La mayoría de los fracasos de Scrum no son fallas del framework. Son fallas de implementación. Estos son los más frecuentes:

• Omitir la retrospectiva del Sprint. Este es el evento donde Scrum se potencia. Los equipos que lo omiten permanecen indefinidamente en el mismo nivel de disfunción. Si el tiempo escasea, acorte la retro, pero no la elimine.
• Tratar al Scrum Master como un gerente de proyecto. Asignar tareas, reportar Velocity al liderazgo y gestionar cronogramas son funciones de un PM. Un Scrum Master que hace esas tareas no está haciendo el trabajo de Scrum Master. Ambos roles se ven perjudicados.
• No tener un Product Owner real. Un Product Owner que no puede tomar decisiones de priorización, necesita la aprobación de tres comités o cambia el objetivo del Sprint a mitad de camino rompe la capacidad del equipo para planificar y entregar.
• Dejar que las partes interesadas eviten al Product Owner. Que los Developers reciban solicitudes de funcionalidades directamente de ejecutivos o clientes es una señal de que la autoridad del Product Owner no se respeta. Hay que corregir la cultura organizacional, no el framework.
• Ejecutar Sprints sin objetivo de Sprint. Un Sprint que es solo una lista de tareas no tiene un objetivo unificador. El equipo no puede tomar buenas decisiones de compromiso cuando llega información nueva, porque no hay nada que proteger.
• Tratar Scrum como la solución completa. Scrum no incluye prácticas de ingeniería. Los equipos también necesitan automatización de pruebas, integración continua y estándares de calidad claros (la Definition of Done) para realmente entregar Increments funcionales. Sin eso, la revisión del Sprint se convierte en un desfile de funcionalidades a medias.

Preguntas frecuentes

¿Es Scrum lo mismo que Agile?

No. Agile es un conjunto de valores y principios, descritos en el Manifiesto Agile (2001). Scrum es un framework para implementar esos principios. Se puede ser Agile sin usar Scrum, y se puede ejecutar Scrum de forma deficiente de un modo que contradiga los valores Agile. Piense en Agile como la filosofía y en Scrum como una forma estructurada de practicarla. Otros frameworks Agile incluyen Kanban, Extreme Programming (XP) y SAFe (Scaled Agile Framework).

¿Puede funcionar Scrum sin un Scrum Master?

Técnicamente, Scrum requiere un Scrum Master. En la práctica, los equipos maduros a veces operan sin uno dedicado, distribuyendo las responsabilidades de orientación y facilitación entre los miembros del equipo. Pero los equipos nuevos en Scrum generalmente necesitan un Scrum Master que proteja activamente el framework, oriente al equipo y elimine los impedimentos organizacionales. Sin ese rol, los equipos tienden a volver a sus hábitos anteriores: los Stand-ups se convierten en reuniones de estado, las retros se omiten y el Product Owner pierde su autoridad sobre el Backlog.

¿Cuánto tiempo debe durar un Sprint?

La Scrum Guide 2020 indica un mes o menos, y la mayoría de los equipos elige entre una y cuatro semanas. Los sprints de dos semanas son los más comunes en la práctica. La duración adecuada depende de qué tan estables son los requisitos, con qué frecuencia el equipo necesita retroalimentación externa y cuánta carga de planificación puede absorber el equipo. Los sprints más cortos generan retroalimentación más rápida, pero más ceremonias de planificación en relación con el tiempo de desarrollo. Los sprints más largos reducen la carga de las ceremonias, pero retrasan la retroalimentación. Empiece con dos semanas y ajuste según lo que aprenda.

¿Qué se eliminó en la Scrum Guide 2020?

La revisión de 2020 eliminó varios elementos que se habían acumulado en versiones anteriores. Las tres preguntas prescritas del Daily Scrum ("¿qué hice ayer?, ¿qué haré hoy?, ¿hay algún obstáculo?") se eliminaron en favor de formatos flexibles. El término "Development Team" fue reemplazado por "Developers." Se eliminaron el concepto de Chief Product Owner y el Sprint 0. El rol del Scrum Master como "servant-leader" se reformuló simplemente como "true leader." La guía de 2020 también añadió por primera vez los tres compromisos de los artefactos (objetivo del producto, objetivo del Sprint, Definition of Done), que fueron incorporaciones nuevas y no eliminaciones.

Scrum seguirá evolucionando. Ese es el punto. El framework en sí mismo practica lo que predica: inspeccionar, adaptarse y entregar una versión más ligera.

Para los equipos que quieran utilizar una matriz RACI junto con sus roles de Scrum, tenga en cuenta que RACI funciona bien para mapear los derechos de decisión entre las partes interesadas, mientras que los roles de Scrum definen las responsabilidades dentro del equipo. Los dos frameworks se complementan en lugar de entrar en conflicto.