U2 – Scrum

Definición: Es un framework que ayuda a las personas, equipos y organizaciones a generar

valor a través de soluciones adaptativas para problemas complejos. Me permite desarrollar
productos en un ambiente de alta incertidumbre.

Scrum requiere de un Scrum Master (SM) para fomentar un entorno donde:

1. Un Product Owner (PO) ordena el trabajo de un problema complejo en un Product

Backlog
2. El Scrum Team convierte una selección del trabajo en un Increment de valor durante
un Sprint.
3. El Scrum Team y sus interesados inspeccionan los resultados y se adaptan para el
próximo Sprint
4. Repetir

Es un framework incompleto de manera intencional, solo define las partes necesarias para
implementar la teoría de Scrum. En lugar de proporcionar instrucciones detalladas a las
personas, las reglas de Scrum guían sus relaciones e interacciones.

Teoría de Scrum

Se basa en el empirismo y en el pensamiento Lean. El empirismo afirma que el conocimiento

proviene de la experiencia y de la toma de decisiones con base en lo observado.

El pensamiento Lean reduce el desperdicio y se enfoca en lo esencial (lo que agrega valor).

Scrum emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar el

riesgo. Scrum involucra a grupos de personas que colectivamente tienen todas las habilidades
y experiencia para hacer el trabajo y compartir/adquirir dichas habilidades según sea
necesario.

Scrum combina cuatro eventos o ceremonias dentro de un evento contenedor, el Sprint. Estos
eventos funcionan porque implementan los pilares empíricos de Scrum

Pilares Empíricos

Transparencia: El proceso y el trabajo debe ser visible tanto para quienes realizan el trabajo
como para quienes los reciben. La transparencia es en dos ámbitos, primero sería en el estado
del equipo, y la segunda es en FALTA. Con Scrum todas las decisiones importantes se toman en
base al estado percibido de sus artefactos, si estos tienen poca transparencia, se pueden
tomar decisiones que disminuyan el valor y aumenten el riesgo.

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

Inspección: Los artefactos de Scrum y el progreso hacia los objetivos acordados deben
inspeccionarse con frecuencia para detectar variaciones o problemas. Para ayudar con la
inspección existen los eventos de Scrum.

La inspección permite la adaptación. La inspección sin adaptación es inútil. Los eventos de

Scrum están diseñados para provocar cambios

Adaptación: Si algún aspecto del proceso se desvía fuera de los límites aceptables, o si el
producto resultante es inaceptable, el proceso se debe ajustar. El ajuste se debe realizar lo
antes posible para minimizar una mayor desviación.
La adaptación se vuelve más difícil cuando las personas no están empoderadas ni se
autogestionan. Se espera que el Scrum Team se adapta en el momento en que aprenda algo
nuevo a través de la inspección.

Valores de Scrum

El éxito de Scrum depende de que las personas posean 5 valores:

 Compromiso: El Scrum Team se compromete a lograr sus objetivos y apoyarse

mutuamente.
 Foco: El foco principal del Scrum Team está en el trabajo del Sprint para lograr el mejor
progreso posible hacia estos objetivos.
 Franqueza: El Scrum Team y sus interesados son francos sobre el trabajo y los desafíos.
 Respeto: Los miembros del Scrum Team se respetan entre sí para ser personas capaces
e independientes, y son respectados como tales por las personas con las que trabajan
 Coraje: El Scrum Team tiene el coraje de hacer lo correcto, para trabajar en problemas
difíciles.

Estos valores dan dirección al Scrum Team con respecto a su trabajo, acciones y
comportamiento. Los miembros del Scrum Team aprenden y exploran los valores mientras
trabajan con los eventos y artefactos Scrum.

El Scrum Team

Es la unidad fundamental de Scrum. Consta de un Scrum Master, un Product Owner y

Developers. Dentro del equipo no hay subequipos ni jerarquías. Los Scrum Teams son
multifuncionales, es decir, los miembros tienen todas las habilidades necesarias para crear
valor en cada sprint. También se autogestionan, deciden internamente quién hace qué,
cuándo y cómo.

Es una unidad cohesionada de profesionales enfocados en un objetivo a la vez, el objetivo el

producto. Debe ser lo suficientemente pequeño como para ser ágil y lo suficientemente
grande como para completar el trabajo dentro del sprint (10 personas o menos).

Los equipos más pequeños se comunican mejor y son más productivos. Si los Scrum Teams se
vuelven demasiado grandes, deberían considerar reorganizarse en múltiples equipos
cohesivos, enfocados en el mismo producto. (Deben comportar el mismo objetivo del
producto, el producto backlog y el PO).

El Scrum Team es responsable de todas las actividades relacionadas con el producto

