Guía de Scrum oficial en español

Guía de Scrum 2020™

Esta versión HTML de la Guía de Scrum es una adaptación directa de la versión de noviembre de 2020, disponible en formato PDF aquí.

Propósito de la Guía de Scrum

Desarrollamos Scrum a principios de los años noventa. Escribimos la primera versión de la Guía de Scrum en 2010 para ayudar a las personas de todo el mundo a comprender Scrum. Desde entonces, hemos ido evolucionando la Guía mediante pequeñas actualizaciones funcionales. Juntos, la respaldamos.

La Guía de Scrum contiene la definición de Scrum. Cada elemento del marco sirve a un propósito específico que es esencial para el valor general y los resultados obtenidos con Scrum. Cambiar el diseño o las ideas centrales de Scrum, omitir elementos o no seguir las reglas de Scrum, encubre problemas y limita los beneficios de Scrum, incluso puede llegar a hacer que pierda su utilidad.

Seguimos el uso creciente de Scrum en un mundo cada vez más complejo. Nos sentimos honrados al ver que Scrum se adopta en muchos ámbitos que implican trabajos esencialmente complejos, más allá del desarrollo de productos de software donde Scrum tiene su origen. A medida que se expande el uso de Scrum, los desarrolladores, investigadores, analistas, científicos y otros especialistas hacen el trabajo. Utilizamos la palabra «desarrolladores» en Scrum no para excluir, sino para simplificar. Si obtienes valor de Scrum, considérate incluido.

A medida que se usa Scrum, pueden encontrarse, aplicarse y diseñarse patrones, procesos y conocimientos que encajan con el marco de Scrum tal como se describe en este documento. Su descripción está fuera del propósito de esta Guía, ya que son sensibles al contexto y difieren ampliamente según el uso de Scrum. Estas tácticas varían ampliamente y se describen en otros lugares.

¿Qué es Scrum?

Scrum es un marco de trabajo ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos.

En resumen, Scrum requiere un Scrum Master que fomente un entorno donde:

Un Product Owner ordena el trabajo para un problema complejo en un Product Backlog.
El Scrum Team convierte una selección del trabajo en un Incremento de valor durante un Sprint.
El Scrum Team y sus partes interesadas inspeccionan los resultados y ajustan para el siguiente Sprint.
Repetir.

Scrum es simple. Pruébalo tal como es y determina si su filosofía, teoría y estructura ayudan a alcanzar objetivos y crear valor. El marco de Scrum está intencionalmente incompleto, definiendo solo las partes requeridas para implementar la teoría de Scrum. Scrum se construye con la inteligencia colectiva de las personas que lo utilizan. En lugar de proporcionar instrucciones detalladas, las reglas de Scrum guían las relaciones e interacciones.

Diversos procesos, técnicas y métodos pueden emplearse dentro del marco. Scrum envuelve prácticas existentes o las hace innecesarias. Scrum hace visible la eficacia relativa de la gestión actual, el entorno y las técnicas de trabajo, permitiendo mejoras.

Teoría de Scrum

Scrum se basa en el empirismo y el pensamiento Lean.

Empirismo sostiene que el conocimiento proviene de la experiencia y de tomar decisiones basadas en lo observado.
Pensamiento Lean reduce el desperdicio y se enfoca en lo esencial.

Scrum emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar el riesgo. Involucra a grupos de personas que colectivamente tienen todas las habilidades y experiencia necesarias para realizar el trabajo, compartiéndolas o adquiriéndolas según sea necesario.

Scrum combina cuatro eventos formales de inspección y adaptación dentro de un evento contenedor: el Sprint. Estos eventos funcionan porque implementan los pilares empíricos de Scrum: transparencia, inspección y adaptación.

Transparencia

El proceso emergente y el trabajo deben ser visibles tanto para quienes lo realizan como para quienes lo reciben. Con Scrum, las decisiones importantes se basan en el estado percibido de sus tres artefactos formales. Artefactos con baja transparencia pueden llevar a decisiones que disminuyen el valor y aumentan el riesgo.

La transparencia permite la inspección. La inspección sin transparencia es engañosa y un desperdicio.

Inspección

Los artefactos de Scrum y el progreso hacia los objetivos acordados deben inspeccionarse frecuentemente y con diligencia para detectar posibles desviaciones o problemas no deseados. Para ayudar con la inspección, Scrum proporciona cadencia en la forma de cinco eventos.

La inspección permite la adaptación. Inspeccionar sin adaptarse se considera inútil. Los eventos de Scrum están diseñados para provocar el cambio.

