TEMA 4.

SCRUM: OVERVIEW
4.1. Introducción y objetivos

Introducción a Scrum

Una vez adquirido una visión global sobre Agile Management vamos a entrar a definir conceptos
como Scrum, roles asociados, ceremonias y artefactos como herramientas de uso.

El enfoque de Agile versus cascada ha mostrado los beneficios de esta forma de trabajo, así como
la mejora exponencial en muchos de los procesos. En este tema se va a proporcionar una visión
global de Scrum en la que destacarán valores como la colaboración y la multidisciplinariedad en
los equipos de trabajo.

De la misma forma, se detallarán los objetivos que se pretenden conseguir:

 Entender qué es la metodología Scrum y el marco donde se encuentra.

 Conocer y entender los diferentes roles que existen en los grupos de trabajo, así como las
responsabilidades de cada uno y las funciones que desempeñan.

 Conocer y entender qué son las ceremonias, su utilización e importancia dentro de los
equipos.

 Conocer y comprender los diferentes artefactos que generan mayor eficiencia en el

trabajo de los equipos que trabajan en Scrum.

4.2. ¿Qué es SCRUM?

El término Scrum proviene de un término francés que hace referencia a la formación de rugby
llamado Melé. El equipo se posiciona de tal manera que todos empujan hacia la misma dirección.

Figura 9. Melé de Rugby. Fuente: Unsplash

Según su creador Jeff Sutherland, Scrum es la aplicación práctica de los principios ágiles, lo que
permite a las compañías lograr el doble de éxito en la mitad de tiempo (Marina, 2019).

Si hablamos de Scrum en términos generales podemos decir que es un marco metodológico fácil
de entender, ligero y muy difícil de llegar a conocer totalmente. Cuando se creó esta
metodología se basó en la necesidad de gestionar el desarrollo de productos complejos en los
años 90. Scrum muestra la eficacia relativa a estas prácticas (Schwaber y Sutherland, 2013).

El marco de trabajo está compuesto por los equipos, roles, artefactos, ceremonias y reglas para
que todos los anteriores encajen a la perfección. Se basa en la teoría de control de los procesos
empíricos, es decir, el conocimiento procede de la experiencia y de tomar decisiones basándose
en lo que se conoce, de esta manera el foco se fija en ser iterativo e incremental y de esta manera
optimiza su valor predictivo y el control del riesgo.

Existen tres pilares sobre los que se asienta Scrum:

 Transparencia: una de las características más importantes de la metodología. Todo debe

ser compartido y tener un lenguaje común. Para ello debemos compartir terminología, así
como tener en cuenta las necesidades reales del receptor del producto.

 Inspección: los equipos Scrum tienen que revisar en los artefactos y el progreso del
proyecto, para detectar posibles acciones sujetas de cambio, así como las mejoras a
realizar en todo el proceso.

 Adaptación: los cambios se sucederán de forma constante, y hay que ser flexible, y ajustar
cuanto antes para minimizar los errores. Estos ajustes se visibilizan a lo largo del proceso,
pero se destacan cuatro momentos que pasaremos a llamar ceremonias a partir de ahora:
o Sprint Planning Meeting (reunión de planificación del sprint).

o Daily Meeting (reunión diaria).

o Sprint Review (reunión de revisión de sprint).

o Sprint Refinement (reunión de refinamiento de sprint).

o Sprint Retrospective (reunión de retrospectiva del sprint).

Por lo que, en resumen, podemos decir que Scrum es la aplicación práctica de los principios ágiles.
Este enfoque, según lo postulado por el creador Jeff Sutherland, permite a la compañía lograr el
doble de éxito en la mitad del tiempo.

Esta metodología aplica una forma de trabajo colaborativa, en equipo para obtener el mejor
resultado posible de un proyecto y si lo relacionamos con negocio en las organizaciones, equipos
multidisciplinares tienen que trabajar de una manera conjunta para alcanzar sus
objetivos (Schwaber y Sutherland, 2013).

Aunque venimos de relacionar metodologías ágiles con negocio, cuando hablamos de Scrum
tendemos a pensar que es una metodología de trabajo solo aplicable a organizaciones o grandes
empresas, pero se pueden ver muchos ejemplos donde aplicar esta forma de trabajo trajo grandes
beneficios (Pareja, 2019).

Como ejemplo innovador de uso de metodologías ágiles encontramos la clínica de salud

mental, Monash Health, Melbourne, donde los médicos adoptaron estas prácticas para gestionar
enfermedades complejas, habiendo una mejora del 46 por ciento en las medidas de atención y
satisfacción laboral.

