Curso Complementario en:

Gestión de Proyectos en Entornos Ágiles - Énfasis SCRUM

www.udecatalunya.edu.co
Fase de Implementación

La fase de implementación está relacionada a la ejecución de las tareas y actividades para crear el
producto de un proyecto. Este capítulo describe los procesos relacionados con la implementación
de un proyecto bajo el marco Scrum, los cuales son los siguientes:

• Crear entregables: En este proceso, el Equipo Scrum trabaja en las tareas del Sprint Backlog
para crear los entregables del sprint. Generalmente se utiliza un Scrumboard para dar
seguimiento al trabajo y a las actividades que se llevan a cabo. Los problemas que enfrenta el
Equipo Scrum pueden actualizarse en el Impediment Log (o registro de impedimentos).

• Realizar Daily Standup: En este proceso se lleva a cabo diariamente una reunión altamente
focalizada con un time-box asignado y denominada: Daily Standup Meeting. Es un foro para
que el Equipo Scrum se ponga al día sobre sus progresos y sobre cualquier impedimento que
pudieran estar enfrentando.

• Refinar el Backlog Priorizado del Producto: En este proceso constantemente se actualiza y

refina el Backlog Priorizado del Producto. Se puede celebrar una reunión de revisión del
Backlog Priorizado del Producto, donde los cambios y actualizaciones al backlog se analizan
y se incorporan al Backlog Priorizado del Producto, según corresponda.

Crear entregables

En Scrum, la transparencia proviene de las herramientas visiblemente abiertas tales como el

Scrumboard, donde se muestra el avance del equipo.

El equipo utiliza un Scrumboard para planificar y dar seguimiento al progreso durante cada sprint.
El tablero contiene cuatro columnas para indicar el progreso de las tareas estimadas para el sprint:

• una columna “por hacer”: para las tareas que aún no se inician;

• una columna “en progreso” para las tareas que ya iniciaron, pero no se han concluido;

• una columna “en prueba” para las tareas concluidas pero que están en proceso de evaluación,

• una columna de “terminado” para las tareas que se han concluido y evaluado
satisfactoriamente.

Al principio de cada sprint, todas las tareas se colocan en la columna “por hacer” y avanzan según
su progreso. El Scrumboard de preferencia debe mantenerse manualmente en papel o en un
pizarrón, aunque también se puede hacer de manera electrónica en una hoja de cálculo.

El Equipo Scrum debe cambiar y agregarle al Scrumboard según sea necesario, de tal forma que
brinde información visual y control sobre el trabajo en acción según lo acordado y lo
comprometido por el equipo.

1
 Ilustración 1 Scrumboard

Un impedimento es cualquier obstáculo o barrera que reduce la productividad del Equipo Scrum.
Los impedimentos deben identificarse, resolverse y eliminarse si el equipo sigue trabajando
eficazmente. Los impedimentos pueden ser internos en un equipo, tales como un flujo de trabajo
ineficiente o la falta de comunicación, o bien, pudieran ser externos. Algunos ejemplos de
impedimentos externos pudieran ser problemas relacionados a licencias de software o requisitos
de documentación innecesaria

Al final de cada sprint se completa un incremento de producto o entregable. El entregable debe

incluir todas las características y funcionalidades definidas en las historias de usuario que se
incluyen en el sprint y deben haber sido evaluadas satisfactoriamente.

En los casos donde un entregable no cumpla con los criterios de aceptación, este se considera
como entregable rechazado (Rejected Deliverable). Los entregables rechazados generalmente no
se mantienen en una lista por separado, simplemente permanecen en el Backlog Priorizado del
Producto y no se marcan como terminados, de forma que se puedan volver a priorizar en el
proceso de Refinamiento del Backlog Priorizado del Producto y se consideren para su desarrollo
en el siguiente sprint.

Realizar Daily Standup

Los miembros del Equipo Scrum mantienen al tanto a sus compañeros durante las reuniones de
Daily Standup. Esta sesión se denomina Standup (de pie), ya que los miembros permanecen de
pie durante toda la reunión. Los integrantes del equipo discuten los logros y la experiencia del día
anterior. Esta experiencia es una entrada importante al Daily Standup.