Adaptación

Si cualquier aspecto de un proceso se desvía de los límites aceptables, o si el producto resultante es inaceptable, el proceso aplicado o los materiales producidos deben ajustarse. El ajuste debe hacerse lo antes posible para minimizar desviaciones futuras.

La adaptación se vuelve más difícil si las personas involucradas no están empoderadas o no se autogestionan. Se espera que un Scrum Team se adapte en el momento en que aprende algo nuevo mediante la inspección.

Valores de Scrum

El uso exitoso de Scrum depende de que las personas se vuelvan más competentes en vivir cinco valores:

Compromiso, Enfoque, Apertura, Respeto y Valentía

El Scrum Team se compromete a alcanzar sus metas y a apoyarse mutuamente.
Su enfoque principal está en el trabajo del Sprint para avanzar lo máximo posible hacia estas metas.
El Scrum Team y sus partes interesadas son abiertos sobre el trabajo y los desafíos.
Los miembros del Scrum Team se respetan mutuamente como personas capaces e independientes, y son respetados como tales por quienes trabajan con ellos.
Los miembros del Scrum Team tienen el coraje de hacer lo correcto y de trabajar en problemas difíciles.

Estos valores orientan al Scrum Team respecto a su trabajo, acciones y comportamiento. Las decisiones que se toman, los pasos que se dan y la manera en que se utiliza Scrum deben reforzar estos valores, no disminuirlos o socavarlos. Los miembros del Scrum Team aprenden y exploran estos valores a medida que trabajan con los eventos y artefactos de Scrum.

Cuando estos valores son incorporados por el Scrum Team y por las personas con las que trabajan, los pilares empíricos de Scrum —transparencia, inspección y adaptación— cobran vida y construyen confianza.

El Scrum Team

La unidad fundamental de Scrum es un pequeño equipo de personas: el Scrum Team. Está compuesto por un Scrum Master, un Product Owner y Desarrolladores. Dentro del Scrum Team no existen subequipos ni jerarquías. Es una unidad cohesiva de profesionales enfocados en un único objetivo a la vez: el Objetivo del Producto (Product Goal).

Características clave del Scrum Team:

Es multifuncional: sus miembros tienen todas las habilidades necesarias para crear valor en cada Sprint.
Es autogestionado: decide internamente quién hace qué, cuándo y cómo.
Su tamaño suele ser de 10 personas o menos, lo suficientemente pequeño para mantener agilidad y lo suficientemente grande para completar un trabajo significativo durante el Sprint.

Si un Scrum Team se vuelve demasiado grande, se recomienda reorganizarlo en varios equipos cohesivos que trabajen en el mismo producto, compartiendo el mismo Product Goal, Product Backlog y Product Owner.

El Scrum Team es responsable de todas las actividades relacionadas con el producto: colaboración con stakeholders, verificación, mantenimiento, operación, experimentación, investigación y desarrollo, y cualquier otra necesaria. Están estructurados y empoderados por la organización para gestionar su propio trabajo. Trabajar en Sprints a un ritmo sostenible mejora su enfoque y consistencia.

Responsabilidad compartida:

Todo el Scrum Team es responsable de crear un Incremento valioso y útil en cada Sprint.

Scrum define tres responsabilidades específicas dentro del Scrum Team:

Desarrolladores

Son las personas del Scrum Team comprometidas a crear cualquier aspecto de un Incremento usable en cada Sprint.

Los Desarrolladores son siempre responsables de:

Crear un plan para el Sprint: el Sprint Backlog.
Incorporar calidad cumpliendo con la Definición de Hecho (Definition of Done).
Adaptar su plan diariamente hacia el Objetivo del Sprint (Sprint Goal).
Rendir cuentas entre ellos como profesionales.

Product Owner

Es responsable de maximizar el valor del producto que resulta del trabajo del Scrum Team. La forma de hacerlo puede variar entre organizaciones, equipos e individuos.

También es responsable de una gestión efectiva del Product Backlog, que incluye:

Desarrollar y comunicar claramente el Product Goal.
Crear y comunicar claramente los elementos del Product Backlog.
Ordenar los elementos del Product Backlog.
Asegurar que el Product Backlog sea transparente, visible y entendido.

El Product Owner puede delegar tareas, pero siempre conserva la responsabilidad.

Para tener éxito, toda la organización debe respetar sus decisiones, que se reflejan en el contenido y orden del Product Backlog, y en el Incremento revisable durante el Sprint Review.