En este caso, la clínica mental también mejoró su sistema de IT (Tecnología de la información),

proporcionando sistemas eficientes y más rápidos sin perder calidad, así como ofrecer una
atención inmediata tanto en la urgencia, como diagnóstico, tratamiento y recuperación de
pacientes.

Esto se consiguió gracias a la valoración del personal médico tras cada sesión con los pacientes
complejos, para poder usar a tiempo real el feedback, y usarlo como oportunidad de mejora y
aprendizaje con el fin de brindar servicios a la medida del paciente.

Siguiendo la filosofía Agile, y por consecuencia la metodología Scrum, las interacciones con los
pacientes en la clínica son más valoradas que los procesos, habiendo una adaptación a la nueva
forma de gestión y obteniendo como resultado un desarrollo ágil, una atención personalizada con
más calidad en los procedimientos y un ahorro de tiempo.

Este ejemplo nos da la visión de que cuando hablamos de Scrum, no solo nos estamos refiriendo al
sector tecnológico o financiero, no solo hablamos de un marco de trabajo que se usa para
desarrollar software o hardware, o para gestionar la operativa de las organizaciones, sino que
Scrum puede aplicarse a todos los sectores en función de sus necesidades.

Otro ejemplo de la aplicabilidad de Scrum, puede ser el sector de la política, lleno de

incertidumbre, inestabilidad y cambio constante (Pareja, 2019). El equipo de la campaña de Barack
Obama usó metodologías ágiles para lograr su reelección como presidente de Estados Unidos en
2012.

El candidato demócrata necesitaba ver resultados para hacer los ajustes casi a tiempo real a través
de las redes sociales. En este caso, analizaron durante meses a los votantes de los estados clave en
las elecciones. Con estos datos, se identificó a los indecisos y se creó una campaña a través de
redes sociales centrada en ellos.

El equipo Scrum de campaña, estaba formado por matemáticos, programadores y expertos en

Internet, su función era medir grandes volúmenes de datos y analizar resultados para ajustar su
ruta de forma ágil. El resultado fue una amplia participación ciudadana y ajustes a tiempo real.

A lo largo de la campaña, identificaron los intereses de los posibles electores, y gracias al Big Data
y al desarrollo ágil se combinó el análisis de grandes volúmenes de datos con la segmentación
refinada que demostró ser eficaz en la identificación de mensajes que resonaban con audiencias
específicas lo que ayudó en la reelección de Barack Obama (Kaizenia, 2019).
Figura 10. Scrum, visión global. Fuente: Opinno.

4.3. Scrum: Roles

Scrum: Roles

Para poder trabajar de una manera eficiente además de exitosa debemos determinar quién hace
qué, y cuáles son responsabilidades frente a los demás miembros del equipo. La colaboración es
clave, pero también lo son las asignaciones de tareas, las responsabilidades de cada uno, así como
la transparencia dentro del equipo (Schwaber y Sutherland, 2013).

Figura 11. Roles. Fuente: Opinno.

Los roles de Scrum son: Product Owner (PO), Scrum Master (SM) y Scrum Team (ST), y en rasgos
generales podemos decir que:

 Los distintos miembros del equipo pueden ir cambiando de nivel o incluso desaparecer en
distintas partes del proyecto.

 La involucración del equipo core es 100 %, y no debe ser de más de 10 personas.

 El equipo core está co-localizado.

 No hay ningún problema con que parte del equipo core sea externo, incluso puede que el
único interno sea el Product Owner.

Product Owner

Figura 12. Product Owner. Fuente: Agile Visual Mind

Traduce los valores y deseos del cliente, identifica, define y prioriza las necesidades y
objetivos, que maximizan el valor del producto, garantizando que se cumplen con las áreas de
soporte y control para poder lanzar el producto final al mercado.

Es el responsable de maximizar el valor del trabajo hecho por el equipo, de ponerlo en valor frente
al cliente. Al tener la doble visión, tanto de cliente como del Scrum Team, es el responsable último
de variar la prioridad del Product Backlog, artefacto que definiremos más adelante.

El Product Owner debe expresar claramente lo que necesita el cliente, así como las prioridades de
las user stories, debe optimizar el trabajo del equipo, así como asegurar que el trabajo que se está
haciendo es transparente, visible y clara para todos los miembros del equipo.

En este caso esta figura solo consta de un miembro, y es responsable último del trabajo del
equipo. Sus decisiones deben ser respetadas por toda la organización y el equipo debe respaldar
con entrega de valor cada sprint.
Características y responsabilidades:

 Representa al usuario y hace de nexo de unión con el equipo.

 Trabaja de manera coordinada con los diferentes stakeholders para identificar, definir y
