CHAPTER 3

Scrum: Una Pequeña

Introducción

3.1 Introducción
Scrum, sin lugar a dudas, es el paradigma más destacado entre los modelos
de procesos ágiles. Desarrollado a fines de los años 90 por Ken Schwaber, se
destaca por su enfoque iterativo e incremental que promueve la flexibilidad y
la colaboración en el desarrollo de software.
La esencia de Scrum puede ser comprendida a través de los siguientes puntos
clave:

• El desarrollo de software se lleva a cabo en ciclos repetitivos llamados

“sprints”, que representan períodos de tiempo específicos.
• Cada sprint agrega un incremento de funcionalidad al producto y gen-
era un resultado “potencialmente entregable”, es decir, un incremento
de software funcional.
• El contenido del sprint se define en gran medida mediante una nego-
ciación activa con el representante del cliente, conocido como “prod-
uct owner”.
• Al concluir cada sprint, se realizan dos reuniones esenciales antes de
embarcarse en el siguiente ciclo:
• La reunión de “review”, que implica evaluar y presentar lo que se ha
logrado durante el sprint, así como identificar lo que aún debe abor-
darse.
• La “retrospectiva”, una sesión reflexiva en la que el equipo analiza y
discute cómo funcionó el proceso durante el sprint anterior y cómo se
pueden realizar mejoras.

16
 3.2 Solo 3 roles

Figure 3-1 Ilustración: Scrum

Scrum se caracteriza por su estructura organizativa y sus roles bien

definidos, que incluyen al “product owner”, el equipo de desarrollo y el
“Scrum Master”, quien actúa como facilitador y defensor del proceso. A
través de estos roles y prácticas, Scrum fomenta la transparencia, la adapt-
abilidad y la colaboración continua, permitiendo que los equipos entreguen
resultados de alta calidad en ciclos cortos y controlados.
A pesar de sus numerosas ventajas, implementar Scrum de manera efec-
tiva requiere una comprensión sólida de sus principios y prácticas, así como
una comunicación abierta y una colaboración constante entre los miembros
del equipo y los stakeholders. En última instancia, Scrum ofrece un marco
poderoso para el desarrollo de software ágil, alineado con los valores y prin-
cipios fundamentales de la metodología ágil.

3.2 Solo 3 roles

En este modelo de proceso solo existen 3 roles distintos:
• Product Owner. Este rol asume la responsabilidad total del producto,
lo que incluye su éxito o fracaso en el proyecto. El Product Owner es
el encargado de tomar decisiones clave sobre el producto y trabaja en
estrecha colaboración con los stakeholders para identificar y priorizar
las características esenciales que se incorporarán. Su enfoque se centra
en garantizar que el equipo esté construyendo el producto adecuado y
que las necesidades del cliente se satisfagan plenamente.
• Scrum Master. El Scrum Master desempeña un papel multifacético
como coach y líder del proceso. Su función principal es facilitar y guiar
al equipo en la implementación efectiva de Scrum. Actúa como un fa-
cilitador que remueve obstáculos y promueve un ambiente propicio
para la colaboración y la mejora continua. Además, el Scrum Mas-
ter asume la responsabilidad de resolver problemas y asegurar que
el equipo siga las prácticas y los principios de Scrum de manera ade-
cuada.
• Team. El núcleo del proceso recae en el equipo de desarrollo, el cual
está compuesto por individuos altamente colaborativos y con habili-

17
 Scrum: Una Pequeña Introducción

dades diversas. Los equipos en Scrum son autónomos y autogestion-

ados, y típicamente constan de 5 a 8 personas. Estos equipos cross-
funcionales tienen la capacidad de planificar, diseñar, implementar y
probar las características del producto. Trabajan de manera colabora-
tiva, promoviendo la comunicación abierta y la responsabilidad com-
partida para alcanzar los objetivos del sprint.

3.3 El Importantísimo Product Owner

