Luis Felipe Hanco Sucari

DESAFÍO FINAL: APLICACIÓN

DE LA METODOLOGÍA AGIL
SCRUM
1. Identifica las ceremonias, artefactos y roles
del SCRUM y ponlo en práctica en tu proyecto
Las ceremonias Scrum:
claves para la gestión de procesos

 Sprint Planning
 Daily Scrum
 Sprint Review
 Sprint Retrospective
 Sprint Grooming o Refinement

El objetivo de estas ceremonias o eventos es mantener los mínimos

necesarios para facilitar que el control empírico de procesos funcione.

Scrum define cinco ceremonias principales para cumplir con el control

de sus procesos, todas con un sentido de ser propio que hace que
sean imprescindibles para esta metodología.

Aunque el proceder general de algunas compañías es el de adecuar

las ceremonias prescritas a sus necesidades y, si bien esto puede
tener sentido en algunas organizaciones que cuentan con una larga
tradición en otras metodologías, la tímida aplicación de las
ceremonias y su exagerada adaptación a la cultura pre-existente en
la organización terminan en muchos casos por generar lo mismo que
venían produciendo, pero con nuevos nombres que suenan más
“Agile”, lo cual suele acabar en sonoros fracasos.

La razón por la que Scrum cuenta con estas cinco ceremonias es la

de mantener los mínimos necesarios para facilitar que el control
empírico de procesos funciona . El gran problema de adaptar estos
eventos o de transformarlos en otra realidad es el de dinamitar uno
de los pilares fundamentales de Scrum y, por lo tanto, asumir correr
el riesgo al que conlleva. Analicemos a continuación lo que es un
Sprint y las ceremonias que van asociadas al mismo:

¿Qué es un Sprint?
Sprint es un contenedor para el resto de eventos de Scrum . El Sprint
es continuo, es decir, su duración no debe cambiar mientras está en
marcha el desarrollo del producto, y se puede interpretar como una
 Luis Felipe Hanco Sucari

medida de ritmo constante a lo largo del tiempo, permitiéndonos

reducir complejidad y comparar resultados a lo largo de diferentes
Sprints. El Sprint permite la transparencia, así como inspeccionar y
adaptar los otros eventos de Scrum.

Scrum prescribe que un Sprint debe durar 4 semanas más o menos.

Aunque es bastante habitual que los equipos Scrum elijan tener
Sprints de diversas duraciones según la finalidad perseguida. Cada
caso es diferente y es el equipo Scrum el que debe descubrir cuál es
su periodo mínimo necesario para generar valor a través de un
incremento terminado.Partiendo de la experiencia más inmediata en
la implantación de “Agile” a lo largo de diferentes organizaciones, la
duración real de los Sprints es la siguiente:

1. 2 semanas: poco frecuente, generalmente usada en proyectos

de I+D o PoCs que requieren de un rápido ciclado para obtener
resultados a muy corto plazo.

2. 3 semanas: frecuente, se asemeja al anterior, pero

generalmente en iniciativas de algo más de envergadura.

3. 4 semanas: lo más frecuente, parece un ritmo adecuado para

la mayor parte de los productos.

4. 5 semanas: frecuente también, aunque es una duración fuera

de los estándares de Scrum. Es habitual encontrarnos este
escenario en las organizaciones, demandado por los propios
equipos Scrum. Resulta muy útil en proyectos que se encuentran
en fases iniciales, así como en periodos estimados como menos
productivos.

La duración de un Sprint está determinada por el periodo mínimo en

que un equipo de desarrollo puede generar valor a través de un
incremento determinado. El Sprint es una iteración definida (time
boxed) que sirve al desarrollo iterativo e incremental.

La duración del Sprint se determina por un horizonte de planning

aceptable, determinado por el propio equipo Scrum junto al Product
Owner. No hay fases en Scrum, sólo Sprints. No existen Sprints
específicos de testing, hardening, release o análisis.