2
El Daily Standup es una breve reunión diaria con un time-box de 15 minutos. Los miembros del
equipo se reúnen para dar un reporte sobre su progreso en el sprint y planificar las actividades
del día. La duración de la reunión es muy corta y se busca que todos los integrantes del Equipo
Scrum estén presentes. Sin embargo, la reunión no se cancela o se retrasa si uno o más miembros
no pueden asistir.

Las tres preguntas diarias se utilizan en los Daily Standups, organizados por el Scrum Master,
donde cada miembro del Equipo Scrum brinda información en forma de respuesta a tres
preguntas específicas:

1. ¿Qué he hecho desde la última reunión?

2. ¿Qué tengo planeado hacer antes de la siguiente reunión?

3. ¿Qué impedimentos u obstáculos (si los hubiera) estoy enfrentando en la actualidad?

Al enfocarse en estas tres preguntas, todo el equipo puede tener una comprensión clara de la
situación de trabajo. En ocasiones se pueden discutir otros elementos, pero se mantiene al mínimo
en razón del tiempo asignado que tiene la reunión.

Es muy recomendable que, de ser posible, los miembros del equipo den respuesta a las dos
primeras preguntas en forma cuantificable en vez de dar largas respuestas cualitativas. Los
miembros del equipo pueden organizar reuniones adicionales después del Daily Standup a fin de
abordar temas que requieran de mayor discusión.

Refinar el Backlog Priorizado del Producto

El Backlog Priorizado del Producto se puede actualizar con nuevas historias de usuario, nuevas
solicitudes de cambio, nuevos riesgos identificados o historias de usuario actualizadas o bien, la
re-priorización de las historias de usuario ya existentes.

El Product Owner puede tener varias reuniones por separado con los stakeholders relevantes, con
el Scrum Master y con el Equipo Scrum a fin de asegurarse de contar con la información suficiente
para actualizar el Backlog Priorizado del Producto en el proceso de su refinamiento.

La intención de las reuniones de revisión del Backlog Priorizado del Producto es asegurarse de
que se entiendan las historias de usuario y los criterios de aceptación y de que el Product Owner
la escriba adecuadamente reflejando los requerimientos y prioridades actuales del stakeholder
(cliente); que todos en el Equipo Scrum entiendan las historias de usuario y que las historias de
usuario de mayor prioridad sean bien refinadas de tal forma que el Equipo Scrum las pueda
estimar adecuadamente y avocarse a ellas.

Las reuniones de revisión del Backlog Priorizado del Producto garantizan también que se eliminen
historias de usuario irrelevantes y que se incorporen las solicitudes de cambio aprobadas o los
riesgos identificados en el Backlog Priorizado del Producto.

3
Fase de Revisión y Retrospectiva

La fase de Revisión y Retrospectiva cubre los relacionado a la revisión de los entregables y al

trabajo que se ha realizado y determina las formas para mejorar las prácticas y métodos
implementados para realizar el trabajo del proyecto. Este capítulo describe los procesos
relacionados con la revisión y retrospectiva de un proyecto bajo el marco Scrum, los cuales son
los siguientes:

Demostrar y validar el sprint: En este proceso, el Equipo Scrum demuestra los entregables del
sprint al Product Owner y a los stakeholders relevantes durante una reunión de revisión del
sprint. El propósito de esta reunión es lograr la aprobación y aceptación del Product Owner
respecto al producto o servicio.

Retrospectiva de sprint: En este proceso, el Scrum Master y el Equipo Scrum se reúnen para
discutir las lecciones aprendidas durante el sprint. Dicha información se documenta como
lecciones aprendidas que pudieran implementarse en futuros sprints. Generalmente, como
consecuencia de esta reunión, se pudieran obtener Agreed Actionable Improvements (mejoras
aceptadas).

Demostrar y validar el sprint

Los miembros del equipo principal de Scrum y los stakeholders relevantes participan en las
reuniones de revisión del sprint para aceptar los entregables que cumplan con los criterios de
aceptación de las historias de usuario y rechazar los entregables no aceptables. Tales reuniones
se convocan al final de cada sprint.

El Equipo Scrum demuestra los logros del sprint, incluyendo las nuevas funcionalidades o los
productos elaborados. Esto brinda una oportunidad para que el Product Owner y el(los)
stakeholder(s) inspeccionen lo que se ha completado hasta el momento y determinen si deban
realizarse cambios en el proyecto o en los procesos en sprints posteriores.