(colaboración de los interesados, la verificación, mantenimiento, operación, experimentación,
investigación y desarrollo). Están estructurados y empoderados por la organización para
gestionar su propio trabajo. Todo el equipo es responsable de crear un Increment valioso y útil
en cada Sprint

Developers: Son las personas del equipo que se comprometen a crear cualquier aspecto de un
Increment utilizable en cada Sprint. Las habilidades que necesitan son amplias y dependen del
ámbito de trabajo. Responsabilidades:

 Crear un plan para el Sprint, es decir, el Sprint Backlog

 Introducir calidad al adherirse a un DoD (Definition of Done)
 Adaptar su plan de cada día hacia el objetivo del Sprint.
 Responsabilizarse mutuamente como profesionales
Product Owner: Es responsable de maximizar el valor del producto resultante del trabajo del
equipo. El PO también es responsable de la gestión efectiva del Product Backlog, incluye:

 Desarrollar y comunicar explícitamente el objetivo del producto.

 Crear y comunicar claramente los elementos del Product Backlog.
 Ordenar los elementos del Product Backlog.
 Asegurarse que el Product Backlog sea transparente, visible y se entienda.

El PO puede realizar dicho trabajo o delegar la responsabilidad en otros. Independientemente

de ello, el PO sigue siendo responsable de que el trabajo se realice. Para que el PO tenga éxito,
toda la organización debe respetar sus decisiones. Dichas decisiones son visibles en el
contenido y el orden del Product Backlog, y se inspeccionan a través del Increment en el Sprint
Review.

El PO es una persona, aunque puede representar las necesidades de muchos interesados en el

PB. Si se quiere cambiar el PB, se debe hablar primero con el PO.

Scrum Master: Es el responsable de establecer Scrum tal cual lo define la guía. Ayuda a todos a
comprender la teoría y la práctica de Scrum, tanto en el Scrum Team como en la organización.
Es el responsable de lograr la efectividad del Scrum Team, y lo hace apoyándolo en la mejora
de sus prácticas, dentro del marco de trabajo de Scrum.

El Scrum Master sirve al Scrum Team de la siguiente manera:

 Guiar a los miembros del equipo en ser autogestionados y multifuncionales

 Ayudar al Scrum Team a enfocarse en crear Increments de alto valor que cumplan con
la DoD.
 Procurar la eliminación de impedimentos para el progreso del equipo.
 Asegurarse que todos los eventos de Scrum se lleven a cabo y sean positivos,
productivos y se mantengan dentro de los límites de tiempo.

El Scrum Master sirve al PO de varias maneras:

 Ayudar a encontrar técnicas para una definición efectiva de los objetivos del producto
y la gestión del producto backlog.
 Ayudar al equipo a comprender la necesidad de tener elementos del producto backlog
claros y concisos.
 Ayudar a establecer una planificación empírica de productos para un entorno complejo
 Facilitar la colaboración de los interesados según se solicite o necesite.

El Scrum Master sirve a la organización de varias maneras:

 Liderar, capacitar y guiar a la organización en su adopción de Scrum.

 Planificar y asesorar implementaciones de Scrum dentro de la organización.
 Ayudar a los empleados y los interesados a comprender y aplicar un enfoque empírico
para el trabajo complejo.
 Eliminar las barreras entre los interesados y los Scrum Team.

Eventos de Scrum
El Sprint es un contenedor para todos los demás eventos. Cada evento en Scrum es una
oportunidad formal para inspeccionar y adaptar los artefactos. Esos eventos están diseñados
específicamente para habilitar la transparencia requerida.

No operar cualquier evento según lo establecido resulta en la pérdida de oportunidades para

inspeccionar y adaptarse. Los eventos se utilizan para minimizar la necesidad de reuniones no
definidas en Scrum.

Sprint: Son el corazón de Scrum, donde las ideas se convierten en valor. Tienen una duración
fija de un mes o menos para crear consistencia. Un nuevo Sprint comienza inmediatamente
después de la conclusión del Sprint anterior. Todo el trabajo necesario para lograr el objetivo
del producto, incluido los otros eventos de Scrum, ocurren dentro del Sprint.

Durante el sprint no se realizan cambios que pongan en peligro el objetivo del sprint, la calidad
no disminuye, se refina el Product Backlog según lo necesario, y el alcance se puede aclarar y
renegociar con el PO a medida que se aprende más. (No se agregan nuevas características si el
equipo terminó con todo lo que debían hacer antes de tiempo)

Los Sprint permiten previsibilidad al garantizar inspección y adaptación del progreso hacia el
objetivo del producto, al menos cada mes. Puede llegar a ocurrir que el objetivo del Sprint se
vuelva inválido, la complejidad puede crecer y el riesgo aumentar, y se puede llegar a cancelar
un Sprint. Solo el PO tiene la autoridad para esto