El Product Owner generalmente desempeña un papel clave en el proyecto,
siendo un líder de usuarios que posee un profundo conocimiento sobre los
usuarios, el mercado y las tendencias relevantes para el dominio en cuestión.
Este rol requiere disponibilidad, experiencia en el negocio y un compromiso
sólido con el proyecto.
La figura del Product Owner debe tener una visión clara de los objetivos del
proyecto y ser capaz de comunicar eficazmente esa visión al equipo. Su re-
sponsabilidad principal radica en la priorización del backlog del producto,
aunque no decide la cantidad de trabajo que se aborda en cada sprint.
El Product Owner asume la responsabilidad final del proyecto, desem-
peñando diversos roles clave. Como comunicador, el Product Owner informa
a los interesados sobre el progreso del proyecto y se involucra en negocia-
ciones con los stakeholders, colaborando con ellos para definir y establecer
el valor que será entregado. Además, fomenta la creación de conocimiento
compartido y se mantiene accesible para el equipo en todo momento.
También desempeña un papel activo en los eventos del equipo, participando
activamente en ellos.
En su función como planificador, el Product Owner diseña y planifica los
sprints, buscando maximizar el valor de los releases. Asimismo, establece
prioridades en el backlog y toma decisiones fundamentales para el avance y
el éxito del proyecto.
Como visionario, el Product Owner posee una visión clara y precisa de los
requisitos y objetivos del proyecto. Promueve esta visión ante la organi-
zación y se esfuerza por definir metas claras y alcanzables que guíen el de-
sarrollo del software.
En su rol de experto, el Product Owner demuestra un profundo conocimiento
del ámbito del proyecto. Goza de respeto y reconocimiento en toda la orga-
nización, desempeñando también el papel de representante del negocio en el
proceso de desarrollo.
Finalmente, como miembro valioso del equipo (Team player), el Product
Owner motiva al equipo estableciendo metas concretas y comprensibles.
Además, suministra al equipo la información necesaria para que pueda en-

18
 3.4 El Scrum Master no es el Jefe de Proyecto

tregar valor de manera efectiva y eficiente. Su colaboración y participación

son fundamentales para el éxito general del proyecto.

3.4 El Scrum Master no es el Jefe de Proyecto

El Scrum Master tiene la responsabilidad primordial de respaldar y fomentar
el proceso Scrum en todas sus dimensiones: teoría, prácticas, reglas y val-
ores. Su alcance de acción no se limita solo al equipo de desarrollo, sino que
también se extiende al Product Owner y a la organización en su conjunto.
Sus funciones clave abarcan:

• Ofrecer apoyo al equipo de desarrollo mediante el ejercicio de coach-

ing en la autorganización y la multifuncionalidad. Además, se encarga
de eliminar obstáculos que puedan dificultar el avance del equipo y
brindar orientación para la creación de productos de alto valor.
• Brindar soporte al Product Owner en diversos aspectos, como asegu-
rarse de que todos comprendan las metas establecidas, sugerir técnicas
para la gestión eficiente del backlog y garantizar que las prioridades
del backlog sean adecuadamente establecidas.
• Contribuir al éxito organizacional al acelerar la adopción de procesos
ágiles en la organización. Esto implica planificar y supervisar la imple-
mentación del modelo Scrum en la estructura organizativa, así como
proporcionar orientación a los empleados y partes interesadas sobre
cómo llevar a cabo procesos con Scrum de manera efectiva.

3.5 Actividades y Artefactos

La siguiente gráfica sintetiza todas las actividades y los artefactos involucra-
dos en un proceso Scrum.
A continuación se describen brevemente cada una de las actividades en el
marco de Scrum:

• Sprint: Es un período de tiempo fijo y corto en el que se lleva a cabo

el trabajo de desarrollo. Durante el sprint, se crea un incremento del
producto potencialmente entregable que agrega valor al producto en
desarrollo.
• Sprint Planning: Es una reunión al comienzo de cada sprint donde el
equipo de desarrollo y el Product Owner colaboran para definir qué
elementos del backlog se trabajarán durante el sprint y cómo se llevará
a cabo el trabajo.
• Daily Scrum: Una reunión diaria de corta duración en la que el equipo
de desarrollo sincroniza sus actividades, revisa el progreso y discute
cualquier obstáculo que pueda estar afectando su avance.

19
 Scrum: Una Pequeña Introducción

• Sprint Execution: Durante esta actividad, el equipo de desarrollo tra-