Un Sprint normal tendría los siguiente eventos o ceremonias:

1. El Sprint Planning al comienzo del Sprint

2. Daily Scrums a diario

3. Un Sprint Review al final del Sprint para inspeccionar el

incremento realizado.
 Luis Felipe Hanco Sucari

4. Y, finalmente, una Retrospectiva para inspeccionar el equipo y

levantar mejoras que se apliquen en el siguiente Sprint.

5. Adicionalmente se ha incorporado también una reunión

de Grooming o Refinement, que sirve para, dentro del Sprint,
afinar y aclarar ciertas historias de usuario que pudieron quedar
pendientes durante el Sprint Planning.

Todo ocurre en un sólo Sprint y en cada Sprint . La mentalidad de un

proyecto por Sprint es uno de los cambios más difíciles de asumir
para las organizaciones que están haciendo una transición a esta
metodología Agile-Scrum. A diferencia de la gestión tradicional de
proyectos, donde un proyecto puede durar meses o años, en Scrum
un “proyecto” dura un sólo un Sprint, de modo que todas las tareas
necesarias para llevar el proyecto a cabo (como el diseño, la
planificación o el testing) se realizan dentro del mismo Sprint,
siempre orientado a generar el máximo valor.

En Scrum, los proyectos se financian por cada Sprint y es el product

owner quien decide dónde y a qué dedicar los recursos. Entender
esto es crítico para asegurar el éxito en el empleo de Scrum en una
organización.

1ª ceremonia: Sprint Planning

El Sprint Planning es una reunión que se realiza al comienzo de cada

Sprint donde participa el equipo Scrum al completo; sirve para
inspeccionar el Backlog del Producto (Product Backlog ) y que el
equipo de desarrollo seleccione los Product Backlog Items en los que
va a trabajar durante el siguiente Sprint. Estos Product Backlog
Items son los que compondrán el Sprint Backlog.
 Luis Felipe Hanco Sucari

Durante esta reunión, el product owner presenta el Product

Backlog actualizado que el equipo de desarrollo se encarga de
estimar, además de intentar clarificar aquellos ítems que crea
necesarios.

Si bien en el Sprint Planning participa el equipo Scrum al completo,

no participan los stakeholders. En el Sprint Planning se inspeccionan
el Product Backlog, los acuerdos de la Retrospectiva, la capacidad y
la Definition of Done y se adaptan el Sprint Backlog, Sprint Goal y
el plan para poder alcanzar ese Sprint Goal.

El Sprint Planning se divide en dos partes. En la primera parte de la

reunión se trata Qué se va a hacer en el siguiente Sprint y, en la
segunda parte, se discute el Cómo. La primera parte está organizada
y liderada por el product owner, mientras que de la segunda parte se
encarga el Development Team. La única labor del Scrum Master es
asegurarse de que la reunión existe como parte de Scrum y que se
mantiente dentro de las duraciones estimadas.

El Sprint Planning puede durar hasta 8 horas para Sprints de 4

semanas. En la práctica esta ceremonia suele llevar una mañana
completa -alrededor de 5 horas- y, sólo si el producto o el Sprint
definido por el Product Owner son complejos o están poco claros, se
llegan a alcanzar las 8 horas definidas en la metodología. La razón del
Sprint Planning es conseguir alineamiento entre negocio y desarrollo
de producto en relación a las prioridades.

2ª ceremonia: Daily Scrum

El Daily Scrum, conocido comúnmente sólo como “La Daily”, es una
reunión diaria de 15 minutos en la que participa exclusivamente
el Development Team.

En esta reunión todas y cada una de las personas del Development

Team responden a las siguientes preguntas:

1. ¿Qué hice ayer para contribuir al Sprint Goal?

2. ¿Qué voy a hacer hoy para contribuir al Sprint Goal?

3. ¿Tengo algún impedimento que me impida entregar?

Mucha gente confunde el Daily Scrum con el Standup Meeting, sin

