Scrum es un marco de trabajo agil que ayuda a personas, equipos y organizaciones a generar valor mediante soluciones adaptativas para problemas complejos. Más que definir un proceso rígido, proporciona una guia de trabajo que permite a los equipos colaborar de forma efectiva, aprender continuamente y adaptarse rápidamente a los cambios.
Su esencia radica en el empirismo de tomar decisiones basadas en la transparencia, la inspección frecuente y la adaptación continua. Gracias a ello, los equipos pueden entregar valor de manera incremental, reducir riesgos y responder con rapidez a nuevas necesidades del negocio o de los clientes.
La mejora continua es mejor que la perfección postergada
Mark Twain
Aunque Scrum fue formalizado por Ken Schwaber y Jeff Sutherland a principios de la década de 1990, sus fundamentos se remontan a 1986, cuando Hirotaka Takeuchi e Ikujiro Nonaka publicaron en Harvard Business Review el artículo «The New New Product Development Game«. En este trabajo analizaron organizaciones innovadoras como Honda, Canon, Fuji-Xerox, NEC y Epson, observando que los equipos más exitosos no seguían un proceso secuencial tradicional, sino que trabajaban de forma colaborativa, con equipos multidisciplinarios, autoorganizados y capaces de adaptarse continuamente a los cambios.
Los autores utilizaron la metáfora del rugby, donde el equipo avanza unido hacia un objetivo común, inspirando el nombre Scrum (melé), que posteriormente sería adoptado por Schwaber y Sutherland para definir el framework que hoy se utiliza en millones de equipos alrededor del mundo (Takeuchi & Nonaka, 1986; Schwaber & Sutherland, 2020).
Scrum surge como respuesta a problemas comunes en los proyectos tradicionales, entre ellos:
-Entregas que tardan demasiado tiempo.
-Largos periodos de estabilización antes de poner un producto en producción.
-Dificultad para incorporar cambios durante el desarrollo.
-Disminución progresiva de la calidad del producto.
-Equipos desmotivados debido a proyectos largos y entregas tardías.
Pilares
- Transparencia: La información sobre el trabajo y el producto debe ser visible y comprensible para todos, facilitando la toma de decisiones.
- Inspección: El equipo revisa frecuentemente el progreso, el producto y los procesos para detectar oportunidades de mejora.
- Adaptación: Cuando la inspección identifica cambios necesarios, el equipo ajusta su forma de trabajo o el producto para maximizar el valor entregado (Mejora Continua).
Valores
- Compromiso: Trabajar juntos para alcanzar los objetivos del Equipo.
- Coraje: Afrontar desafíos, tomar decisiones y adaptarse al cambio.
- Foco: Concentrarse en el trabajo que genera mayor valor.
- Apertura: Mantener una comunicación honesta y transparente.
- Respeto: Valorar las capacidades y aportes de cada integrante del equipo.
Una formula comun para entender el marco de trabajo es la de 3-5-3.
3 Roles (Product Owner, Scrum Master, Equipo de Desarrollo), 5 Eventos (Sprint, Planning, Daily, Sprint Review, Sprint Retrospective) y 3 Artefactos (Backlog del Producto, Backlog del Sprint, Incremento).
Roles Scrum
Antes de comenzar un proyecto, es fundamental definir los roles que interactuarán para construir o mantener el producto.
El Scrum Team está conformado por:
- 1 Product Owner
- 1 Scrum Master
- Entre 3 y 9 integrantes del Equipo de Desarrollo
Product Owner (Dueño del Producto)
Es un único profesional que representa al cliente o al negocio frente al equipo de desarrollo.
Su responsabilidad es definir, priorizar y gestionar el Product Backlog (Pila del Producto), asegurando que el equipo siempre trabaje sobre aquello que genera mayor valor.
Además de administrar el Product Backlog, el Product Owner es responsable de maximizar el valor del producto y el retorno de la inversión (ROI). Para ello define una visión clara del producto, gestiona las necesidades de los interesados, prioriza continuamente el trabajo y acepta los incrementos desarrollados al finalizar cada Sprint.
Scrum Master
Es un profesional responsable de garantizar que Scrum sea comprendido, adoptado y mejorado continuamente dentro del equipo y la organización.
Actúa como un líder servicial, ayudando al equipo a mejorar su forma de trabajo mediante la mejora continua, la autoorganización y la eliminación de impedimentos.
Su principal responsabilidad es crear un entorno donde el equipo pueda alcanzar su máximo desempeño, eliminando impedimentos, facilitando la colaboración y promoviendo la adopción de Scrum en toda la organización. Actúa como facilitador, mentor y coach del equipo, fomentando una cultura de mejora continua.
El equipo es autoorganizado y multifuncional. Sus integrantes estiman el trabajo, realizan el seguimiento de su avance y asumen la responsabilidad compartida de entregar incrementos de producto con calidad suficiente para ser liberados a producción.
Equipo de Desarrollo (Solucionador)
Está conformado por entre 3 y 9 profesionales multidisciplinarios, responsables de construir el producto utilizando todas las habilidades necesarias para crear un incremento potencialmente entregable.
Eventos Scrum
Sprint
Al iniciar un proyecto con Scrum, el trabajo se organiza en iteraciones llamadas Sprint, donde se desarrolla el producto de forma incremental.
Un Sprint es un bloque de tiempo fijo (entre 1 y 4 semanas) durante el cual se crea un incremento del producto.
Durante cada Sprint se realizan todos los eventos de Scrum: Planning, Daily Scrum, Sprint Review y Sprint Retrospective.
Todos estos eventos utilizan la técnica de Time-boxing, es decir, cuentan con una duración máxima previamente establecida. El Time-box es una técnica mediante la cual se define una duración máxima para un evento o reunión.
Cuando el tiempo establecido finaliza, la actividad concluye, permitiendo que los participantes prioricen los temas realmente importantes, aprovechen mejor el tiempo y eviten desperdicios.
Sprint Planning (Planificación del Sprint)
Durante este evento se define qué trabajo se realizará y cómo se llevará a cabo.
Además, se establece el Sprint Goal (Objetivo del Sprint), que representa el propósito que se busca alcanzar durante la iteración.
| Sprint | Tiempo |
| 1 semana | 2 horas |
| 2 semanas | 4 horas |
| 3 semanas | 6 horas |
| 4 semanas | 8 horas |
Daily Scrum (Reunión Diaria)
Es una reunión diaria donde el equipo sincroniza su trabajo y planifica las siguientes 24 horas, permitiendo inspeccionar el progreso hacia el Objetivo del Sprint y realizar pequeños ajustes cuando sea necesario.
Se recomienda realizarla siempre en el mismo lugar y a la misma hora, preferiblemente de pie.
Durante la reunión se responden las tres preguntas recomendadas:
- ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint?
- ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
- ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?
Duración máxima: 15 minutos.
Sprint Review (Revisión del Sprint)
Durante este evento se presenta el incremento del producto a los principales interesados, se valida cuáles elementos fueron terminados y se obtiene retroalimentación que servirá para adaptar el Product Backlog.
| Sprint | Tiempo |
| 1 semana | 1 hora |
| 2 semanas | 2 horas |
| 3 semanas | 3 horas |
| 4 semanas | 4 horas |
Sprint Retrospective (Retrospectiva del Sprint)
La retrospectiva permite al equipo inspeccionar la forma en que trabajó durante el Sprint.
Se analizan las prácticas que funcionaron, aquellas que deben mejorar y las acciones concretas que permitirán incrementar la efectividad del equipo en el siguiente Sprint.
| Sprint | Tiempo |
| 1 semana | 1 hora |
| 2 semanas | 1,5 horas |
| 3 semanas | 2 horas |
| 4 semanas | 3 horas |
Refinamiento del Product Backlog
Aunque no es un evento oficial de Scrum, se recomienda dedicar aproximadamente el 10 % de la capacidad del Sprint a esta actividad. Consiste en un proceso continuo donde el Product Owner y el Equipo de Desarrollo revisan, agregan, eliminan, modifican, estiman y aclaran los elementos del Product Backlog para que estén preparados para futuros Sprint.
| Sprint | Tiempo |
| 1 semana | 4 horas |
| 2 semanas | 8 horas |
| 3 semanas | 12 horas |
| 4 semanas | 16 horas |
Artefactos Scrum
Product Backlog (Pila del Producto)
Es una lista priorizada que contiene todas las funcionalidades, mejoras, correcciones y necesidades del producto.
Evoluciona continuamente a medida que cambia el conocimiento del producto y del negocio, por lo que permanece en constante refinamiento.
El Product Owner es el único responsable de su contenido y priorización.
Sprint Backlog
Es el conjunto de elementos del Product Backlog seleccionados por el equipo para un Sprint, junto con el plan necesario para alcanzar el Objetivo del Sprint.
Está compuesto por los Product Backlog Items (PBI) que el equipo se compromete a entregar como parte del siguiente incremento del producto.
Incremento
El incremento es la suma de todos los Product Backlog Items (PBI) completados durante el Sprint, junto con los incrementos obtenidos en los Sprint anteriores.
Debe cumplir con la Definición de Terminado (Definition of Done) para que pueda ser liberado a producción cuando el Product Owner considere que aporta valor al negocio.
La esencia de Scrum
La Definición de Terminado (Definition of Done) es un acuerdo compartido por el equipo que establece los criterios mínimos que debe cumplir un incremento para considerarse completamente terminado. Su objetivo es garantizar un nivel consistente de calidad, transparencia y previsibilidad en cada Sprint, evitando que existan funcionalidades parcialmente terminadas o pendientes de completar.
Más allá de sus eventos y artefactos, Scrum promueve una forma diferente de trabajar basada en la colaboración, la transparencia y la mejora continua.
En un equipo Scrum:
- Se trabaja sobre objetivos claros y compartidos.
- El equipo se autoorganiza para decidir cómo alcanzar esos objetivos.
- Se entregan de manera frecuente las funcionalidades de mayor valor para el negocio.
- Los interesados proporcionan retroalimentación constante para mejorar el producto.
- El equipo inspecciona periódicamente su forma de trabajar para identificar oportunidades de mejora.
- Toda la organización puede visualizar el avance del producto mediante información transparente.
- Existe una comunicación abierta y honesta sobre el progreso, los riesgos y los impedimentos del proyecto.
Métricas recomendadas en Scrum
Las métricas permiten inspeccionar el desempeño del equipo y tomar decisiones basadas en evidencia. Algunas de las más utilizadas son:
- Velocidad del equipo (Velocity).
- Burndown del Sprint.
- Tiempo promedio de finalización de historias (Cycle Time).
- Trabajo en proceso (Work In Progress – WIP).
- Porcentaje de pruebas automatizadas.
- Deuda técnica.
- Satisfacción del cliente y del equipo.
Estas métricas no deben utilizarse para medir la productividad individual, sino para facilitar la mejora continua y aumentar la capacidad de entrega del equipo.
La más popular es el Burndown Chart (Gráfico de Trabajo Restante), durante el Sprint, normalmente después del Daily Scrum, el equipo actualiza el estado de los elementos terminados. El Burndown Chart permite visualizar el trabajo restante y el avance del Sprint, mostrando el ritmo del equipo durante el desarrollo del proyecto.
Aunque es una herramienta muy útil para el seguimiento, no reemplaza la importancia del empirismo ni de la inspección continua.
📲 No olvides seguirme en redes sociales para no perderte la próxima publicación.
¡Ser Mejor es tu decisión!
¿Te resultó útil este artículo?
Hablemos de cómo aplicar estas ideas en tu contexto.
📚 Cómo citar este artículo (APA 7)
Cifuentes G. (2016). Scrum desde cero: conceptos, roles, artefactos y eventos que debes conocer. Giovanny Cifuentes. https://www.giovannycifuentes.com/scrum/
Referencias
Hundermark, P. (2009). Un mejor Scrum: Un conjunto no oficial de consejos e ideas sobre cómo implementar Scrum (A. Cyment, Trad.). ScrumSense
Schwaber, K., & Sutherland, J. (2020). La Guía Scrum. La guía definitiva de Scrum: Las reglas del juego. Scrum Guides.
Sutherland, J. (2016). Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo. Editorial Océano.
Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business Review