Los Sprint más cortos permiten generar más ciclos de aprendizaje, limitar el riesgo de costo y
esfuerzo.
Existen varias prácticas para pronosticar el progreso, como el trabajo pendiente (burn-downs
chart), el trabajo completado (burn-up chart) o flujos acumulativos. Si bien son de utilidad, no
reemplazan la importancia del empirismo. En entornos complejos se desconoce lo que
sucederá, solo lo que ya ha sucedido se puede emplear para la toma de decisiones.

Sprint Planning: Inicia el Sprint al establecer el trabajo que se realizará para el Sprint. El PO se
asegura de que los asistentes estén preparados para discutir los elementos más importantes
del Product Backlog, y cómo se relacionan con el objetivo del Producto. Se puede invitar a
terceros para brindar asesoramiento. Se tratan tres temas:

¿Por qué es valioso este Sprint? El PO propone como el producto podría incrementar su valor y
utilidad en el Sprint actual. Luego todo el equipo colabora para definir un Objetivo del Sprint, y
establece por qué el sprint es valioso. El objetivo debe completarse antes que termine el sprint
planning.

¿Qué se puede hacer en este Sprint? A través de una conversación con el PO, los developers
seleccionan elementos del Product Backlog para incluirlos en el Sprint actual. El Scrum Team
puede refinar estos elementos durante el proceso. Es complicado seleccionar cuánto se puede
completar dentro de un Sprint, sin embargo, cuanto más sepan los developers sobre su
desempeño pasado, su capacidad actual y su DoR, mejor será el pronóstico. Al Sprint solo
entran US que cumplan con el DoR

¿Cómo se realizará el trabajo elegido? Para cada elemento del PB seleccionado, los Developers
planifican el trabajo necesario para crear un Increment que cumpla con la DoD. Se suele hacer
descomponiendo los elementos del PB en elementos de trabajo más pequeños. La forma de
hacerlo queda a criterio de los Developers, ellos deciden como convertir los elementos del PB
en Incremens de valor.
El Objetivo del Sprint, los elementos del PB seleccionados para el Sprint, más el plan para
entregarlos se denominan Sprint Backlog.

La Sprint Planning tiene un límite máximo de 8 horas para un Sprint de un mes. Participan
todos los miembros del Scrum Team

Daily Scrum: El propósito de la misma es sincronizar el trabajo de los Developers y dar

visibilidad. Me permite inspeccionar el progreso hacia el objetivo del Sprint y adaptar el Sprint
Backlog según sea necesario. Es un evento de 15 minutos para los Developers del equipo, y se
suele llevar a cabo a la misma hora y lugar todos los días hábiles. Si el PO o el SM están
trabajando sobre elementos del Sprint Backlog, deben participar como Developers (si no
tienen afectado trabajo, no es necesario que estén).

Los Developers pueden seleccionar la estructura y ténica que deseen, siempre que la Daily se
centre en el progreso hacia el objetivo del sprint y produzca un plan viable para el siguiente día
de trabajo.

Las Daily mejoran la comunicación, identifican impedimentos y promueven la toma rápida de

decisiones.

Sprint Review: Se inspecciona el resultado del Sprint y determinan futuras adaptaciones. El

equipo presenta los resultados de su trabajo a los interesados y se discute el progreso hacia el
objetivo del Producto. Busca obtener feedback, se inspecciona el producto, es lo que quiero
validar.

Se revisa lo que se logró en el Sprint. El PB también se puede ajustar según las necesidades.
Tiene una duración máxima de 4 horas para un sprint de 1 mes. Participa todo el equipo.

Sprint Retrospective: Me permite planificar formas de aumentar la calidad y efectividad. El

Scrum Team inspecciona (y luego adapta) como fue el último Sprint con respecto a los
procesos, las herramientas y su DoD. Se identifican los supuestos que los llevaron por el mal
camino y se exploran sus orígenes. El Scrum Team analiza qué salió bien durante el Sprint, qué
problemas encontró y cómo se resolvieron (o no) esos problemas.

Identifica los cambios más útiles para mejorar su efectividad. Las mejoras impactantes se
abordan lo antes posible. El Sprint Retrospective concluye el Sprint, y tiene un tiempo limitado
máximo de tres horas para un Sprint de un mes. El PO no es necesario que esté, pero puede
ser invitado.

Product Backlog Refinement: No es una ceremonia definida como obligatoria por parte de la
guía de Scrum, pero en la vida real es sumamente importante. También denominada Story
Time, el Scrum Team se junta para refinar el PB, por lo que se puede decir que se trabaja sobre
el producto. El propósito de la misma es configurar el product backlog, se parte de una visión y
empezamos a identificar US, épicas, temas.