El Product Owner es una sola persona, no un comité. Puede representar las necesidades de múltiples partes interesadas, pero cualquier cambio en el Product Backlog debe negociarse con él.

Scrum Master

Es responsable de establecer Scrum según la Guía de Scrum. Ayuda a todos a comprender la teoría y práctica de Scrum, tanto dentro del Scrum Team como en la organización.

También es responsable de la eficacia del Scrum Team, facilitando la mejora de sus prácticas dentro del marco de Scrum.

El Scrum Master es un verdadero líder al servicio del equipo y de la organización. Sirve al Scrum Team de varias maneras, incluyendo:

Entrenamiento en autogestión y multifuncionalidad.
Fomento de la creación de Incrementos de alto valor cumpliendo con la Definición de Hecho.
Eliminación de impedimentos para el progreso del equipo.
Asegurando que los eventos de Scrum se realicen y sean positivos, productivos y dentro del tiempo definido.

También sirve al Product Owner mediante:

Técnicas para definir el Product Goal y gestionar el Product Backlog.
Fomento de ítems del Backlog claros y concisos.
Planificación empírica de productos en entornos complejos.
Facilitación de la colaboración con stakeholders.

Y sirve a la organización mediante:

Liderazgo, entrenamiento y capacitación en la adopción de Scrum.
Planificación y asesoramiento en implementaciones de Scrum.
Promoción del enfoque empírico para trabajos complejos.
Eliminación de barreras entre stakeholders y Scrum Teams.

Eventos de Scrum

El Sprint es el contenedor de todos los demás eventos. Cada evento en Scrum es una oportunidad formal para inspeccionar y adaptar los artefactos de Scrum. Estos eventos están diseñados específicamente para permitir la transparencia necesaria. No realizar estos eventos como se prescribe resulta en oportunidades perdidas para inspeccionar y adaptarse.

Los eventos de Scrum crean regularidad y minimizan la necesidad de reuniones no definidas en el marco.

Idealmente, todos los eventos se realizan en el mismo momento y lugar para reducir la complejidad.

El Sprint

El Sprint es el latido del corazón de Scrum, donde las ideas se transforman en valor.

Tiene una duración fija de un mes o menos, lo que crea consistencia.
Un nuevo Sprint comienza inmediatamente después de que finaliza el anterior.
Incluye todo el trabajo necesario para alcanzar el Product Goal, como: Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective.

Durante el Sprint:

No se hacen cambios que pongan en peligro el Sprint Goal.
La calidad no disminuye.
El Product Backlog se refina según sea necesario.
El alcance puede aclararse y renegociarse con el Product Owner conforme se aprende más.

Los Sprints permiten la previsibilidad al garantizar la inspección y adaptación del progreso hacia el Product Goal al menos una vez al mes.

Si la duración del Sprint es demasiado larga, el Sprint Goal puede volverse inválido, la complejidad puede aumentar y los riesgos también. Usar Sprints más cortos permite más ciclos de aprendizaje y limita el riesgo en periodos de tiempo más pequeños.

Nota: Existen prácticas como burn-downs, burn-ups o flujos acumulativos para pronosticar el progreso. Aunque útiles, no sustituyen el valor del empirismo. En entornos complejos, lo que sucederá es desconocido. Solo lo que ya ha sucedido puede usarse para tomar decisiones futuras.

Un Sprint puede cancelarse si el Sprint Goal se vuelve obsoleto. Solo el Product Owner tiene autoridad para cancelar un Sprint.

Sprint Planning

La planificación del Sprint inicia el Sprint al establecer el trabajo a realizar. El plan resultante se crea mediante la colaboración de todo el Scrum Team.

El Product Owner asegura que los asistentes estén preparados para hablar de los elementos más importantes del Product Backlog y cómo se relacionan con el Product Goal. El equipo puede invitar a otras personas para que brinden asesoramiento.

Sprint Planning responde a tres temas clave:

Tema 1: ¿Por qué este Sprint es valioso?

El Product Owner propone cómo puede aumentar el valor y la utilidad del producto durante el Sprint. Luego, todo el Scrum Team colabora para definir un Sprint Goal que comunique ese valor a las partes interesadas. El Sprint Goal debe definirse antes de terminar la planificación.

Tema 2: ¿Qué se puede hacer en este Sprint?

A través de la conversación con el Product Owner, los Desarrolladores seleccionan elementos del Product Backlog para incluir en el Sprint. Estos elementos pueden refinarse durante la planificación para aumentar comprensión y confianza.