baja en la implementación de las tareas definidas en el backlog durante
el sprint planificado.
• Sprint Review: Al final de cada sprint, se lleva a cabo una reunión
para demostrar y revisar el incremento del producto desarrollado. Los
stakeholders proporcionan retroalimentación y se identifican posibles
ajustes para el backlog.
• Sprint Retrospective: Otra reunión al final del sprint en la que el
equipo de desarrollo reflexiona sobre el proceso, identifica lo que
funcionó bien y las áreas de mejora, y ajusta su enfoque para futuros
sprints.
• Add/Take from Product Backlog: Durante cualquier momento, el
Product Owner puede agregar nuevos elementos o ajustar los elemen-
tos existentes en el backlog del producto, en función de las necesidades
cambiantes del proyecto y la retroalimentación recibida.

Estas actividades en conjunto forman la estructura esencial de Scrum, per-

mitiendo la entrega incremental y continua de valor mientras se adapta y
mejora el proceso a lo largo del tiempo.
A continuación una breve descripción de cada uno de los artefactos en
Scrum:

• Product Backlog: Es una lista priorizada de todas las funcionalidades,

requisitos, mejoras y correcciones que se planea desarrollar en el pro-
ducto a lo largo del tiempo. Se mantiene y actualiza constantemente
para reflejar las necesidades cambiantes del proyecto y proporciona
una visión general de alto nivel de los elementos a ser trabajados. Esta
lista está constantemente siendo revisada y priorízala por el product
owner.
• Sprint Backlog: Despues de seleccionar los elementos del Product
Backlog que se han comprometido a ser desarrollados durante un
sprint específico. Contiene tareas más detalladas y estimadas que el
equipo de desarrollo debe completar durante el sprint para cumplir
con los objetivos establecidos. Recordemos que una vez iniciado el
sprint no se pueden agregar ni quitar nuevas tareas.
• Potentially Shippable Product: Al final de cada sprint, el equipo de
desarrollo entrega un incremento de producto potencialmente entre-
gable. Esto significa que el incremento contiene todas las funcional-
idades completas y probadas que podrían ser entregadas al cliente si
fuera necesario, aunque la decisión de hacerlo depende del Product
Owner.

20
 3.6 El Sprint

3.6 El Sprint
El sprint es una iteración, típicamente de dos a cuatro semanas de duración.
Todas las iteraciones en Scrum son del mismo largo. Lo importante es que al
final del sprint debe haberse creado algo de valor para el cliente y por eso es
fundamental el rol de product owner.

• Planeación del Sprint. Es la etapa inicial antes de comenzar la ejecu-

ción. Comienza con la selección de relatos o funcionalidades que serán
desarrolladas. Esto lo hace el equipo de desarrollo a partir del backlog
del producto priorizado por el product owner. Estas prestaciones son
divididas en tareas más pequeñas para poder hacer estimaciones de
tiempo y esfuerzo y se asignan a los miembros del equipo disponibles.
• Ejecución del Sprint. Corresponde a la ejecución de las tareas en el
orden que el equipo decida. Nadie le dice al equipo cómo llevar a cabo
las tareas y no existen cosas “casi hechas”, está hecha o no está hecha.
Siempre está el Scrum Master a mano para guías y consultas sobre el
proceso.
• El Daily Meeting. Es una reunión de pié cada día temprano de 15 - 20
minutos. Los miembros del equipo indican que hicieron desde ayer,
que pretendo hacer hoy y posibles obstáculos visibles. Puede decidirse
que temporalmente una persona apoye a alguien que está teniendo
problemas o cambios en los equipos. No es momento de resolver prob-
lemas
• El Sprint Review. Esta reunión es muy importante, porque permite in-
speccionar y adaptar el producto a medida que transcurren las itera-
ciones. La conversación incluye al equipo, a los interesados, a spon-
sors, y a clientes y representa una gran oportunidad para que equipo
adquiera feedback de la gente relacionada con el negocio.
De esta reunión puede surgir la necesidad de repriorizar el backlog del
producto o incluso agregar o eliminar algunas tareas.
• El Sprint Retrospective. La segunda reunión del final de sprint. A difer-
encia del Sprint Review, esta está orientada a reflexionar y ver formas
de mejorar el proceso. Permite revisar en forma crítica el proceso y
como funcionó en el sprint reciente para ver posibles formas de pulir
los ripios, eliminar conflictos y mejorar así el proceso dentro de los
principios á[Link] principalmente el Scrum Master y los miem-
bros del equipo de desarrollo, pero no es raro que se una el product
owner en algunos casos.