embargo, este último es una práctica de eXtreme Programming (XP)
orientada a controlar y gestionar el trabajo motivada por un
manager, mientras que el primer término, Daily Scrum, hace
referencia a la práctica que permite la inspección y adaptación a
través de la auto-organización del equipo.
 Luis Felipe Hanco Sucari

3ª ceremonia: Sprint Review

El Sprint Review es la reunión que ocurre al final del Sprint,
generalmente el último viernes del Sprint, donde el product owner y
el Develpment Team presentan a los stakeholders el incremento
terminado para su inspección y adaptación correspondientes. En
esta reunión organizada por el product owner se estudia cuál es la
situación y se actualiza el Product Backlog con las nuevas condiciones
que puedan afectar al negocio.

El equipo ha pasado hasta cuatro semanas desarrollando un

incremento terminado de software que ahora mostrará a
los stakeholders. No se trata de una demostración, sino de una
reunión de trabajo. El software ya ha sido mostrado y validado junto
con el product owner previamente a esta reunión.

Por un lado, se revisará el incremento terminado. Se mostrará el

software funcionando en producción y los stakeholders tendrán la
oportunidad de hacer cuantas preguntas estimen oportunas sobre el
mismo. El software funcionando ha sido validado previamente por
el product owner, que se ha encargado de trabajar con el equipo
durante el Sprint para asegurarse que cumple con la Definition of
Done y, efectivamente, hace que el Sprint Goal sea válido. Si no
existe software funcionando, el Sprint Review carece de sentido,
aunque en ciertas ocasiones y oportunidades se sigue manteniendo.

El Development Team tiene que tener un papel importante en esta

reunión. Muchas veces no es el product owner quien demuestra el
incremento producido, sino que son los propios miembros del
Development Team quienes lo hacen. Es una buena práctica no sólo
el que lo lleven a cabo, sino también el que lo hagan de forma
rotatoria y, tras varios Sprints, hayan participado todos.

El equipo de desarrollo comenta posteriormente qué ha ocurrido

durante el Sprint, los impedimentos que se han encontrado, así como
soluciones tomadas y actualizan a los stakeholders con la situación
del equipo. Por último, el product owner actualiza -con la información
de negocio recibida en esta reunión- el Product Backlog para el
siguiente Sprint.

En contra de lo que comúnmente se cree, el Sprint Review no se trata

de una demo para un cliente o para los stakeholders o incluso para
el product owner, ni es tampoco una reunión para felicitar al Equipo
de Desarrollo. Es una reunión de trabajo, una de las más importantes
porque sirve para marcar la estrategia de negocio. La duración
estimada en el estándar para un Sprint Review es de 8 horas para un
Sprint de 4 semanas, aunque habitualmente estas reuniones se
ejecutan en un entorno de entre 2 y 3 horas.
 Luis Felipe Hanco Sucari

4ª ceremonia: Sprint Retrospective

La retrospectiva ocurre al final del Sprint, justo después del Sprint
Review. En algunos casos y por comodidad de los equipos, se realiza
conjuntamente con el Sprint Planning, siendo la retrospectiva la parte
inicial de la reunión.

El objetivo de la retrospectiva es hacer de reflexión sobre el último

Sprint e identificar posibles mejoras para el próximo. Aunque lo
habitual es que el Scrum Master sea el facilitador, es normal que
distintos miembros del equipo Scrum vayan rotando el rol de
facilitador durante la retrospectiva.

Un formato común es analizar qué ha ido bien durante el Sprint, qué

ha fallado y qué se puede mejorar. Este formato se puede facilitar
pidiendo a los miembros del equipo Scrum que escriban notas –en
post-its- para luego agruparlas y votar aquellos ítems más
relevantes, dando la oportunidad a todos de hablar y expresar sus
inquietudes.

También se utiliza el formato de retrospectiva basado en cinco fases:

1. Preparar el ambiente: un pequeño ejercicio para romper el