priorizar las necesidades del producto.

 Es la voz del equipo hacia el exterior.

 Comprende y define el objetivo de negocio.

 Cuantifica el valor que aporta a negocio la solución.

 Define y prioriza las user stories.

 Valida las entregas de cada sprint.

 Asegura el escalado y soporte al equipo.

Scrum Master

Figura 13. Scrum Master. Fuente: Knowledgehut

Es quien se asegura de que Scrum se practica correctamente. Su tarea principal es eliminar los
obstáculos y guiar al equipo en las prácticas de Scrum. Responsable de la velocidad y la mejora
continua del equipo Scrum. Es responsable de que Scrum es entendido y adoptado a nivel
metodológico, asegurando que el equipo trabaja acorde a las reglas.

El liderazgo de este rol está enfocado al servicio al equipo «Servant Leader». Ayuda a los equipos o
personas externas al equipo core a entender cómo deben ser las interacciones con el mismo,
cuales están siendo un impedimento, o cuales son una ayuda. Evita las distracciones, así como los
bloqueos que pueda tener el equipo, consiguiendo de esta manera maximizar el aporte de valor
por el Scrum Team.
El Scrum Master y el Product Owner deben estar alineados en cuanto a los requerimientos de
cliente, deben trabajar buscando la mayor facilidad de interacción para llevar al éxito el proyecto.
En este punto deben de buscar técnicas para gestionar el Product Backlog de una manera efectiva,
así como ayudar a entender al Scrum Team la necesidad de tener unas user stories, claras y
concisas.

Este rol es responsable de entender la planificación de una manera global y con una iteración
asociada, debe asegurarse que el Product Owner prioriza el Product Backlog de manera adecuada
para maximizar el valor. Asimismo, debe entender la filosofía Agile y ser facilitador en todas las
ceremonias en las que sea requerido.

En relación con su responsabilidad con el equipo debe guiarle para que sean autoorganizados y
multifuncionales, darles la visión para la creación de productos de alto valor, eliminando los
impedimentos y favoreciendo su forma de trabajo.

Desde el punto de vista de la organización, este rol tiene una labor imprescindible para la
adaptación y adopción metodológica. Debe liderar y guiar a la organización, planificar las
implementaciones de Scrum en la organización, así como ayudar a llevar a cabo el desarrollo
empírico del producto.

Una de las funciones más importantes, y que gracias a ella se implanta con éxito esta forma de
trabajo, es la motivación frente a los cambios, que incrementan la productividad de los equipos, la
educación y la cultura del feedback, el aprendizaje y el conocimiento de que lo iterativo maximiza
la eficiencia del proyecto y del proceso.

Características y responsabilidades:

 Asegurar que el equipo entiende y se adhiere a las prácticas de Scrum.

 Facilitar las reuniones de Scrum.

 Entrenar al equipo para autoorganizarse y autogestionarse.

 Asegurar que el equipo es multifuncional.

 Mantener al equipo centrado en un objetivo trascendente.

 Ayudar al Product Owner a redefinir el Product Backlog.

 Representar al equipo ante el resto de la organización.

 Proteger al equipo de interrupciones.

 Mantener la moral del equipo alta.

 Aplicar mejoras en los procesos.

Scrum Team
Figura 14. Scrum Team. Fuente: Visual Paradigm

Personas que trabajan activamente en la ejecución de los elementos del Product Backlog durante
un sprint. Están determinados a vencer cualquier impedimento que suponga el no conseguir
acabar las tareas comprometidas en el sprint.

Los equipos Scrum son multifuncionales y autoorganizados decidiendo ellos la mejor forma de
llevar a cabo el trabajo, ya que son ellos quienes tienen los conocimientos técnicos, competencias
y capacidades para ello. Debido a esto trabajan de forma autónoma y no dependiendo de otras
personas externas al equipo.

El Scrum Team está diseñado para optimizar la productividad, maximizar la creatividad, así como la
productividad, entregando productos o resultados de forma iterativa e incremental, lo que
permite obtener feedback continuo del cliente y por consiguiente las mejoras incrementales que
este feedback suponga.

Cada entregable, al final de cada sprint, tiene las características de ser funcional y aportar valor al
cliente, no siendo entregas a medias o no funcionales. Esto hace que el feedback que se reciba sea
real ya que ha podido testar el valor o la funcionalidad del mismo.

Características y responsabilidades:

 Grupo de profesionales con los conocimientos técnicos necesarios y que desarrollan el

proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al
inicio de cada sprint.

 Tienen un objetivo común, comparten la responsabilidad del trabajo que realizan (así
como de su calidad) en cada iteración y en el proyecto.

 Tienen espíritu del equipo, determinación de superar cualquier impedimento.

  Son autónomos, autoorganizados y autogestionados, con poder para tomar sus propias
decisiones.

 Equipos multifuncionales que tienen todas las habilidades necesarias para completar el
proyecto.

 El Scrum Team se encuentra colocalizado y está dedicado al proyecto al 100 %.

4.4. Scrum: Ceremonias

Scrum: Ceremonias

Para la adecuada adopción de esta metodología hay que tener en cuenta ciertos puntos que son
necesario cumplir. Este es el caso de las ceremonias mencionadas en el apartado «¿Qué es
Scrum?» En esta sección pasaremos a definir cada una de las ceremonias, los roles implicados, así
como desmitificar ciertas cuestiones que surgen en torno a las ceremonias.

Gracias a estas ceremonias creamos cierta regularidad y minimizamos las reuniones ineficientes.
Todas las ceremonias están definidas por un tiempo específico, es decir, la duración es fija y están
localizadas en días específicos de cada sprint. Cada una de las ceremonias tiene un objetivo
específico y si alguna de estas ceremonias no se realizase implicaría una falta de transparencia y
una mayor posibilidad de error (Schwaber y Sutherland, 2013).

Antes de definir las ceremonias mencionadas anteriormente, es necesario hablar del sprint,
definido como un bloque de tiempo en el cual, una vez terminado, se entrega valor. La duración de
los sprints se determina al inicio del proyecto, pero siempre tendrá que estar entre dos y cuatro
semanas, siendo lo más común, dos semanas.

Cada sprint comienza inmediatamente después del anterior y cada uno de ellos contendrá todas
las ceremonias comentadas. Cabe destacar ciertos aspectos que suceden durante el sprint:

 No se realizan cambios durante el sprint que puedan afectar al entregable del mismo.

 La calidad no es un aspecto que pueda disminuir.

 El alcance del sprint debe ser consensuado con el Product Owner.

Debemos tener en cuenta que la duración de cada sprint no se ha elegido de forma aleatoria por
sus creadores. Cuando el horizonte del sprint es demasiado grande, aumenta la complejidad y por
consecuencia el riesgo. Es por ello que está definido con una duración acotada y un alcance
definido, y estos dos aspectos no son susceptibles de cambio.

Sprint Planning
Figura 15. Ejemplo de Sprint Planning. Fuente: Asana

La finalidad de esta ceremonia es organizar el sprint que se va a llevar a cabo. Se hace mediante
una co-creación de todo el Scrum Team. Tiene una duración máxima de dos horas por semana
de sprint, hasta un máximo de ocho horas si es que el sprint es de cuatro semanas.

Es trabajo del Scrum Master el asegurarse de que la ceremonia se lleve a cabo, y que todos los
asistentes y miembros del equipo, entiendan el objetivo y el alcance esta ceremonia, así como
mantener un control del tiempo estricto.

Según la Guía de Scrum, se plantean dos cuestiones importantes, qué puede ser terminado en
un sprint y cómo se conseguirá terminar este trabajo. En el caso de responder a la primera
pregunta tenemos que saber que es en esta ceremonia donde el Product Owner consensua el
objetivo del sprint, así como las user stories o historias de usuario que, de completarse, se logaría
alcanzar el objetivo.

Una vez fijado el objetivo, es el Product Owner quién va a dividir ese objetivo en user stories, y
será el Scrum Team quien a su vez divida estas en tareas más pequeñas para poder ejecutarlas, y
son solo ellos quienes podrán hacer esta última división ya que tienen el conocimiento para
desarrollar esta labor.

Si pasamos a la cuestión de cómo se conseguirá terminar el trabajo para así alcanzar el objetivo
del sprint, debemos cerciorarnos de que se ha fijado un objetivo alcanzable para el tiempo
estimado de sprint, ya que, una vez aprobado el alcance del sprint, el Product Owner comunicará a
cliente el alcance del sprint.
El equipo se autoorganiza para asumir el trabajo fijado en el Product Backlog, tanto en el Sprint
Planning como a lo largo del sprint. Si se determina que es una carga demasiado grande para el
tiempo del sprint se puede renegociar las user stories con el Product Owner, cambiando los
términos de alcance o de objetivo a completar haciendo incremental la entrega de valor al final del
mismo.

Antes de pasar a la siguiente ceremonia, es necesario hacer una alto en el camino para entender
qué significa objetivo del sprint, el cual puede ser alcanzable mediante la priorización de las user
stories del Product Backlog.