3.7 Scrum y Principios Ágiles

Scrum responde a los principios ágiles al

• Abrazar la variabilidad: En lugar de tratar de eliminar por completo

la incertidumbre y la variabilidad, los enfoques ágiles reconocen que el

21
 Scrum: Una Pequeña Introducción

cambio y la adaptación son inevitables en el desarrollo de software. En

lugar de resistir la variabilidad, los equipos ágiles la abrazan y la incor-
poran en su enfoque, permitiendo una mayor flexibilidad y capacidad
de respuesta a medida que surgen nuevos desafíos y requisitos.
• Desarrollar en forma iterativa e incremental: En lugar de tratar de
completar todo el desarrollo de una vez, los métodos ágiles fomentan
la construcción del producto en pequeños incrementos funcionales
a lo largo de iteraciones periódicas. Esto permite obtener retroali-
mentación temprana, ajustar el enfoque según sea necesario y entre-
gar valor de manera continua en lugar de esperar hasta que todo esté
terminado.
• Inspeccionar y adaptar constantemente: Los equipos ágiles se com-
prometen a una mejora continua mediante la revisión constante de
su trabajo y procesos. Inspeccionan su progreso, identifican áreas de
mejora y ajustan su enfoque para optimizar la eficiencia y la calidad del
producto.
• Fomentar la transparencia (todos saben lo que está pasando): La
transparencia es fundamental en los métodos ágiles. Todos los aspectos
del trabajo, desde el progreso del proyecto hasta los desafíos y prob-
lemas, se comparten de manera abierta y accesible. Esto fomenta la
confianza, la colaboración y la toma de decisiones informadas en todos
los niveles, lo que contribuye a un ambiente de trabajo más efectivo y a
la alineación en los objetivos del proyecto.
• Reducir las incertezas: Los enfoques ágiles buscan reducir las incer-
tidumbres y los riesgos al abordar el desarrollo en pasos pequeños y
manejables. Al construir de manera incremental y obtener retroali-
mentación temprana, los equipos pueden abordar y resolver problemas
a medida que surgen, en lugar de esperar a que se conviertan en ob-
stáculos insuperables.

3.8 Ejercicios
Preguntas de verdadero o falso:

• Scrum es un modelo de proceso ágil desarrollado por Ken Schwaber a

fines de los años 90.
• En Scrum, los sprints son períodos de tiempo fijos y cortos en los que se
lleva a cabo el trabajo de desarrollo.
• Durante un sprint, se crea un incremento de funcionalidad potencial-
mente entregable.
• El product owner es responsable de priorizar el backlog del producto y
decide cuánto trabajo se aborda en cada sprint.
• La reunión de sprint review implica evaluar y presentar lo que se ha
logrado durante el sprint y definir el valor que falta.

22
3.8 Ejercicios

• El Scrum Master es el líder del equipo de desarrollo y tiene la respons-

abilidad total del producto.
• El Scrum Master elimina obstáculos y promueve un ambiente propicio
para la colaboración y la mejora continua.
• El sprint backlog contiene tareas detalladas y estimadas que el equipo
debe completar durante el sprint.
• El sprint execution es la fase en la que se planifica qué elementos del
backlog se trabajarán durante el sprint.
• En Scrum, el Product Owner es responsable de hacer coaching en au-
toorganización y multifuncionalidad al equipo de desarrollo.

Preguntas abiertas de reflexión:

• ¿Cómo contribuye Scrum a la flexibilidad y la colaboración en el desar-

rollo de software?
• ¿Cuál es el papel y la importancia del Product Owner en el proceso
Scrum?
• ¿Cómo se diferencia el rol del Scrum Master del rol de un jefe de
proyecto tradicional?
• ¿Por qué es esencial la inspección y adaptación constante en Scrum?
• ¿Cómo promueve Scrum la transparencia en todas las etapas del desar-
rollo?

23