hielo.

2. Recolectar información: durante esta fase, se utilizan

actividades para intentar construir una imagen de lo que ha sido
el último Sprint, resultando una imagen conjunta de equipo.

3. Generación de ideas: el equipo intenta generar ideas para

identificar acciones que ayuden a mejorar el rendimiento del
equipo durante el siguiente Sprint.

4. Decidir qué hacer: de las ideas generadas, se proponen

acciones que el equipo pueda implementar en el próximo Sprint.

5. Cierre: Una pequeña actividad de cierre, normalmente unida a

una evaluación de la propia retrospectiva, ayuda al equipo a
decidir hacia dónde dirigirse en próximas ocasiones. Un
recordatorio de la mejora continua.

La duración recomendada por Scrum para un Sprint de 4 semanas es

de un máximo de 3 horas, aunque habitualmente se destina entre 1 y
2 horas a este evento.

5ª ceremonia: Sprint Grooming o Refinement

El refinamiento del Product Backlog es una práctica recomendada
para asegurar que éste siempre esté preparado. Esta ceremonia sigue
un patrón similar al resto y tiene una agenda fija específica en cada
Sprint. Se estima su duración en 2 horas máximo por semana del
 Luis Felipe Hanco Sucari

Sprint. Es responsabilidad del product owner agendar, gestionar y

dirigir esta reunión.

Los participantes de esta reunión son todo el equipo Scrum, así

como cualquier recurso adicional que considere necesario el PO y
que pueda contribuir a aclarar el requerimiento. Es necesario, por
tanto, que antes de la reunión todos conozcan los requerimientos o
historias de usuario que van a ser tratados en la misma y sólo asistan
aquellos cuya presencia sea estrictamente relevante.

Workflow de un Sprint – Scrum

Scrum: roles y responsabilidades

Los 3 roles de la metodología Scrum

Scrum Master, Product Owner y el equipo de desarrollo

Un equipo Scrum suele estar compuesto por grupos de trabajo de

entre 3 a 9 miembros del equipo de desarrollo, más el Scrum Master
y el Product Owner. Cada uno de estos roles tiene diferentes
responsabilidades y debe de rendir cuentas de distinta manera, tanto
entre ellos como para el resto de la organización. La suma de todos
los roles es lo que llamamos Equipo Scrum.

Product Owner
El Product Owner es el encargado de optimizar y maximizar el valor
del producto, siendo la persona encargada de gestionar el flujo de
valor del producto a través del Product Backlog. Adicionalmente, es
fundamental su labor como interlocutor con los stakeholders y
sponsors del proyecto, así como su faceta de altavoz de las peticiones
y requerimientos de los clientes. Si el Product Owner también juega
el rol de representante de negocio, su trabajo también aportará
valor al producto.

Tradicionalmente, se ha entendido la labor del Product Owner como

un gestor de requisitos o un cliente que se encarga de gestionar el
Product Backlog, pero es mucho más que eso. No solo tiene la
responsabilidad de mantener el Product Backlog bien estructurado,
 Luis Felipe Hanco Sucari

detallado y priorizado, sino que además tiene que entender

perfectamente cuál es la deriva que se desea para el producto en
todo momento, debiendo poder explicar y trasmitir a los stakeholders
cuál es el valor del producto en el que están invirtiendo. 

Con cada Sprint, el Product Owner debe hacer una inversión en

desarrollo que tiene que producir valor. Marcar el Sprint Goal de
manera clara y acordada con el equipo de desarrollo, hace que el
producto vaya incrementando constantemente su valor.

Es fundamental otorgar el poder necesario al Product Owner para

que este sea capaz de tomar cualquier decisión que afecte al
producto. En el caso de que el Product Owner no pueda tomar estas
decisiones sin consultarlas previamente con otra persona, deberá ser
investido para tomarlas él mismo, o ser sustituido por esa persona. A
su vez, el Product Owner debe convertirse en el altavoz del cliente,
en el transmisor de las demandas y del feeback otorgado por los
mismos.