Los entregables que cumplen con los criterios de aceptación de las historias de usuario son
aceptados por el Product Owner. El objetivo de un sprint es crear entregables potencialmente
enviables o incrementos del producto que cumplan con los criterios de aceptación definidos por
el cliente y el Product Owner. Estos se consideran entregables aceptados que pudieran ser
entregados al cliente y así se desea.

Se mantiene una lista de entregables aceptados y se actualiza después de cada reunión de revisión
del sprint. Si un entregable no cumple con los criterios de aceptación definidos, no se considera
aceptado y generalmente se llevará a un sprint posterior para corregir cualquier problema. Esto
no es muy recomendable, ya que el objetivo de cada sprint es que los entregables cumplan con
los criterios de aceptación.

Si los entregables no cumplen con los criterios de aceptación, tales entregables se rechazan. Las
historias de usuario asociados a tales entregables rechazados se agregan al Backlog Priorizado

4
del Producto para que tales entregables puedan ser considerados como parte de un sprint
posterior.

Retrospectiva de sprint

La reunión de retrospectiva del sprint es un elemento importante del framework de ―inspección-

adaptación de Scrum y es el último paso en un sprint. Todos los miembros del Equipo Scrum
asisten a la reunión, misma que organiza y modera el Scrum Master.

Se recomienda que asista el Product Owner, aunque no es obligatorio. Un integrante del equipo
se desempeña como secretario y documenta las discusiones y los elementos para acciones a
futuro. Es esencial celebrar esta reunión es un entorno abierto y relajado a fin de fomentar la
completa participación de todos los miembros del equipo. Las discusiones en la reunión de
retrospectiva del sprint abarcan tanto lo que salió mal como lo que salió bien. Los objetivos
primordiales de la reunión son identificar tres elementos específicos:

1) Las cosas que el equipo necesita seguir haciendo: mejores prácticas

2) Las cosas que el equipo necesita empezar a hacer: mejoras en el proceso

3) Las cosas que el equipo necesita dejar de hacer: problemas de proceso y embotellamiento

Estas áreas se analizan y se crea una lista de mejoras accionables aceptadas (Agreed Actionable
Improvements).

Los llamados Agreed Actionable Improvements son el principal resultado del proceso de
Retrospectiva del sprint. Forman parte de la lista de actionable items (elementos accionables) que
ha elaborado el equipo para hacer frente a los problemas y mejorar los procesos a fin de mejorar
también su desempeño en futuros sprints.

Una vez que se han elaborado y refinado, los Assigned Action Items (elementos de acción
asignados) y las fechas límite, el Equipo Scrum puede considerar los puntos de acción para
implementar las mejoras. Cada elemento de acción contará con una fecha límite de conclusión.

Se espera que el Equipo Scrum (equipo auto organizado y empoderado) aprenda de los errores
cometidos durante el sprint y que estas lecciones aprendidas ayuden a mejorar su desempeño en
futuros sprints. Estas lecciones aprendidas también pueden documentarse en las
recomendaciones del Scrum Guidance Body para compartirse con otros equipos de Scrum.

Puede haber varias lecciones positivas aprendidas como parte de un sprint. Estas lecciones
positivas aprendidas son parte clave de la retrospectiva y deben compartirse adecuadamente
dentro del equipo y con el Scrum Guidance Body conforme el equipo avanza hacia una auto-
mejora continua.

5
Fase de Lanzamiento

La fase de lanzamiento (Release) hace énfasis en la entrega al cliente de los entregables aceptados,
así como en la identificación, documentación e internalización de las lecciones aprendidas durante
el proyecto. Este capítulo describe los procesos relacionados con el lanzamiento de un proyecto
bajo el marco Scrum, los cuales son los siguientes:

Transferir entregables: En este proceso se hace la entrega o la transición de los entregables

aceptados a los stakeholders relevantes. La conclusión satisfactoria del sprint se documenta
en un Working Deliverables Agreement (o Acuerdo de entregables funcionales).

Retrospectiva del proyecto: En este proceso, en el cual se concluye el proyecto, los

stakeholders de la organización y los miembros del equipo principal de Scrum se reúnen para
hacer una retrospectiva del proyecto e identificar, documentar e internalizar las lecciones que
se aprendieron. Generalmente, dichas lecciones permiten documentar las Agreed Actionable
Improvements e implementarlas en futuros proyectos.