La finalidad de fijar el objetivo del sprint en esta ceremonia viene dada por la flexibilidad que
tienen el equipo, así como la coherencia a la hora de fijarlo. A lo largo del sprint, el objetivo se
mantiene en el horizonte para no perder el camino de actuación, implementar la funcionalidad y la
entrega de valor.

Miembros participantes: Product Owner, Scrum Master y Scrum Team.

Daily Meeting

Figura 16. Ejemplo de Daily Meeting.Fuente: Medium

Es una ceremonia de reunión diaria definida en un bloque de tiempo de quince minutos. En esta
ceremonia se crea un plan de trabajo para el propio día, realizándose siempre a la misma hora
todos los días que formen parte del sprint.

Esta ceremonia es altamente beneficiosa para el equipo de trabajo ya que se visualiza el avance
del día anterior de cada uno de los miembros del equipo, los posibles bloqueos que existen, así
como la planificación para ese día.

Por lo tanto, los miembros del equipo en estos quince minutos deben responder a estas tres
preguntas:

 ¿Qué hice ayer que ayudó a lograr el objetivo del sprint?

  ¿Qué haré hoy para ayudar a lograr el objetivo del sprint?

 ¿Qué bloqueos tengo el día de hoy que evite que el equipo o yo logremos el objetivo
del sprint?

Gracias a esta ceremonia se optimiza las posibilidades de que el equipo consiga alcanzar el
objetivo del sprint, y se reduce el riesgo de bloqueos o cuellos de botella ya que estos se
visualizando diariamente.

Como se ha comentado anteriormente, la colaboración es un factor esencial de este marco

metodológico y no debe ser menos esta ceremonia, trabajando en conjunto y siendo un equipo
autoorganizado, se podrá alcanzar como equipo el objetivo del sprint.

Es labor del Scrum Master hacer que ocurra esta ceremonia, pero es el propio equipo quien se
encarga de liderarla. Se encarga de enseñar cómo debe realizarse esta ceremonia, así como el
alcance de la misma.

En este caso los beneficios que implican la realización de esta ceremonia son las mejoras de
comunicación, así como la eliminación de la necesidad de mantener otras reuniones. Además, el
poder visibilizar los bloqueos hace que puedan identificarse y eliminarse antes de que supongan
una pérdida o un aumento del riesgo de no alcanzar el objetivo de entregable.

Miembros participantes: Scrum Master y Scrum Team.

Sprint Review
Figura 17. Ejemplo de Sprint Review. Fuente: StartInfinnity

Al final de cada sprint se lleva a cabo esta ceremonia para poder revisar el aporte de valor, así
como valorar estratégicamente el avance global del proyecto.

Esta reunión tiene una duración de máximo una hora a la semana, en el caso de un sprint de un
mes, un total de cuatro horas. El equipo muestra el incremento de valor al cliente, y este
incremento debe ser validado previamente por el Product Owner.

El objetivo de esta ceremonia es obtener feedback de cliente y del usuario, así como actualizar
el Product Backlog para el siguiente sprint. Esta ceremonia nos da una visual global del avance del
proyecto, así como la organización de los siguientes pasos.

En este caso tenemos dos objetivos importantes:

 Revisar el uso potencial del resultado del proyecto.

 Revisar la línea del tiempo, así como el presupuesto, las capacidades potenciales y el
enfoque para el siguiente sprint.

Miembros participantes: Product Owner, Scrum Master, Scrum Team y Stakeholders.

Sprint Refinement

Esta ceremonia solo se produce en el caso de que sea necesario. Se produce la revisión y
redefinición de las user stories a partir de nuevas informaciones o requerimiento.

Asimismo, se produce la re-estimación de los elementos existentes basada en las nuevas

informaciones anteriormente desconocidas. En esta ceremonia también se puede llevar a cabo la
división de user stories grandes (épicas) en otras más pequeñas, que supongan el alcanzable
deseado.

Esta ceremonia se completa con una nueva estimación, así como una nueva priorización de los
elementos.

Miembros participantes: Product Owner, Scrum Master, Scrum Team y Stakeholders.

Sprint Retrospective
Figura 18. Ejemplo de Sprint Retrospective Boat. Fuente: Plutora

Esta ceremonia es una oportunidad para el equipo de poder recapitular acerca del trabajo hecho y
encontrar las posibles mejores que sean necesarias.

Tiene una duración máxima de una hora a la semana y como en las anteriores el Scrum Master
tiene la responsabilidad de que se celebre y de que los asistentes entiendan el propósito de la
misma.