Scrum Master
El Scrum Master tiene dos funciones principales dentro del marco de
trabajo: gestionar el proceso Scrum y ayudar a eliminar
impedimentos que puedan afectar a la entrega del producto. Además,
se encarga de las labores de mentoring y formación, coaching y de
facilitar reuniones y eventos si es necesario.

1.    Gestionar el proceso Scrum: el Scrum Master se encarga de

gestionar y asegurar que el proceso Scrum se lleva a cabo
correctamente, así como de facilitar la ejecución del proceso y sus
mecánicas. Siempre atendiendo a los tres pilares del control empírico
de procesos y haciendo que la metodología sea una fuente de
generación de valor.

2.    Eliminar impedimentos: esta función del Scrum Master indica

la necesidad de ayudar a eliminar progresiva y constantemente
impedimentos que van surgiendo en la organización y que afectan a
su capacidad para entregar valor, así como a la integridad de esta
metodología. El Scrum Master debe ser el responsable de velar
porque Scrum se lleve adelante, transmitiendo sus beneficios a la
organización facilitando su implementación.

Puede que el Scrum Master esté compartido entre varios equipos,

pero su disponibilidad afectará al resultado final del proceso Scrum.

El equipo de desarrollo
El equipo de desarrollo suele estar formado por entre 3 a 9
profesionales que se encargan de desarrollar el producto, auto-
organizándose y auto-gestionándose para conseguir entregar un
incremento de software al final del ciclo de desarrollo.
 Luis Felipe Hanco Sucari

El equipo de desarrollo se encargará de crear un incremento

terminado a partir de los elementos del Product Backlog
seleccionados (Sprint Backlog) durante el Sprint Planning.

Es importante que en la metodología Scrum todos los miembros del

equipo de desarrollo conozcan su rol, siendo solo uno común para
todos, independientemente del número de miembros que tenga el
equipo y cuales sean sus roles internos. Cómo el equipo de desarrollo
decida gestionarse internamente es su propia responsabilidad y
tendrá que rendir cuentas por ello como uno solo; hay que evitar
intervenir en sus dinámicas.

Habitualmente son equipos ‘cross-funcional’, capaces de

generar un incremento terminado de principio a fin, sin otras
dependencias externas.

Artefactos Scrum: las 3 herramientas clave de

gestión

Elementos para la gestión de un proyecto de desarrollo de

software
Incremento, Product Backlog y Sprint Backlog
En el marco de trabajo Scrum, denominamos Artefacto a aquellos
elementos físicos que se producen como resultado de la aplicación de
Scrum. Los tres principales artefactos o herramientas Scrum
son: el Product Backlog, Sprint Backlog y el Incremento.

Product Backlog
El Product Backlog es un inventario que contiene cualquier tipo de
trabajo que haya que hacer en el producto: requerimientos, casos de
uso, tareas y dependencias. Es la principal fuente de información
sobre el producto en Scrum, una lista, en cualquier formato, que
contiene todos los requerimientos que necesitamos implementar en el
producto. Esta lista es el resultado del trabajo del Product Owner con
el cliente, los distintos stakeholders, sponsors, comités, etc, y refleja
el estado real del trabajo pendiente de implementar en el producto,
así como el ya realizado. 

El Product Backlog debe ser gestionado en exclusiva por el

Product Owner, siendo su principal función la de priorizar aquellos
elementos que tienen más valor en cada etapa y detallarlos para que
el equipo de desarrollo sea capaz de valorarlos y ejecutarlos.

Al comenzar a utilizar Scrum, no es necesario una lista

completa y exhaustiva de todos los requerimientos. Es
recomendable empezar con los dos o tres requerimientos más
 Luis Felipe Hanco Sucari

urgentes arriba e ir añadiendo elementos conforme vamos

descubriendo más necesidades de nuestro producto.