Transferir entregables

Los mecanismos de desplazamiento o de transferencia en cada organización tienden a ser

diferentes basados en su respectiva industria, en los usuarios meta y el posicionamiento.
Dependiendo del producto a entregarse, el desplazamiento puede ser remoto o puede incluir el
envío físico o la transición de un artículo.

Debido a que la implementación tiende a implicar un alto nivel de riesgo, las organizaciones
suelen tener mecanismos de implementación bien definidos y establecidos, con procesos
detallados para garantizar el cumplimiento de todas las normas aplicables y medidas de garantía
de calidad. Estas podrían incluir aprobaciones finales de los representantes específicos de gestión,
mecanismos de aprobación de usuario y directrices para la funcionalidad mínima de un
lanzamiento.

Los entregables que cumplen con los criterios de aceptación, reciben el cierre formal del negocio
y la aprobación formal por parte del cliente o del patrocinador. Obtener la aceptación formal del
cliente es fundamental para el reconocimiento de los ingresos. La responsabilidad de obtener
dicha aceptación se define en las políticas de la empresa y no es necesariamente la
responsabilidad del Product Owner.

El entregable final enviable (del inglés: shippable deliverable) para el cual fue sancionado el
proyecto se conforma a medida que se crean los incrementos de los productos, estos se integran
continuamente a los incrementos anteriores, por lo que hay un producto potencialmente
entregable disponible en todo momento a lo largo del proyecto.

6
Retrospectiva del proyecto

La reunión de cierre en un proyecto scrum se llama retrospectiva. Incluye el equipo ágil, el

propietario del producto y las partes interesadas clave. Alienta a los participantes a revisar:

Lo que salió bien

Lo que se podría haber hecho mejor

Esta evaluación incluye el trabajo sobre el producto y también los procesos, el nivel de
colaboración dentro y fuera del equipo, y otras áreas que influyen en la eficacia de la entrega.

La reunión de retrospectiva del proyecto es una reunión para determinar las formas en las que la
colaboración y eficacia del equipo puede mejorarse en futuros proyectos. También se analizan las
oportunidades positivas, negativas y potenciales para mejorar. Esta reunión no tiene un time-box
asignado y se puede llevar a cabo en forma presencial o en formato virtual. Durante la reunión,
se documentan las lecciones aprendidas y los participantes buscan oportunidades para mejorar
los procesos y atender las ineficiencias.

Es una reunión de inspección para sacar conclusiones con vistas a futuros proyectos. Tiene un
enfoque distinto a la retrospectiva que se hace tras concluir cada una de las iteraciones. Es un
momento en el que, de manera indirecta, se produce un agradecimiento entre los compañeros.

Es una dinámica de aspectos positivos y negativos que ayuda al equipo a recolectar todo aquello
que pueda aportar un mejor desarrollo de proyecto en futuras ocasiones. Permite la unión del
equipo, ya que se genera un ambiente de confianza y empatía.

Deberían participar los involucrados en el proyecto desde que se hizo la propuesta a nivel
económico, técnico y de estimación de esfuerzo.

7
 Bibliografía

• Agile Manifesto.

• Webpage; Agile Alliance; Scrum Alliance; Project Management Institute.

• Project Management Institute (2021) Guía de los Fundamentos para la Dirección de Proyectos
(Guía del PMBOK®). Séptima Edición, Project Management Institute Inc. EUA

• Project Management Institute (2017) Guía Práctica de Ágil. Primera Edición, Project
Management Institute Inc. EUA

• Lledó, P. (2020) Profesional Ágil: Apuntes para la Certificación PMI-ACP®. 1ra. Edición, Pablo
Lledó, Canadá.

• Ken Schwaber & Jeff Sutherland: La Guía Scrum, La Guía Definitiva de Scrum, Las Reglas del
Juego. (2020).

• A Guide to the Scrum Body of Knowledge (SBOK™ Guide 2017). Scrumstudy.

8
 © UdeCa t al u ña 2022

Todo s lo s de r echo s r e s e rv ado s .

P r ohibida la r ep r od u cción t o t al o pa r cial de lo s con t enido s
s in el pe r mi s o e x cl us i v o de UdeCa t al u ña

Bogo t á - Colombia .

UdeCataluña