El Scrum Master participa en la reunión como un miembro del equipo, siendo el propósito de esta
ceremonia:

 Valorar cómo fue el último sprint, en cuanto a personas, procesos y herramientas.

 Identificar y ordenar aquellas cosas importantes que salieron bien, aquellas que pueden
mejorarse y por último aquellas que no pueden repetirse.

 Crear un plan de mejoras para todo el equipo con objetivos a corto y medio plazo que
supondrán mejoras incrementales a futuro.

Miembros participantes: Product Owner, Scrum Master y Scrum Team.

Una vez conocidas las cinco ceremonias debemos tener claro cuál es la importancia de cada una
de las mismas, los requerimientos necesarios para llevarlas a cabo y quienes son los implicados,
pero, aun así, surgirán dudas acerca de la necesidad de su celebración o no, por ello vamos a
desmitificar ciertos aspectos asociados a estas ceremonias.

Cuando empezamos a implantar esta nueva forma de trabajo surgen las primeras dudas acerca de
la importancia de las ceremonias, así como del tiempo que implican cada una de ellas, por eso
hemos querido entrar a desmitificar ciertas dudas que siempre surgen y que serán las primeras
que vengan a la cabeza (Hartzog, 2019).

Tarda demasiado
La ceremonia de Sprint Planning es algo que todos los equipos temen. Hay una regla que no falla,
dos horas por semana de sprint, con lo que, si el sprint es de dos semanas, tendremos una
ceremonia de Sprint Planning con una duración de cuatro horas.

Para que estas cuatro horas sean eficiente el equipo debe estar alineado con los requerimientos
del proyecto, y debe ir validando el cumplimiento de los mismos ya que este ejercicio además de
dar una visión global del proyecto permite tener un conocimiento de en qué punto estamos del
proyecto, así como de los impedimentos que van surgiendo a lo largo del mismo.

Una de las cosas más importantes en las ceremonias es dedicar la ceremonia únicamente a lo que
está designada, si por ejemplo hablamos de la ceremonia de Sprint Planning, nos centraremos en
planificar y asignar las user stories a quien se considere, así como estimar el esfuerzo que cada una
de estas asignaciones impliquen.

Todas las ceremonias deberían estar liderada por el rol correspondiente y tendrá que dirigir la
conversación, dar una buena planificación, en función de quien hablemos. A fin de al cabo, si los
pasos se siguen, el tiempo no debe ser un impedimento para la realización d estas ceremonias.

El Product Owner (PO) debe decidir que ha de hacerse en cada sprint

Cuando es el PO quien decide qué hay en el sprint, no estamos hablando de un proyecto ágil, en
este caso el equipo no se ha comprometido con el trabajo, con lo cual podrían terminarlo, pero tal
vez no.

En el caso del Sprint Planning la función del PO es priorizar los requisitos de las partes interesadas,
por un lado, es la voz del cliente por lo que tiene unos requerimientos específicos, que serán los
criterios de priorización, por otro lado, tiene que respetar al equipo. El trabajo del Scrum Master
es decirle al PO, cuanto te probable puede ser el compromiso al sprint, son ellos quienes
estimarán esfuerzo, y, por ende, su compromiso con las asignaciones.

Una vez que todo está hablado por parte del equipo, el PO puede informar a los interesados qué
vamos a entregar al final del sprint. Una vez que se ha informado, a no ser que haya una causa
insalvable, el compromiso queda pactado y se entregará eso al final del sprint.

Solo el líder del equipo o un equipo «core» de confianza debe proporcionar estimaciones»

4.5. Artefactos

Scrum: Artefactos

Para poder llevar a cabo un seguimiento, así como para garantizar transparencia del proceso y
avance del proyecto, podríamos decir que incrementan la eficiencia y la proactividad (Schwaber y
Sutherland, 2013).

Representan el aporte de valor de manera gradual y una adaptación a los cambios en tiempo real.
Están diseñados con el propósito de maximizar la información clave necesaria para el
entendimiento del proyecto, el alcance y el objetivo del sprint por parte de todos los miembros del
equipo.

Product Backlog (PB)

Figura 19. Ejemplo de Product Backlog. Fuente: Pinterest

Este artefacto es el corazón de Scrum, una lista priorizada de requisitos/historias o

funcionalidades que hay que desarrollar a lo largo del proyecto y que representa a grandes rasgos
una lista priorizada de lo que el cliente quiere que tenga el producto.

Está compuesto por Product Backlog Items (PBIs) que son las necesidades del mercado o las
especificaciones del producto. La técnica más usada para expresar los PBIs son las user stories.