Un Product Backlog contiene distintos elementos:

 Funcionalidades

 Bugs

 Historias de usuario: una forma de expresar elementos de un

Product Backlog. Para obtener el máximo valor de una historia de
usuarios es necesario expresarlas desde el punto de vista del
usuario.

 Tareas técnicas

 Trabajo de investigación

Sprint Backlog
¿A qué denominamos Sprint Backlog? Se trata de una lista de
elementos en los que trabajar durante la etapa de Sprint. Estos
elementos normalmente se componen de tareas técnicas más
pequeñas que permiten conseguir un incremento de software
terminado.

Todo el trabajo que el Development Team haya seleccionado para

hacer durante el siguiente Sprint pasa al Sprint Backlog. Este
artefacto es un elemento para visualizar el trabajo a realizar
durante cada Sprint y está gestionado por el equipo de
desarrollo. Su propósito es mantener la transparencia dentro del
desarrollo, actualizándolo durante toda la iteración especialmente a
través de los daily Scrums.

El Sprint Backlog permite visualizar, durante cada Sprint, aquellos

elementos que aún no han empezado a desarrollarse, aquellos que sí
y quiénes están trabajando en los mismos, así como aquellos que
están esperando a desplegarse o están completamente terminados.

Este artefacto permite entender cuál es la evolución del trabajo

durante el Sprint, así como hacer un análisis de riesgos. Dado
que cada Sprint tiene una meta específica (p.e. permitir que los
usuarios se registren en la app móvil) y hay elementos seleccionados
del Product Backlog que tienen más o menos valor, el Sprint Backlog
permite analizar hasta donde se ha cumplido el objetivo y que se
podría eliminar. De esta forma, maximizamos el retorno de la
inversión en desarrollo.
 Luis Felipe Hanco Sucari

Incremento
Si Scrum tuviera que ser reducido a una sola cosa, sería a entregar
una pieza de software terminado en cada Sprint. Un Incremento es
el resultado del Sprint, es la suma de todas las tareas, casos de
uso, historias de usuario y cualquier elemento que se haya
desarrollado durante el Sprint y que será puesto a disposición del
usuario final en forma de software, aportando un valor de negocio al
producto que se está desarrollando.

Construir software de manera ágil se basa en hacerlo de

manera iterativa e incremental. Mediante las iteraciones, nos
aseguramos que todo el ciclo de vida del software (planificación,
diseño, desarrollo, testeo y entrega) ocurre en 4 semanas o menos.
Por supuesto, no podemos construir toda la funcionalidad que
queremos en solo cuatro semanas y tenemos que buscar la manera
de ir entregando los componentes necesarios justo a tiempo.

Otros artefactos
El marco de trabajo Scrum destaca los 3 elementos expuestos
previamente como imprescindibles. Sin embargo, hay otros que, a
pesar de no formar parte del core, son necesario para asegurar la
calidad de la metodología Scrum.

 Definition of Done (DoD): La DoD es un documento que

define qué se considera hecho en un equipo Scrum. La idea es
establecer una serie de criterios comunes para especificar cuando
un ítem está completamente terminado y que aplique a todos los
ítems que forman parte del incremento.

 Definition of Ready (DoR): El DoR es un documento que

define cuándo un requerimiento (historia de usuario o similar) se
considera listo para que el equipo de desarrollo pueda
entenderlo, valorarlo e incluirlo en un Sprint Planning con idea de
acometerlo en un Sprint.

 Burndown Chart: El Burndown Chart es un gráfico de trabajo

pendiente a lo largo del tiempo que muestra la velocidad a la que
se están completando los objetivos, requisitos, o historias de
usuarios. Permite extrapolar si el equipo podrá completar el
trabajo en el tiempo estimado.

2. Presenta tu proyecto final en base a la

metodología SCRUM; identificando, resaltando y
complementando con los momentos más
importantes de los tres desafíos anteriores.
Luis Felipe Hanco Sucari