Se reserva un 10% del tiempo del Sprint para esta ceremonia, y se ejecuta On Demand,
siempre que sea necesaria. El PO obligatoriamente debe estar presente, junto con los terceros
que este desee convocar. El SM puede o no estar (generalmente en las primeras iteraciones no
está). Y los developers pueden o no estar, y puede que no estén todos.

Artefactos de Scrum
Representan el trabajo o valor. Están diseñados para maximizar la transparencia de la
información. Cada artefacto tiene un compromiso para garantizar que proporcione
información que mejore la transparencia y el enfoque frente al cual se puede medir el
progreso.

 Para el Product Backlog, el compromiso es el Objetivo del Producto.

 Para el Sprint Backlog, el compromiso es el Objetivo del Sprint.
 Para el Increment (versión del producto), el compromiso es la DoD

Product Backlog: Es una lista emergente y ordenada de lo que se necesita para mejorar el
producto. Es la única fuente del trabajo realizado por el Scrum Team. Los elementos del
Product Backlog que el Scrum Team pueda dar por terminados dentro de un Sprint se
consideran preparados para ser seleccionados en un evento de Sprint Planning.

El refinamiento del Product Backlog es el acto de dividir y definir aún más los elementos del PB
en elementos más pequeños y precisos. Los Developers que realizan el trabajo son los
responsables de dimensionarlo. El PO puede influir en esto ayudando a entender y seleccionar
las mejores alternativas.

El PO es el dueño del Product Backlog y puede agregar, quitar ítems o refinarlo. El Product
Backlog debe tener al principio lo mínimo y suficiente como para ejecutar un sprint.

Compromiso: El objetivo del producto describe un estado futuro del producto que puede servir
como un objetivo para que el Scrum Team planifique. El objetivo del producto está en el
producto backlog. El resto del PB emerge para definir “qué” cumplirá con el objetivo del
producto. El objetivo del producto es el objetivo a largo plazo del Scrum Team.

Sprint Backlog: Se compone del objetivo del Sprint (por qué), el conjunto de elementos del PB
seleccionados para el Sprint (qué), y un plan de acción para entregar el Increment (cómo).

Es el plan realizado por y para los Developers. Es una imagen visible y en tiempo real del
trabajo que los Developers planean realizar durante el Sprint para cumplir con el Objetivo del
Sprint. El Sprint Backlog se actualiza a lo largo del Sprint a medida que se aprende más.

Compromiso: El objetivo del Sprint es el único propósito del Sprint. Si bien dicho objetivo es un
compromiso de los Developers, proporciona flexibilidad en términos del trabajo necesario para
lograrlo. El objetivo del Sprint crea coherencia y enfoque.

El objetivo del Sprint se crea durante el Sprint Planning y se agrega al Sprint Backlog. Mientras
los Developers trabajan durante el Sprint, tienen en mente el Objetivo del Sprint. Si el trabajo
es diferente de lo que esperaban, colaboran con el PO para negociar el alcance del Sprint
Backlog dentro del Sprint, sin afectar el objetivo del Sprint.

Increment: Es un peldaño concreto hacia el objetivo del producto. Cada Increment se suma a
todos los Increment anteriores y se verifica minuciosamente, lo que garantiza que todos los
Increments funcionen juntos. Debe ser utilizable, para poder proporcionar valor.

Se pueden crear múltiples Increments dentro de un Sprint. La suma de los mismos se presenta
en la Sprint Review, permitiendo el empirismo. Se puede entregar un Increment a los
interesados antes del final de un Sprint. El trabajo no puede considerarse parte de un
Increment a menos que cumpla con la DoD.
Compromiso: La Definición de Terminado (DoD) es una descripcion formal del estado del
Increment cuando cumple con las medidas de calidad requeridas para el producto. En el
momento en que un elemento del PB cumple con la DoD, nace un Increment.

Me permite crear transparencia al brindar a todos un entendimiento compartido de qué

trabajo se completó como parte del Increment. Si un elemento del PB no cumple con la DoD,
no se puede presentar en la Sprint Review, en su lugar, vuelve al PB.

Algunos Conceptos adicionales de Scrum

Timebox: Definimos de antemano la duración de las ceremonias y la respetamos.

Capacidad total del sprint: Está dada por el tiempo necesario para las ceremonias,
compromisos externso que puedan surgir, tiempo lbire del personal, capacidad de trabajo en
los ítems del PB y un buffer. La capacidad se usa para estimar cuántas US se pueden incluir en
el Sprint Actual. Es la cantidad de trabajo a la que se puede comprometer el equipo en un
determinado Sprint.

Los equipos mas maduros estiman la capacidad en Story Points, mientras que en equipos
menos maduros se usan las horas ideales, de trabajo puro. Ya que, aunque trabajen 8 horas
por día, el tiempo que realmente pasan trabajando es siempre menos.