Una user story o historia de usuario consiste en los distintos escenarios e interacción entre el
usuario y la solución. Son definidas por el Product Owner, que es quien conoce mejor lo que el
cliente necesita. Tiene que poder realizarse en un solo sprint, si es demasiado grande se rompe
en user stories más pequeñas, siempre y cuando aporte valor.

Es necesario que represente el punto de vista del usuario final y es el Product Owner quien
determinará para el cliente cada uno de los PBIs. Si hablásemos de su representación gráfica, los
que estén colocados en la parte superior serían los de mayor prioridad y que deben ser definidos,
convertidos en user stories inmediatamente accionables. Aquellos PBIs que estén en la parte
inferior, necesitarán menos detalle ya que se definirán más adelante.

El Product Owner no solo define las user stories, sino que las tiene que priorizar. Esta priorización
consiste en ordenar todas las user stories en función del valor que le aporta al cliente, para poder
ofrecerle el mayor valor cuanto antes. Si por algún motivo el proyecto tuviera que parar en algún
momento, el usuario habrá recibido al menos las funcionalidades que mayor valor le aportaban. El
Product Owner debe mantener el Product Backlog actualizado a medida que va avanzando el
proyecto.

Este artefacto es uno de los que más adaptados al cambio están. Los cambios son naturales, no se
necesita ninguna gestión del cambio, se da por hecho que va a haber cambios porque las
circunstancias cambian a lo largo del proyecto. Por lo tanto, nunca está completo y evoluciona a
medida que el producto y el entorno también lo hacen. Es dinámico, cambia constantemente para
identificar las necesidades reales, que sea competitivo y útil.

Sprint Backlog (SB)

Figura 20. Sprint Backlog. Fuente: ScrumOrg

Es el conjunto de elementos del Product Backlog seleccionados para el sprint, más un plan para
entregar el incremento de valor del producto y el objetivo a alcanzar. Hace visible el trabajo del
equipo e identifica lo necesario para alcanzar el objetivo del sprint.

A medida que el sprint va avanzando, y las tareas se van realizando, se va actualizando la

estimación del trabajo que queda. Lo que implica que, si alguna tarea ya no resulta necesaria, es
eliminada. Esto nos da la visión a tiempo real del avance del sprint y que sea un artefacto de lo
más útil para levantar riesgos o visibilizar logros.

Es una lista ordenada de los PBIs que el quipo considera que puede completar en el
próximo sprint. Cada user story debe tener un valor en puntos según la cantidad estimada de
esfuerzo relativo que se necesita para completarla. El equipo determina la mejor manera de
trabajar el Sprint Backlog pero siempre que sea posible trabajará primero en los items de mayor
valor. Una vez seleccionados los ítems del Sprint Backlog, no debe haber cambios hasta el final
del sprint, aunque en caso de necesidad el PO puede interrumpir y replanificar.

En resumidas cuentas, es a lo que se compromete el equipo según la prioridad dada por el PO. Los
puntos asignados no se corresponden con horas, se corresponden con el nivel de esfuerzo relativo
calculado en función de las capacidades conjuntas y de la productividad global de cada equipo.
Este cálculo no se puede definir, es un dato empírico que el equipo irá conociendo conforme vaya
trabajando como equipo unido, sprint tras sprint y proyecto tras proyecto. Las primeras
estimaciones estarán mal hechas porque el equipo no conoce su capacidad real, conforme pase el
tiempo la averiguarán. Es un método de prueba-error.

En relación con la puntuación de las tareas del sprint, será el Scrum Team quien determinará la
cantidad de esfuerzo relativo, al inicio de cada sprint se valora el esfuerzo de las tareas a realizar
planteadas por el PO y consensuadas por todo el equipo. Se empieza valorando la tarea de más
esfuerzo y la de menos esfuerzo para determinar el máximo y el mínimo existente. El expertise del
equipo, la madurez y la novedad del proyecto que afectará a la puntuación de esfuerzo relativo.

Burndown Chart

Figura 21. Ejemplo visual de un Burndown chart. Fuente: Opinno.

Este artefacto es un diagrama para plasmar el tiempo del que dispone el equipo para completar el
trabajo pendiente del sprint en curso. En cuanto a su representación gráfica:

 Eje X: tiempo en días de duración del sprint o de la iteración.

 Eje Y: la cantidad de trabajo comprometida con el cliente durante el sprint.

Al final del día, el equipo actualiza el estado de sus tareas indicando cuánto les queda para
terminar la tarea que tienen en curso, se suma el total y se actualiza la gráfica. Si va por debajo de
la línea ideal, el equipo va en buen camino para alcanzar el objetivo del sprint.