Seleccionar cuánto trabajo puede completarse en un Sprint puede ser difícil. Cuanto más conozcan los Desarrolladores sobre su desempeño pasado, su capacidad y la Definición de Hecho, más seguros estarán en sus pronósticos.

Tema 3: ¿Cómo se hará el trabajo seleccionado?

Para cada elemento seleccionado, los Desarrolladores planifican el trabajo necesario para crear un Incremento que cumpla con la Definición de Hecho. Esto suele hacerse descomponiendo los ítems en tareas más pequeñas (de un día o menos). Solo los Desarrolladores deciden cómo convertir ítems del Product Backlog en Incrementos de valor.

El Sprint Goal, los ítems seleccionados y el plan para entregarlos constituyen el Sprint Backlog.

Tiempo límite: 8 horas para un Sprint de un mes. En Sprints más cortos, la duración es proporcionalmente menor.

Daily Scrum

El propósito del Daily Scrum es inspeccionar el progreso hacia el Sprint Goal y adaptar el Sprint Backlog según sea necesario, ajustando el trabajo planeado para el día siguiente.

Es un evento de 15 minutos realizado por los Desarrolladores.
Se realiza a la misma hora y lugar todos los días del Sprint para reducir la complejidad.
Si el Product Owner o el Scrum Master están trabajando activamente en ítems del Sprint Backlog, participan como Desarrolladores.

Los Desarrolladores pueden usar cualquier estructura o técnica, siempre que el enfoque esté en avanzar hacia el Sprint Goal y generar un plan de acción claro para las siguientes 24 horas.

Daily Scrum mejora la comunicación, identifica impedimentos, promueve la toma de decisiones rápidas y elimina la necesidad de otras reuniones.

Importante: No es el único momento en el que los Desarrolladores pueden ajustar su plan. Pueden reunirse en cualquier momento para adaptarse.

Sprint Review

El objetivo del Sprint Review es inspeccionar los resultados del Sprint y determinar futuras adaptaciones.

El Scrum Team presenta los resultados a stakeholders clave.
Se revisa el avance hacia el Product Goal.

Durante la reunión:

Se revisa lo logrado en el Sprint y cualquier cambio en el entorno.
Con base en esa información, se colabora en qué hacer a continuación.
El Product Backlog puede ajustarse para reflejar nuevas oportunidades.

La Sprint Review es una sesión de trabajo, no solo una presentación.

Tiempo límite: 4 horas máximo para un Sprint de un mes. En Sprints más cortos, se acorta proporcionalmente.

Sprint Retrospective

La Sprint Retrospective tiene como objetivo planificar maneras de aumentar la calidad y la eficacia.

El Scrum Team inspecciona cómo fue el último Sprint respecto a personas, procesos, herramientas y la Definición de Hecho.
Identifican suposiciones erróneas y analizan sus causas.
Se discuten aciertos, problemas y cómo fueron (o no fueron) resueltos.

El equipo identifica los cambios más útiles para mejorar. Las mejoras más relevantes se abordan lo antes posible, incluso pueden añadirse al Sprint Backlog del siguiente Sprint.

Tiempo límite: 3 horas máximo para un Sprint de un mes.

Artefactos de Scrum

Los artefactos de Scrum representan trabajo o valor. Están diseñados para maximizar la transparencia de la información clave, de modo que todos los que los inspeccionen tengan la misma base para adaptarse.

Cada artefacto incluye un compromiso asociado, que garantiza que proporcione foco y claridad para medir el progreso:

Para el Product Backlog, el compromiso es el Product Goal.
Para el Sprint Backlog, el compromiso es el Sprint Goal.
Para el Incremento, el compromiso es la Definición de Hecho (Definition of Done).

Estos compromisos refuerzan el empirismo y los valores de Scrum para el equipo y las partes interesadas.

Product Backlog

El Product Backlog es una lista emergente y ordenada de todo lo necesario para mejorar el producto. Es la única fuente de trabajo que realiza el Scrum Team.

Los ítems del Product Backlog que pueden completarse dentro de un Sprint se consideran listos para su selección durante la planificación. Esta transparencia suele lograrse mediante actividades de refinamiento.

Refinamiento del Backlog: consiste en dividir y definir los ítems en partes más pequeñas y claras. Esta actividad continua incluye agregar detalles como descripción, orden y tamaño. Los atributos varían según el dominio.

Los Desarrolladores son responsables de estimar el tamaño. El Product Owner puede influir ayudando a comprender y elegir compensaciones.

