Scrum es un framework ligero para desarrollar y mejorar productos y soluciones en entornos complejos, mediante ciclos de trabajo llamados Sprints, inspección frecuente de los resultados y adaptación continua.
Su objetivo es ayudar a los equipos a generar valor de forma progresiva, aprendiendo de lo que ocurre durante el desarrollo en lugar de intentar definir y ejecutar todo el proyecto de principio a fin.
Aunque Scrum nació en el ámbito del desarrollo de software, actualmente puede utilizarse en muchos tipos de proyectos en los que existen incertidumbre, cambios frecuentes y necesidad de obtener resultados y feedback rápidamente.
Para un emprendedor, Scrum puede ser especialmente útil cuando necesita coordinar un equipo y avanzar en el desarrollo de un producto sin esperar a tener definida toda la solución desde el principio.
¿Qué es Scrum?
Scrum es un framework de trabajo basado en el empirismo y el pensamiento Lean. El empirismo significa que el conocimiento se construye a partir de la experiencia y de la observación de lo que sucede realmente.
Scrum se apoya en tres pilares:
- Transparencia: el trabajo y el estado del producto deben ser visibles para quienes toman decisiones.
- Inspección: el equipo debe revisar con frecuencia el progreso y los resultados.
- Adaptación: cuando se detecta una desviación o aparece nueva información, se modifica el rumbo.
Por eso Scrum no pretende establecer de antemano todos los pasos que debe seguir un equipo. Proporciona una estructura para que pueda inspeccionar lo que ocurre y adaptar su trabajo.
La Scrum Guide define Scrum como un framework ligero para generar valor mediante soluciones adaptativas a problemas complejos.
¿Para qué sirve Scrum?
Scrum sirve para organizar el trabajo de equipos que desarrollan productos o soluciones en contextos donde existe incertidumbre.
Puede ayudarte a:
- dividir el desarrollo en ciclos manejables;
- establecer objetivos de corto plazo;
- priorizar el trabajo;
- entregar incrementos de producto con frecuencia;
- obtener feedback;
- detectar problemas antes;
- adaptar prioridades;
- mejorar continuamente;
- coordinar equipos multidisciplinares;
- hacer visible el progreso;
- reducir el riesgo de invertir demasiado tiempo en una solución que necesita cambiar.
Scrum no garantiza que el producto tenga éxito. Lo que proporciona es un sistema para obtener información y reaccionar ante ella con mayor rapidez.
Los valores de Scrum
Scrum se apoya en cinco valores:
- Compromiso: Las personas se comprometen a alcanzar los objetivos del Scrum Team y a apoyarse mutuamente.
- Foco: El equipo concentra su atención en el trabajo del Sprint y en el objetivo del producto.
- Apertura: El equipo y las partes interesadas deben ser transparentes respecto al trabajo y a los problemas.
- Respeto: Las personas se reconocen como profesionales capaces y autónomos.
- Coraje: El equipo necesita valentía para hacer lo correcto, afrontar problemas y tomar decisiones difíciles.
Estos valores ayudan a crear las condiciones necesarias para que funcionen la transparencia, inspección y adaptación.
¿Cómo funciona Scrum?
Scrum organiza el trabajo en Sprints. Un Sprint es un periodo de duración fija de un mes o menos durante el cual el Scrum Team trabaja para conseguir un Sprint Goal y crear un incremento de producto que cumpla la Definition of Done.
El ciclo puede representarse así:
Product Goal → Product Backlog → Sprint Planning → Sprint → Increment → Sprint Review → Sprint Retrospective → siguiente Sprint
Durante cada Sprint el equipo:
- define qué objetivo quiere conseguir;
- selecciona el trabajo que considera necesario;
- desarrolla el incremento;
- inspecciona los resultados;
- obtiene información de las partes interesadas;
- identifica mejoras;
- adapta el Product Backlog;
- comienza el siguiente ciclo.
Un nuevo Sprint comienza inmediatamente después de terminar el anterior.
El Scrum Team
Scrum establece un único Scrum Team, formado por tres tipos de responsabilidades:
- Product Owner
- Scrum Master
- Developers
No existe un “equipo de desarrollo” separado del Scrum Team en la definición actual de Scrum. La Scrum Guide 2020 sustituyó este concepto por un único equipo orientado a un objetivo común.
El Scrum Team es responsable de crear un incremento valioso y útil en cada Sprint. Debe ser un equipo autogestionado, capaz de decidir quién hace qué, cómo realiza el trabajo y en qué debe trabajar dentro del marco de Scrum.
Product Owner
El Product Owner es responsable de maximizar el valor del producto que resulta del trabajo del Scrum Team.
Entre sus responsabilidades se encuentran:
- desarrollar y comunicar el Product Goal;
- crear y comunicar los elementos del Product Backlog;
- ordenar los elementos del Product Backlog;
- asegurar que el Product Backlog sea transparente y comprensible.
El Product Owner puede delegar determinadas tareas, pero sigue siendo responsable de la gestión efectiva del Product Backlog. No debe entenderse simplemente como “la voz del cliente”. Su responsabilidad principal es maximizar el valor del producto.
Scrum Master
El Scrum Master es responsable de establecer Scrum tal como se define en la Scrum Guide. Ayuda al Scrum Team y a la organización a comprender y aplicar Scrum.
Entre sus funciones se encuentran:
- ayudar al equipo a mejorar su efectividad;
- facilitar la eliminación de impedimentos;
- ayudar a establecer objetivos claros;
- facilitar la colaboración;
- ayudar a la organización a adoptar Scrum;
- actuar como líder al servicio del equipo y de la organización.
El Scrum Master no es un jefe de proyecto tradicional. Su función no consiste en asignar tareas y controlar individualmente a cada miembro del equipo.
Developers
Los Developers son las personas del Scrum Team que se comprometen a crear cualquier aspecto de un Increment utilizable en cada Sprint.
Sus responsabilidades incluyen:
- crear el Sprint Backlog;
- desarrollar un plan para el Sprint;
- mantener la calidad mediante la Definition of Done;
- adaptar diariamente su plan hacia el Sprint Goal;
- responsabilizarse profesionalmente de su trabajo.
El término Developers no significa necesariamente únicamente programadores. En un contexto empresarial puede incluir a las diferentes personas necesarias para crear el producto o servicio.
Los artefactos de Scrum
Scrum define tres artefactos:
- Product Backlog
- Sprint Backlog
- Increment
Cada uno incorpora un compromiso que ayuda a proporcionar transparencia y foco.
| Artefacto | Compromiso |
|---|---|
| Product Backlog | Product Goal |
| Sprint Backlog | Sprint Goal |
| Increment | Definition of Done |
Product Backlog
El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto. No es simplemente una lista estática de requisitos. Evoluciona a medida que el equipo aprende más sobre el producto, los usuarios y el entorno.
El Product Owner es responsable de su gestión efectiva. Los elementos de mayor prioridad deben estar suficientemente preparados para poder ser seleccionados durante la planificación de un Sprint.
Product Goal
El Product Goal describe un estado futuro del producto que sirve como objetivo a largo plazo para el Scrum Team. El equipo debe trabajar hacia ese objetivo.Cada Sprint debería acercar el producto al Product Goal.
La incorporación explícita del Product Goal fue una de las novedades importantes de la Scrum Guide 2020.
Sprint Backlog
El Sprint Backlog contiene:
- el Sprint Goal;
- los elementos del Product Backlog seleccionados para el Sprint;
- el plan para entregar el Increment.
Es un plan creado por y para los Developers. No es necesario que permanezca idéntico durante todo el Sprint. A medida que el equipo aprende, puede adaptar su plan siempre que mantenga el foco en el Sprint Goal.
Sprint Goal
El Sprint Goal es el objetivo que da sentido al Sprint. No es simplemente una lista de tareas.
Por ejemplo:
❌ “Crear landing, formulario, página de precios y sistema de registro.”
Mejor:
✅ “Validar que los usuarios pueden completar el proceso de registro y solicitar el servicio.”
Las tareas son el medio; el Sprint Goal expresa para qué se realiza el trabajo.
Increment
El Increment es un paso concreto hacia el Product Goal. Para formar parte del Increment, el trabajo debe cumplir la Definition of Done.
Puede haber varios incrementos dentro de un mismo Sprint y un incremento puede entregarse antes de finalizar el Sprint. La idea fundamental es que cada incremento sea utilizable y aporte valor.
Definition of Done
La Definition of Done es una descripción formal del estado del Increment cuando cumple las medidas de calidad requeridas para el producto. Permite que todo el equipo tenga el mismo significado de “terminado”.
Por ejemplo, para una funcionalidad digital podría incluir:
- desarrollada;
- revisada;
- probada;
- integrada;
- documentada cuando sea necesario;
- disponible para su uso.
No debe confundirse “terminado” con “hecho parcialmente”.
Los eventos de Scrum
Scrum establece cinco eventos:
- Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
El Sprint es el contenedor de los demás eventos. Estos eventos permiten inspeccionar y adaptar el trabajo de forma periódica.
1. Sprint
El Sprint es el ciclo de trabajo de Scrum. Tiene una duración fija de un mes o menos.
Durante el Sprint:
- se trabaja hacia el Sprint Goal;
- se mantiene la calidad;
- se refina el Product Backlog cuando es necesario;
- el alcance puede aclararse y renegociarse con el Product Owner a medida que se aprende.
Los Sprints cortos permiten aumentar la frecuencia de inspección y reducir el riesgo de mantener durante demasiado tiempo una dirección equivocada.
2. Sprint Planning
El Sprint Planning inicia el Sprint. El Scrum Team aborda tres cuestiones fundamentales:
- ¿Por qué es valioso este Sprint? Se establece el Sprint Goal.
- ¿Qué se puede hacer? Se seleccionan los elementos del Product Backlog que pueden contribuir al objetivo.
- ¿Cómo se realizará el trabajo? Los Developers planifican cómo convertir esos elementos en un Increment.
La planificación no consiste en intentar predecir perfectamente todo lo que ocurrirá durante el Sprint.
3. Daily Scrum
El Daily Scrum es un evento de 15 minutos para los Developers. Su finalidad es inspeccionar el progreso hacia el Sprint Goal y adaptar el Sprint Backlog cuando sea necesario. No es una reunión para informar al jefe sobre lo que hizo cada persona el día anterior.
Los Developers pueden utilizar la estructura que consideren más adecuada siempre que el evento ayude a avanzar hacia el Sprint Goal.
4. Sprint Review
La Sprint Review sirve para inspeccionar el resultado del Sprint y determinar futuras adaptaciones. Participan el Scrum Team y las partes interesadas relevantes.
Durante la revisión se analiza:
- qué se consiguió;
- qué cambió en el entorno;
- qué información nueva se obtuvo;
- qué debería hacerse a continuación.
Por tanto, no es simplemente una “demo”. Es una sesión de inspección y adaptación del producto y del Product Backlog.
5. Sprint Retrospective
La Sprint Retrospective permite al Scrum Team analizar cómo ha funcionado durante el Sprint.
Puede revisar:
- personas;
- interacciones;
- procesos;
- herramientas;
- Definition of Done;
- problemas encontrados;
- oportunidades de mejora.
El objetivo es identificar cambios que permitan mejorar la calidad y efectividad del equipo. Una retrospectiva útil termina con acciones concretas de mejora, no solamente con una conversación sobre lo que salió mal.
Ejemplo práctico de Scrum para una startup
Imagina una startup que quiere desarrollar una plataforma para conectar emprendedores con expertos. El equipo tiene una idea general del producto, pero todavía no sabe qué funcionalidades serán realmente utilizadas.
- Product Goal: Conseguir una plataforma funcional que permita a emprendedores encontrar y contactar con expertos adecuados.
- Product Backlog inicial: Entre otros elementos:
- registro de emprendedores;
- perfiles de expertos;
- buscador;
- filtros;
- sistema de contacto;
- valoraciones;
- notificaciones;
- panel de usuario.
El Product Owner ordena el Product Backlog según el valor esperado y la información necesaria para avanzar.
- Sprint Goal: Permitir que un emprendedor encuentre un experto y solicite contacto.
- Sprint: El equipo selecciona los elementos necesarios para alcanzar ese objetivo. No necesita construir todavía:
- sistema de valoraciones;
- aplicación móvil;
- notificaciones avanzadas;
- funcionalidades secundarias.
- Increment: Al finalizar el Sprint existe una versión funcional que permite: registrarse → buscar experto → consultar perfil → solicitar contacto.
- Sprint Review: Los usuarios y partes interesadas prueban la solución. Se descubre que los usuarios necesitan más información sobre la experiencia de los expertos antes de contactar.
- Adaptación: El Product Owner incorpora y prioriza nuevos elementos en el Product Backlog.
El siguiente Sprint puede centrarse en mejorar los perfiles y facilitar la decisión del usuario.
De esta manera, el producto evoluciona a partir de información real, no solamente de las previsiones iniciales.
¿Cómo aplicar Scrum en una pequeña empresa?
No es necesario empezar con un proyecto enorme.
- Paso 1. Define el producto: Determina qué producto o solución está desarrollando el equipo.
- Paso 2. Establece el Product Goal: Define qué estado futuro quieres alcanzar.
- Paso 3. Crea el Product Backlog: Recoge y ordena el trabajo necesario para avanzar hacia ese objetivo.
- Paso 4. Forma el Scrum Team: Asegúrate de que existen las responsabilidades de Product Owner, Scrum Master y Developers.
- Paso 5. Define una duración de Sprint: Elige una duración de un mes o menos que permita inspeccionar y adaptar el trabajo con suficiente frecuencia.
- Paso 6. Define el Sprint Goal: Antes de seleccionar tareas, establece qué resultado quieres conseguir.
- Paso 7. Selecciona el trabajo: Los Developers seleccionan los elementos que consideran necesarios para alcanzar el Sprint Goal.
- Paso 8. Desarrolla el Increment: Trabaja durante el Sprint manteniendo la calidad definida.
- Paso 9. Realiza la Sprint Review: Revisa el resultado con las personas interesadas y utiliza el feedback para adaptar el Product Backlog.
- Paso 10. Haz la Retrospective: Identifica cómo mejorar la forma de trabajar en el siguiente Sprint.
- Paso 11. Repite: Comienza un nuevo Sprint y continúa avanzando hacia el Product Goal.
Scrum para emprendedores
Scrum puede resultar especialmente interesante para startups cuando existe incertidumbre sobre:
- qué funcionalidades desarrollar;
- qué necesitan los usuarios;
- cómo debe evolucionar el producto;
- qué prioridades debe tener el equipo;
- qué solución genera más valor.
Sin embargo, Scrum no sustituye la validación del modelo de negocio.
Una startup puede utilizar Lean Startup para validar hipótesis sobre clientes y mercado y Scrum para organizar el desarrollo del producto.
Por ejemplo:
- Lean Startup → ¿qué debemos validar?
- Scrum → ¿cómo organizamos el trabajo para desarrollar y mejorar la solución?
Ambos enfoques pueden complementarse.
Scrum vs Kanban
Scrum y Kanban pueden utilizarse para gestionar trabajo de manera ágil, pero tienen estructuras diferentes.
| Característica | Scrum | Kanban |
|---|---|---|
| Estructura | Framework definido | Método de gestión del flujo |
| Trabajo | Sprints | Flujo continuo |
| Roles específicos | Product Owner, Scrum Master, Developers | No prescribe los mismos roles |
| Objetivos | Product Goal y Sprint Goal | Depende del sistema utilizado |
| Planificación | Sprint Planning | Planificación según necesidad |
| Revisión | Sprint Review | Feedback continuo |
| Mejora | Retrospective | Mejora continua |
| Trabajo en curso | Gestionado dentro del Sprint | Se limita explícitamente mediante WIP |
No es necesario elegir Scrum porque sea “más ágil” que Kanban. La elección depende del tipo de trabajo y de las necesidades del equipo.
👉 Consulta la TIP sobre metodología Kanban para conocer cómo funciona la gestión visual del flujo.
Scrum vs gestión tradicional de proyectos
En un enfoque tradicional, puede existir un plan detallado que intenta definir desde el principio el alcance, calendario y actividades del proyecto.
Scrum parte de una premisa diferente: cuando existe incertidumbre, no siempre es posible conocer de antemano cuál será la mejor solución.
| Gestión tradicional | Scrum |
|---|---|
| Plan detallado inicial | Planificación adaptativa |
| Cambios controlados mediante procesos específicos | Adaptación frecuente |
| Entrega final o grandes hitos | Incrementos frecuentes |
| Alcance definido inicialmente | Alcance puede evolucionar |
| Seguimiento del plan | Inspección del producto y del progreso |
| Éxito ligado al cumplimiento del plan | Enfoque en valor y resultados |
No significa que Scrum elimine la planificación. Significa que la planificación se adapta a lo aprendido.
Ventajas de Scrum
- Feedback frecuente: Permite recibir información sobre el producto durante su desarrollo.
- Adaptación: El equipo puede modificar prioridades a partir de nueva información.
- Transparencia: El trabajo y el progreso son visibles.
- Foco: Los Sprint Goals ayudan a concentrar los esfuerzos.
- Entregas incrementales: El producto evoluciona mediante incrementos.
- Mejora continua: Las retrospectivas permiten mejorar la forma de trabajar.
- Responsabilidad compartida: El Scrum Team trabaja hacia objetivos comunes.
Limitaciones de Scrum
Scrum tampoco es adecuado para cualquier situación. Puede resultar problemático cuando:
- el equipo no tiene capacidad real para autogestionarse;
- nadie puede asumir la responsabilidad de maximizar el valor;
- los objetivos cambian constantemente sin una dirección clara;
- las partes interesadas nunca proporcionan feedback;
- se convierte en un conjunto de reuniones sin adaptación real;
- se utilizan Sprints pero el trabajo sigue funcionando como un proyecto tradicional;
- se mide el rendimiento únicamente por número de tareas completadas.
Scrum no solucionará por sí mismo:
- un producto sin demanda;
- un modelo de negocio inviable;
- falta de liderazgo;
- ausencia de clientes;
- problemas graves de comunicación;
- falta de conocimientos técnicos.
El framework necesita un contexto organizativo que permita trabajar de forma colaborativa y adaptativa.
Errores frecuentes al aplicar Scrum
- Convertir Scrum en una lista de reuniones: Hacer Daily, Planning, Review y Retrospective no significa necesariamente estar trabajando de forma efectiva con Scrum. La finalidad de los eventos es facilitar inspección y adaptación.
- Confundir el Product Owner con un jefe de proyecto: El Product Owner tiene responsabilidad sobre el valor y el Product Backlog, no sobre controlar individualmente el trabajo de cada persona.
- Utilizar al Scrum Master como jefe: El Scrum Master es un líder al servicio del equipo y de la organización.
- Medir el éxito por tareas terminadas: Completar muchas tareas no garantiza que se haya generado valor.
- Crear Sprints sin un objetivo: Un Sprint debería tener un Sprint Goal que dé sentido al trabajo.
- No entregar un Increment utilizable: El resultado del Sprint debe cumplir la Definition of Done.
- No hablar con usuarios o stakeholders: La inspección del producto necesita información relevante.
- Alargar los Sprints cuando no se llega: Si el equipo no consigue todo el trabajo previsto, la solución no debería ser simplemente ampliar el Sprint. Es necesario inspeccionar qué está ocurriendo y adaptar la forma de trabajar.
¿Cuándo utilizar Scrum?
Scrum puede ser adecuado cuando:
- el producto todavía está evolucionando;
- existe incertidumbre;
- las necesidades pueden cambiar;
- se necesita feedback frecuente;
- existe un equipo multidisciplinar;
- el trabajo puede dividirse en incrementos;
- existe una persona capaz de asumir la responsabilidad de Product Owner;
- el equipo puede autogestionarse.
¿Cuándo puede no ser la mejor opción?
Puede no ser necesario utilizar Scrum cuando:
- el trabajo es altamente repetitivo;
- las tareas llegan continuamente y no necesitan organizarse en Sprints;
- el equipo es muy pequeño y Scrum añadiría burocracia;
- el problema se resuelve mejor mediante un flujo continuo;
- no existe un producto que pueda evolucionar mediante incrementos.
En estos casos puede ser más apropiado utilizar Kanban u otro sistema de gestión.
¿Cómo puede ayudar la inteligencia artificial a un equipo Scrum?
La inteligencia artificial puede utilizarse como herramienta de apoyo, pero no sustituye las responsabilidades del Scrum Team.
Puede ayudar a:
- analizar feedback de usuarios;
- resumir entrevistas;
- identificar patrones en comentarios;
- proponer posibles Product Backlog Items;
- convertir necesidades en borradores de historias de usuario;
- preparar criterios de aceptación;
- resumir reuniones;
- analizar incidencias;
- generar documentación;
- identificar tareas repetitivas;
- analizar datos de producto.
Por ejemplo, después de una Sprint Review, una herramienta de IA podría agrupar cientos de comentarios de usuarios en temas como: usabilidad → funcionalidades → precio → rendimiento → soporte
El equipo puede utilizar esa información para analizar qué cambios deberían incorporarse al Product Backlog.
La decisión final debe seguir siendo responsabilidad de las personas correspondientes dentro del Scrum Team.
Checklist para empezar con Scrum
Antes de implantar Scrum, comprueba:
- Tenemos un producto o solución claramente identificado.
- Existe un Product Goal.
- Tenemos un Product Owner.
- Tenemos un Scrum Master.
- Disponemos de Developers con las capacidades necesarias.
- Existe un Product Backlog ordenado.
- Definimos una Definition of Done.
- Cada Sprint tiene un Sprint Goal.
- El Sprint tiene una duración fija de un mes o menos.
- Realizamos Sprint Planning.
- Los Developers realizan Daily Scrum.
- Revisamos el resultado en la Sprint Review.
- Realizamos Sprint Retrospective.
- Creamos un Increment que cumple la Definition of Done.
- Utilizamos lo aprendido para adaptar el siguiente Sprint.
❓ FAQ (Preguntas frecuentes)
¿Qué es Scrum?
Scrum es un framework ligero para generar valor mediante soluciones adaptativas en entornos complejos. Organiza el trabajo mediante Sprints, objetivos, incrementos, inspección y adaptación.
¿Scrum es una metodología ágil?
Scrum es un framework que forma parte del ecosistema de enfoques ágiles. No debe confundirse con Agile en general: Agile representa un conjunto más amplio de valores y principios, mientras Scrum proporciona una estructura concreta para trabajar.
¿Cuánto dura un Sprint?
Un Sprint tiene una duración fija de un mes o menos. El equipo puede utilizar Sprints más cortos para aumentar la frecuencia de inspección y aprendizaje.
¿Cuáles son los roles de Scrum?
La terminología actual habla de tres tipos de responsabilidades dentro del Scrum Team: Product Owner, Scrum Master y Developers. No existe un equipo de desarrollo separado del Scrum Team.
¿Qué es el Product Backlog?
Es una lista ordenada y evolutiva de lo que se necesita para mejorar el producto. El Product Owner es responsable de su gestión efectiva.
¿Qué diferencia hay entre Scrum y Kanban?
Scrum organiza el trabajo mediante Sprints, objetivos y eventos definidos. Kanban se centra principalmente en gestionar y mejorar el flujo de trabajo, utilizando visualización y límites de trabajo en curso. Kanban no necesita trabajar con Sprints.
¿Scrum sirve para una startup?
Sí, especialmente cuando la startup desarrolla un producto en un entorno incierto y necesita trabajar con ciclos cortos, obtener feedback y adaptar prioridades. Scrum puede combinarse con Lean Startup para conectar el desarrollo del producto con la validación de hipótesis de negocio.
¿Cuál es la diferencia entre Scrum y Agile?
Agile es un enfoque basado en valores y principios para trabajar de forma adaptativa. Scrum es un framework concreto que proporciona una estructura para aplicar ese enfoque mediante Sprints, responsabilidades, eventos y artefactos.
Scrum proporciona una estructura para que los equipos puedan crear valor, inspeccionar resultados y adaptarse continuamente en entornos complejos.
Su funcionamiento se basa en:
Product Goal → Product Backlog → Sprint Goal → Sprint → Increment → Review → Retrospective → adaptación
Para un emprendedor, Scrum puede ser especialmente útil cuando necesita desarrollar un producto con un equipo y todavía existe incertidumbre sobre la solución final.
Sin embargo, Scrum no responde a todas las preguntas de un proyecto empresarial.
Puedes combinar diferentes enfoques según el problema:
- Design Thinking para comprender al usuario y definir problemas y soluciones.
- Lean Startup para validar hipótesis de negocio.
- Scrum para organizar el desarrollo iterativo de un producto.
- Kanban para gestionar y mejorar el flujo de trabajo.
- Stage-Gate para tomar decisiones sobre la continuidad de proyectos.
La clave no es aplicar Scrum de manera mecánica, sino utilizar su estructura para trabajar con objetivos claros, entregar incrementos útiles, obtener información y adaptar las decisiones a medida que aumenta el conocimiento.