Cuando hablamos de equipo «core» en Agile, no estamos siendo honestos. Evidentemente hay un
equipo que puede que estar de una manera más permanente en el proyecto y otros miembros del
equipo solo participen de manera puntual en ciertos sprints.
Es por ello por lo que no debemos acotar las estimaciones de esfuerzo a aquellos miembros
«core», todo el equipo implicado en ese sprint tiene que estimar el esfuerzo que supone hacer
algo.

En Agile el equipo se compromete con el sprint, no el individuo o el «líder del equipo», por lo que
es de vital importancia que sea todo el equipo el que pueda debatir el esfuerzo que suponen
las user stories para garantizar su comprensión y conseguir de esta manera que se asigne una
estimación más precisa ya que utilizaremos la experiencia completa del equipo.

En el caso de un Sprint Planning, el PO se asegurará de que se han resuelto todas las dudas
respecto al alcance del proyecto, en este caso del sprint, esta es una forma de generar una
relación de confianza en la que el equipo se compromete a completar las user stories asignadas.

Por lo que ya visualizados los mitos más «famosos» que están relacionados con las ceremonias, y
en concreto con el Sprint Planning se puede resumir que:

 Un Sprint Planning tiene una duración de un máximo de 2 horas.

 Las user stories tendrán una estimación de esfuerzo dada por todos los miembros del
equipo.

 El equipo se compromete con las user stories que quedan definidas en la ceremonia y
existe una confianza entre todos los miembros del equipo para poder llevar a cabo las
seleccionadas.

 Tras la ceremonia, el PO tiene la seguridad de poder comunicar al cliente lo que se ha

planificado en el sprint.

4.6. Ventajas de Scrum

Según diversas fuentes, las ventajas de trabajar bajo la metodología Scrum son infinitas, pero es
verdad que todos los autores que han escrito acerca de esta forma de trabajo coinciden en los
siguientes puntos (Viewnext, 2019):

 Fomenta el compromiso y la motivación del equipo.

 Se promueve la autoorganización y el trabajo autónomo.

 Elimina bloqueos, lo que deriva en una mayor productividad.

 Genera una mejora en la estimación de esfuerzo que implica el proyecto.

 La división del trabajo en función de las competencias de cada uno y proporciona una
mayor flexibilidad para los cambios.

 Disminuye los riesgos de llevar a cabo el proyecto.

 Existe una mayor alienación con el cliente gracias a recibir feedback de forma continua y
por lo tanto a cumplir sus expectativas.
  Reduce el time to market del producto.

Podemos decir que trabajar bajo este marco no solo aporta beneficios a los equipos, si no a la
organización, imperando valores como la colaboración, la transparencia y la confianza, haciendo
que la cultura Agile forme parte del ADN de la organización.

4.7. Referencias bibliográficas

Alex, M. (2019). Agile in the healthcare sector. Recuperado

de: https://businessagility.institute/learn/agile-in-the-healthcare-sector/

Hartog, S. (2019). Common Myths of Sprint Planning; Recuperado

de: https://medium.com/swlh/common-myths-of-sprint-planning-5bc091ad3b2a

Kaizenia. (2019). Agile usado en campaña política. Recuperado de: https://kzi.mx/agile-usando-en-

campana-politica/

Pareja, D., J. (2019). Scrum aplicado a la salud y a la política. Recuperado

de: https://www.pragma.com.co/blog/Scrum-aplicado-a-la-salud-y-a-la-politica

Proyectos Agile. (2019). Qué es Scrum. Recuperado de: https://proyectosagiles.org/que-es-Scrum/

Schawaber, K. y Sutherland, J. (2013). La guía de Scrum. La guía definitiva de Scrum: las reglas del
juego. Recuperado de: https://www.Scrumguides.org/docs/Scrumguide/v1/Scrum-guide-es.pdf

Viewnext. (2019). Artefactos Scrum, ¿qué son y para qué sirven? Recuperado
de: https://www.viewnext.com/artefactos-Scrum/

4.8. Harman International: Increasing Value Delivered

ScrumAtScale (14 de noviembre de 2018). Harman International: Increasing Value Delivered.

Scrum@Scale. [Vídeo]. Youtube. Recuperado de https://www.youtube.com/watch?v=sYrWJ-vyeas

Este vídeo explica los pasos a seguir para la incrementación de valor, a través de la definición de
patrones viendo qué está pasando en el ecosistema, la validación de la idea a través de MVP lo
que proporciona un mayor valor o la definición del ROI de un usuario específico.