Compromiso: Product Goal

El Product Goal describe un estado futuro del producto que sirve como objetivo a alcanzar por el Scrum Team.

Está incluido en el Product Backlog. El resto del Backlog emerge para definir el “qué” que permitirá cumplir ese objetivo.

Un producto es un vehículo para entregar valor. Tiene límites definidos, stakeholders conocidos y usuarios identificables. Puede ser un servicio, un producto físico o algo más abstracto.

El Product Goal es el objetivo a largo plazo del equipo. Deben cumplir (o abandonar) uno antes de asumir el siguiente.

Sprint Backlog

El Sprint Backlog está compuesto por:

El Sprint Goal (el “por qué” del Sprint),
Los ítems del Product Backlog seleccionados (el “qué”), y
Un plan de acción detallado para entregar el Incremento (el “cómo”).

Es un plan hecho por y para los Desarrolladores. Representa una vista en tiempo real y visible del trabajo planeado para alcanzar el Sprint Goal.

Se actualiza continuamente durante el Sprint a medida que se aprende más.

Debe tener suficiente detalle como para que el equipo pueda inspeccionar su progreso durante el Daily Scrum.

Compromiso: Sprint Goal

El Sprint Goal es el único objetivo del Sprint. Aunque es un compromiso de los Desarrolladores, les da flexibilidad sobre el trabajo exacto necesario para cumplirlo.

Proporciona coherencia y enfoque, fomentando el trabajo en conjunto.

Se define durante el Sprint Planning.
Se añade al Sprint Backlog.
Sirve como guía durante el Sprint.

Si el trabajo cambia, los Desarrolladores colaboran con el Product Owner para negociar el alcance, sin comprometer el Sprint Goal.

Incremento

Un Incremento es un paso concreto hacia el Product Goal. Cada Incremento se suma a los anteriores y se verifica exhaustivamente para asegurar su funcionamiento conjunto.

Para ser valioso, el Incremento debe ser utilizable.

Se pueden crear múltiples Incrementos durante un Sprint. El total se presenta en el Sprint Review, apoyando el empirismo. Sin embargo, un Incremento puede entregarse antes de que el Sprint termine.

La Sprint Review no debe ser vista como una barrera para entregar valor.

Ningún trabajo se considera parte de un Incremento a menos que cumpla con la Definición de Hecho.

Compromiso: Definición de Hecho (Definition of Done)

La Definición de Hecho es una descripción formal del estado del Incremento cuando cumple con los estándares de calidad necesarios para el producto.

En el momento en que un ítem del Product Backlog cumple con la Definición de Hecho, nace un Incremento.

La Definición de Hecho proporciona transparencia al crear una comprensión compartida sobre qué trabajo está completo.

Si un ítem no la cumple, no puede ser entregado ni presentado. Se devuelve al Product Backlog para su consideración futura.
Si es parte de los estándares de la organización, todos los Scrum Teams deben cumplirla.
Si no hay estándar organizacional, el Scrum Team debe crear uno apropiado.

Todos los Desarrolladores deben cumplir con la Definición de Hecho. Si hay múltiples equipos trabajando en un producto, deben acordar una definición común.

Nota final

Scrum es gratuito y se ofrece mediante esta Guía. El marco, como se presenta aquí, es inmutable. Aunque es posible implementar solo algunas partes, eso no es Scrum.

Scrum solo existe en su totalidad y funciona bien como contenedor para otras técnicas, metodologías y prácticas.

Agradecimientos

Personas

De las miles de personas que han contribuido a Scrum, destacamos a quienes estuvieron desde el principio: Jeff Sutherland trabajó con Jeff McKenna y John Scumniotales; Ken Schwaber con Mike Smith y Chris Martin. Todos colaboraron entre sí. Muchos más contribuyeron en los años posteriores.

Historia de la Guía de Scrum

Ken Schwaber y Jeff Sutherland presentaron Scrum por primera vez en la conferencia OOPSLA en 1995. Documentaron el aprendizaje adquirido en años previos y publicaron la primera definición formal de Scrum.

Esta guía documenta Scrum tal como ha sido desarrollado y mantenido durante más de 30 años por Jeff Sutherland y Ken Schwaber. Otras fuentes ofrecen patrones y procesos que complementan el marco, aumentando productividad, valor, creatividad y satisfacción.

Reconocemos como lugares fundacionales: Individual Inc., Newspage, Fidelity Investments e IDX (ahora GE Medical).