Ágil

 Ciclos iterativos
 Individuos e interacciones.
 Producto funcionando (entrega de valor).
 Colaboración con el cliente.
 Respuesta ante el cambio.
 Los marcos ágiles están basados la descentralización del trabajo, romper con las
estructuras jerárquicas tradicionales, para ello es clave la autogestión y la
generación de valor. Esto no sería posible sin la automotivación de los equipos
por lo que las opciones 3 y 5 son correctas para una metodología ágil.

DIFERENCIAS AGIL Y TRADICIONALES

En los marcos tradicionales por otra parte se sigue un orden predeterminado para la
ejecución de actividades, primero hay que planear, ejecutar, validar y cerrar, por
ejemplo. Cada paso precede al anterior. De acuerdo a esto, es clave hacer una
planeación exhaustiva y detallada, todo aquello que quede fuera de la planeación no
será tenido en cuenta en etapas posteriores.

 En los métodos tradicionales de gestión de proyectos, los usuarios aclaran sus

expectativas; el Project Manager define dichas expectativas en términos
cuantificables y obtiene el acuerdo de los usuarios. Después de una
planificación detallada, el equipo del proyecto desarrolla el producto durante un
período acordado. Si hay necesidad de cambiar alguno de los criterios
acordados, los cambios se pueden realizar sólo a través de un sistema formal de
gestión de cambio, en el cual se estima el impacto de los cambios y el Project
Manager consigue la aprobación de todos los stakeholders relevantes

 En Scrum, sin embargo, el Product Owner colabora con los Developers y define
los criterios de aceptación para las historias de usuario en relación con el
producto que se debe entregar. Los Developers, después desarrollan el
producto a partir de una serie de iteraciones cortas denominadas sprints. El
Product Owner puede realizar cambios en los requisitos para mantenerse al
 ritmo de las necesidades del usuario y estos cambios pueden ser abordados por
los Developers, ya sea al concluir el actual sprint, o al incluir los requisitos
ajustados en el próximo sprint, ya que cada uno es de muy corta duración

¿Qué es Scrum?

Scrum es un marco de trabajo (framework) a través del cual las personas pueden
abordar problemas complejos generando soluciones adaptables y creativas con
productos de máximo valor.

El marco Scrum solo define la teoría, es decir, los elementos más fundamentales para
su funcionamiento, contando con flexibilidad suficiente para agregar  procesos,
técnicas y métodos según se requiera.

En lugar de proporcionar instrucciones detalladas, los postulados de Scrum guían las

relaciones e interacciones de las personas.

Scrum está diseñado para funcionar en proyectos y organizaciones de cualquier

tamaño. 

Cuando un producto es muy grande y un solo Equipo Scrum no es suficiente para

desarrollar todo el trabajo, será necesario contar con múltiples equipos. Algunas de las
consideraciones que se deben tener en cuenta para realizar la distribución de los
equipos son:

 El tamaño óptimo del equipo Scrum es de menos de 10 miembros

 Hasta donde sea posible, se debería contar con un solo Product Owner para el
producto.
 Si varios equipos participan en la construcción de un  mismo producto, el
tamaño de esos equipos debería mantenerse equilibrados. 
 Los equipos multifuncionales avanzan más rápido y generan menos
dependencias
 No deberían cambiarse los miembros de equipo durante la ejecución de su
trabajo. 
El marco Scrum resalta el hecho de hacer planificaciones muy detalladas desde el
inicio, y es esa, una de las ventajas que tiene respecto a un marco tradicional,
haciéndolo un modelo más natural.

Sin embargo es importante que desde el inicio si se identifique el Product Goal

(Objetivo de Producto)

Scrum es un marco ágil que se enfoca en la entrega de valor al cliente de manera

incremental y adaptativa. La planificación es importante en Scrum, pero no se planifica
todo el proyecto por adelantado en detalle. En cambio, el equipo se enfoca en entregas
de valor prioritarias para el cliente y se adapta a medida que se aprende más sobre el
producto y los requisitos del cliente.

Scrum sugiere bloques de tiempo para la ejecución de los eventos o ceremonias que
tendrán lugar durante la ejecución del proyecto, no es una responsabilidad del Product
Owner definir dichas duraciones

El manifiesto ágil, está compuesto por 12 principios. Se subrayan en negrita los que
responden a las opciones de la pregunta

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo.
Los procesos Ágiles aprovechan el cambio para proporcionar ventaja
competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos
meses, con preferencia al periodo de tiempo más corto posible. (Opción C)
4. Los responsables de negocio y los desarrolladores trabajamos juntos de
forma cotidiana durante todo el proyecto. (Opción B)
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que
darles el entorno y el apoyo que necesitan, y confiarles la ejecución del
trabajo. (Opción D)
6. El método más eficiente y efectivo de comunicar información al equipo de
desarrollo y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
 8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-
organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.

Manifiesto Ágil

Manifiesto por el Desarrollo Ágil de Software

1. Individuos e interacciones sobre procesos y herramientas

2. Software funcionando sobre documentación extensiva

3. Colaboración con el cliente sobre negociación contractual

4. Respuesta ante el cambio sobre seguir un plan

 Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la
izquierda.

HISTORIA

En 1986, Hirotaka Takeuchi e Ikujiro Nonaka escribieron un artículo en la Harvard

Business Review, hablando sobre el enfoque que utilizaban algunas compañías para el
desarrollo de sus productos. En este artículo también se realizó por primera vez la
comparación de este enfoque de desarrollo con Scrum (la jugada de rugby), que es de
donde se origina el nombre Scrum. En la decada de lo 80´s, estos señores definieron
una nueva forma de ejecutar proyectos, donde hicieron mucho énfasis en el trabajo en
equipo y la colaboración entre los integrantes. Asimilaron esta nueva técnica al juego
de Rugby donde el equipo trabaja como uno solo para llegar al campo contrario
El concepto de Scrum tiene su origen en un estudio de 1986 sobre los nuevos procesos
de desarrollo utilizados en productos exitosos en Japón y los Estados Unidos (Canon,
Xerox, Honda, HP y otros).

Hirotaka Takeuchi e Ikujiro Nonaka definieron Scrum como una estrategia de

desarrollo flexible e incluyente en la que el equipo trabaja como una unidad para
alcanzar un objetivo común.

En  1995 Ken Schwaber y Jeff Sutherland presentaron una definición formal de Scrum
en la conferencia OOPSLA  (Object-Oriented Programming, Systems, Languages &
Applications)

Los pilares Scrum:

 Auto-gestión
 Simplicidad
 Enfoque en el valor para los interesados
 Disciplina
 Desarrollo iterativo

Teoría de Scrum

Scrum combina Scrum emplea un enfoque iterativo e incremental para optimizar la

previsibilidad y controlar el riesgo Los eventos funcionan porque se basan en los
pilares empíricos de Scrum de transparencia, inspección y adaptación.

Transparencia: El proceso y el trabajo deben ser visibles para aquellos que realizan el
trabajo (equipo Scrum), así como para los que reciben el trabajo (cliente y partes
interesadas). Con Scrum, las decisiones importantes se basan en el estado percibido de
los artefactos. Los artefactos que tienen poca transparencia pueden conducir a
decisiones que disminuyen el valor y aumentan el riesgo. 

Los aspectos significativos del proyecto deben ser visibles para las partes interesadas,
esto hace parte de la Transparencia.
Scrum toma un enfoque hacia la transparencia, permitiendo que las decisiones para
optimizar el valor del producto y controlar el riesgo se tomen basadas en el estado
percibido de los artefactos (principalmente el Product Backlog y el Sprint Backlog). En la
medida que se fortalezca la transparencia, estas decisiones tendrán unas bases
sólidas; y, en la medida que los artefactos no sean transparentes, las decisiones
pueden ser erróneas.

Los aspectos significativos del proyecto deben ser visibles para las partes interesadas.
La transparencia requiere que dichos aspectos sean definidos por un estándar común,
de tal modo que los observadores compartan un entendimiento común de lo que se
está viendo. Transparencia-Todos los radiadores de información tales como un Tablero
de Scrum (del inglés Scrumboard) y una Gráfica del trabajo pendiente del sprint (del
inglés Sprint Bumdown Chart) se comparten, lo que conduce a un ambiente de trabajo
abierto. Las respuestas b y d no es completado por el rol del Product Owner, al
contrario, lo ejecuta el Scrum Master o los Developers, en cuanto a la respuesta c, es
falsa, es por esto, que la mejor respuesta es la a

En Scrum:

 Se planifica al inicio del proyecto (planeación de alto nivel del proyecto) , y en

antes de iniciar cada sprint en la reunión de planificación del Sprint. 
 La documentación en Scrum debe ser mínima ( por ejemplo la documentación
técnica y de usuario final).
 Las estimaciones la hace el equipo Scrum durante la reunión de planificación

En la práctica "Definir el objetivo del producto" se estructura el objetivo del producto,

explicando las necesidades empresariales que el proyecto busca satisfacer,
considerando además el alcance, el tiempo, el presupuesto y la calidad esperada por el
patrocinador/cliente del proyecto.

Para asegurar que un proyecto cumpla con los requisitos de calidad, Scrum adopta un
enfoque de mejora continua mediante el cual el equipo aprende de sus experiencias y
de la participación de los socios, a fin de actualizar constantemente la lista priorizada
de pendientes del producto con cualquier cambio de requisitos. Dicha lista nunca se
completa sino hasta el térnino o la conclusión del proyecto. Cualquier cambio en los
requisitos debe reflejar los cambios en el entorno empresarial, ya sean internos o
externos, y el equipo se debe adaptar continuamente a fin de alcanzar esos requisitos.

Criterios de Aceptación

 Los Criterios de Aceptación (detalle técnico) son únicos para cada tarea o

requerimiento, mientras que los Criterios de Terminado son genéricos
(transversales). Product Ownwe junto con los desarrolladores o developers
 Concretamente en Scrum, se los define como un conjunto de sentencias
redactadas de tal manera que conduzcan a una respuesta clara de
“aceptado/rechazado”. Detallan las especificaciones técnicas de cada Historia de
usuario o Tarea.
 Los criterios de aceptación de las historias de usuarios definen los requisitos de
como debe comportarse el sistema en función de las acciones que se ejecuten
por parte de usuario que usará dicho sistema

Hay una diferencia clave entre los "Criterios de Terminado" y los "Criterios de
Aceptación", mientras que los Criterios de Aceptación son únicos para las
Historias de Usuario individuales, los Criterios de Terminado son una serie de
reglas aplicables a todas las historias de usuario en un determinado sprint.

Un riesgo se define como un evento incierto, que puede afectar los objetivos de un
proyecto y puede contribuir a su éxito o fracaso. Los riesgos con resultado positivo se
llaman oportunidades y los negativos se llaman amenazas

Durante la ejecución del proyecto, cualquier miembro del equipo del proyecto puede
identificar los riesgos y el gerente del proyecto o la dependencia encargada de gestión
de proyectos o el personal de apoyo a los proyectos puede actualizarlos en la lista de
riesgos o en el registro de riesgos. En Scrum, cualquier miembro del equipo puede
identificar riesgos y el Product Owner puede actualizar los riesgos identificados en la
lista priorizada de pendientes del producto del riesgo ajustado
Compromiso: Definición de terminado (DoD)

 Es una descripción formal del estado del Incremento cuando cumple con las
medidas de calidad requeridas para el producto.
 La Definición de terminado (Criterios de terminado) es definida en conjunto por
el Equipo Scrum
 La DoD puede ser definida para cada incremento o para el producto en general
 Si un incremento no cumple con la Definición de Terminado, no puede ser
aprobado

La Etapa 1. Inicio del proyecto, incluye las siguientes prácticas:

 - Definir el objetivo del producto

 - Conformar el equipo Scrum 

 - Construir el Product Backlog

 - Priorizar el Product Backlog

 - Definir la arquitectura del producto

 - Definir el cronograma de entregas

La etapa de implementación (despliegue) esta compuesta por 2 prácticas

 Planificación de la Implementación
 Implementación de Entregables

Desarrollo Iterativo

 Scrum fue diseñado para que el desarrollo del proyecto se realice por
iteraciones, también conocidas como Sprints.
 El método iterativo es flexible y abierto a los cambios, lo que permite adaptar el
proyecto a las necesidades cambiantes del mercado, del cliente o de la
organización.

Las prácticas incluidas dentro de Diseño del producto son:

  1. Construir el Product Backlog

 2. Priorizar el Backlog

 3. Definir la Arquitectura de Producto

Algunas de las ventajas principales de la utilización de Scrum en cualquier proyecto

son:

 - Retroalimentación continua: la retroalimentación continua se proporciona a

través de los procesos de realizar el Scrum, demostración y validación del sprint.

 - Ritmo sostenible: los procesos Scrum están diseñados de tal manera que las
personas involucradas pueden trabajar a un ritmo sostenible que, en teoría, se
puede continuar indefinidamente.

 - Responsabilidad colectiva: el proceso de aprobación, estimación y asignación

de historias de usuarios permite que los miembros del equipo hagan suyo el
proyecto y su trabajo conlleve a una mejor calidad

 Flexibilidad mediante equipos interfuncionales - El Product Owner ayuda a la

selección del Equipo interfuncional

 Flexibilidad mediante la priorización basada en valor al cliente - El Product

Owner prioriza la Lista de Pendientes del Producto (Product Backlog) basado en
elementos que ofrecen el máximo valor a los clientes

 Flexibilidad mediante el desarrollo iterativo del producto - Si pedidos de

cambios menores son presentados por los patrocinadores/clientes, el Product
Owner puede aprobarlos

 Deuda técnica

Algunas de las causas de la deuda técnica pueden ser:

 1. Rápida solución y elaboración de entregables que no cumplan con tos
estándares de calidad, seguridad, metas arquitectónicas a largo plazo, etc
2. Evaluación inadecuada o incompleta
3. Documentación inadecuada o incompleta
4. Falta de coordinación entre los distintos miembros del equipo, o si hay
diferentes equipos de Scrum que empiezan a trabajar en forma aislada con
menor enfoque en la integración final de los componentes requeridos para
realizar un proyeclo o programa exitoso
5. Intercambio deficiente del conocimiento empresarial y de procesos entre los
socios y equipos del proyecto
6. Demasiado énfasis en los objetivos del proyecto a corto plazo en vez de
objetivos a largo plazo en la empresa. Esta supervisión puede resultar en una
baja calidad de los entregabtes funcionales que pudiera incurrir en
considerables costos de mantenimiento y actualización

El Equipo Scrum

El Equipo Scrum consiste en un Product Owner,  un Scrum Master y los

Desarrolladores.
Se trata de una unidad cohesionada de profesionales centrados en un objetivo a la vez:
el Objetivo de Producto (Product Goal).

El tamaño óptimo del Equipo es de máximo 10 miembros, esto le permite ser lo

suficientemente pequeño como para permanecer ágil y lo suficientemente grande
como para poder completar una cantidad significativa de trabajo.

Cuando se trata de 1 proyecto y 1 producto, debe haber sólo 1 Product Backlog y 1

Product Owner. Esto hace que la priorización y la rendición de cuentas sean más
sencillas. Recuerde que el Product Owner no gestiona el equipo

 Los Equipos más pequeños podrían encontrar limitaciones en cuanto a las

habilidades necesarias durante un Sprint, haciendo que el Equipo no pudiese
entregar un Incremento que potencialmente se pueda poner en producción
 Tener más de diez (10) miembros en el equipo requiere demasiada coordinación
 Los Equipos grandes generan demasiada complejidad como para que un
proceso empírico pueda ser de utilidad
Valores del equipo, responsabilidad del Scrum Master promoverlos

Es importante que entre los miembros del equipo se genere y mantenga una filosofía
basada en valores que fomenten la confianza, la comunicación y la entrega de
resultados.

A continuación, se relacionan los valores que deberían existir en un equipo Scrum:

1. Compromiso
2. Enfoque
3. Apertura
4. Respeto
5. Coraje

¿Cómo se comunican las personas en el equipo Scrum?

 El cliente le proporciona información y requisitos al Product Owner

 El Product Owner comunica los requerimientos priorizados a los
desarrolladores, crea el Product Backlog y los criterios de aceptación
 El Scrum Master asegura un entorno de trabajo adecuado para los Developers
 Los desarrolladores le muestran los incrementos del producto al Product Owner
 El Product Owner garantiza que se realizan entregas constantes al cliente.

Product Owner

¿Quién es el Product Owner?

1. En un proyecto, es altamente recomendable que sea un único Product Owner.

2. Es quién negocia todos los aspectos del proyecto (Financieros, requerimientos, etc.)

3. Se le asocia comúnmente con el rol “Gerente del Proyecto” (Pero NO son lo mismo)

4. Es el único que debería tener contacto directo con el cliente.

Ser Product Owner no es un trabajo de tiempo completo, y la cantidad del tiempo

requerido depende del proyecto y del ambiente. Ellos necesitan gastar el tiempo que
sea necesario para realizar todas sus responsabilidades, lo que resulta en maximizar el
valor

El Product Owner desempeña un papel importante en la Retrospectiva del Sprint.

Participa en la revisión del último Sprint, contribuye a la identificación de las
lecciones aprendidas, y puede sugerir mejoras a la Definición de terminado (DoD),
que es una lista de los criterios que se deben cumplir para que un producto se
considere "terminado".

El Product Owner tiene que interpretar las entradas y las necesidades de los proyectos
de los socios para crear la lista priorizada de pendientes del producto (Product
Backlog). Por lo tanto, mientras se priorizan las historias de usuario en la lista
priorizada de pendientes del producto, se consideran los siguientes tres factores: 1.
Valor 2. Riesgo o incertidumbre 3. Dependencias. De esta forma, la priorización resulta
en entregables que satisfacen los requisitos del cliente con el objetivo de ofrecer el
máximo valor de negocio en el menor tiempo posible

El Product Owner comunica los requerimientos priorizados a los desarrolladores, crea

el Product Backlog y los criterios de aceptación

Es una lista ordenada de todos los elementos que serán desarrollados, y es la única
fuente de requisitos para cualquier cambio a realizarse en el producto.

•El Product Backlog enumera todas las características, funcionalidades, requisitos,

mejoras y correcciones que se deban hacer sobre el producto para entregas futuras.

•Los elementos del Product Backlog tienen como atributos la descripción, la prioridad,
la estimación y el valor para negocio.

Una de las funciones principales del Product Owner es revisar junto a su equipo y otros
interesados clave el incremento del producto durante la Revisión del Sprint y así
evaluar el grado de cumplimiento respecto al objetivo del sprint definido.

Product Owner (Dueño del Producto)

  Es el representante de todos los interesados (stakeholders) en los resultados del
producto
 Actúa como interlocutor único ante el equipo Scrum, con autoridad para tomar
decisiones.
 Es el encargado de garantizar los resultados del producto.
 El Product Owner (P.O) es una única persona, no un comité.
 Es considerado como “La voz del cliente”

Son responsabilidades del Product Owner:

 Determina los requisitos del producto y da inicio a las actividades del proyecto
 Asegura que el producto responda a las necesidades del cliente y partes
interesadas.
 Representa a los usuarios del producto o servicio con un profundo
conocimiento de la comunidad de usuarios e interesados.
 Asegura los recursos necesarios para que el equipo pueda trabajar.
 Centrarse en la creación de valor y en general de Retorno de la Inversión (ROI).
 Evaluar la viabilidad y garantizar la entrega del producto o servicio.
 Es quién negocia todos los aspectos del proyecto (Financieros, requerimientos,
etc)
 El Product Owner comunica los requerimientos priorizados a los
desarrolladores, crea el Product Backlog y los criterios de aceptación.
 Dirige y participa en la reunión de planificación del Sprint.
 Participa en la reunión de revisión del Sprint ( Durante esta reunión el Product
Owner aprueba/rechaza el incremento construido.)
 Líder servicial - El liderazgo servicial implica escuchar cuidadosamente, tener
empatía, comprometerse al servicio, tener visión, y compartir el poder y la
autoridad con los miembros del equipo. Este estilo de liderazgo logra resultados
centrándose en las necesidades del equipo.
 La velocidad es un concepto relativo que no se puede comparar con otros
proyectos y otros equipos. Incluso cuando se considera dentro del proyecto,
aunque es importante, no es una medida clave del éxito. El Product Owner debe
centrarse en la cantidad de valor que se entrega, y cualquier otra cosa puede ser
engañosa

Técnicas Product Owner

Los Mockups
También llamandos prototipos, Permiten que el equipo entienda mejor a los usuarios,
sus necesidades y expectativas

Herramientas del producto Owner para dar seguimiento al proyecto

 Un tablero de Scrum
 Retroalimentación frecuente de los socios durante varios procesos Scrum
 Demostración del incremento del producto

Scrum Master

De acuerdo a la pregunta formulada, teniedo en cuenta que el proyecto cuenta con 7

equipos de desarrollo, lo ideal sería tener 7 Scrum Masters, uno para cada equipo, ya
que esto permite una mejor gestión de cada equipo y garantiza una mayor eficiencia
en el proyecto. No obstante, en algunos casos, se podría contar con un Scrum Master
para dos o tres equipos de desarrollo, dependiendo de la complejidad del proyecto y la
capacidad del Scrum Master para manejar múltiples equipos.

 Es responsable de evaluar la viabilidad y de garantizar la entrega del producto o

servcio

Funciones del Scrum Master

El Scrum Master es un facilitador, responsable de asegurar que Scrum es entendido y

adoptado por el equipo y en general por la organización, ayudando a todos a
comprender la teoría y prácticas de Scrum.

 El Scrum Master es responsable de la efectividad del Equipo Scrum propiciando

la mejora continua.
 Los Scrum Masters son verdaderos líderes que sirven al Equipo Scrum y a la
organización en general.

 Coordinar los eventos de Scrum relacionados con el Sprint

 Mantener la motivación del equipo
 Gestionar los impedimentos que puedan afectar al equipo
 Promover las prácticas de Scrum en la organización
 Recolectar métricas que le permitan mejorar la productividad del equipo.
 Asistir al Product Owner en la toma de decisiones, gestión de riesgos, etc.
Habilidades del Scrum Master

Como scrum master (SM) es necesario brindar soporte y soluciones al equipo scrum y
a la organización en general.

Para esto debe contar con aptitudes y actitudes que contribuyan al liderazgo, a
continuación se muestran algunas habilidades que tiene un SM.

1. Eliminador de impedimentos (Un impedimento es cualquier cosa que obstruye

el flujo de trabajo generando retrasos. Los impedimentos pueden ser internos
del equipo, tales como flujo de trabajo ineficiente o falta de comunicación,
o pueden ser externos cuando son atribuibles a insumos que debe entregar el
cliente, o incluso por algún incumplimiento de parte de los proveedores.), El
marco de Scrum, con su transparencia facilita la rápida y fácil identificación de
los obstáculos (impedimentos) que puedan afectar al proyecto.Los
impedimentos deben ser registrados formalmente por el Scrum Master en
un log de impedimentos, y pueden ser discutidos durante las reuniones
diarias y las Reuniones de Revisión del Sprint

1. Resolutor de conflictos
2. Maestro
3. Facilitador
4. Coach y mentor

El Scrum Master como Maestro

El SM debe animar al equipo para aprender nuevos conocimientos, esto permite

que el equipo sea multidisciplinario y no se estanque fácilmente.

Es necesario que el Scrum Master: 

 Tenga seguridad para guiar al equipo

 Desarrollar comunicación abierta y transparente
 Establecer reglas claras con el equipo
  Involucrarse en todas las actividades (no como supervisor, sino como apoyo)
 Recordar que trabajas con personas no robots 

El Scrum Master como facilitador

El SM logra que todas las acciones, procesos y tareas sean fáciles de entender para el
equipo, además de asegurar que se cuente con el entorno y herramientas necesarias
para trabajar.

Es necesario que actúe de manera:

 Colaborativa: para guiar al equipo en sus funciones

 Neutral: para entender las necesidades de todas las partes sin tener
preferencia alguna
 Responsable: garantizando la disciplina y la efectividad del equipo

El Scrum Master como Coach y mentor

 Coach: Su enfoque está en enseñar a los demás a mejorar

 Mentor: Su enfoque está en ayudar y guiar a quienes tienen menos experiencia

El Scrum Master sirve al Equipo Scrum de varias maneras, incluyendo:

 Capacitar a los miembros del equipo en autogestión y multifuncionalidad;

 Ayudar al Equipo Scrum a centrarse en la creación de incrementos de alto valor
que cumplan con la definición de Terminado (Done)
 Gestionar la eliminación de impedimentos
 Asegurar que todos los eventos de Scrum se lleven a cabo y sean positivos,
productivos, y se ejecuten dentro de los tiempos (time-box)
 Es responsable de evaluar la viabilidad y de garantizar la entrega del producto o
servicio

El servicio del Scrum Master a los Developers

El Scrum Master sirve a los Developers de varias formas, incluyendo:

  Ayudar a los Developers a crear productos de alto valor
 Eliminar impedimentos para el progreso de los Developers (Solucionador
de problemas)
 Ayuda a resolver los conflictos que puedan suceder al interior del equipo
 Facilitar los eventos de Scrum según se requiera o necesite
 Guiar a los Developers en entornos organizacionales en los que Scrum aún no
haya sido adoptado y entendido por completo

Enfoque en el valor para los interesados

En Scrum, la máxima prioridad es satisfacer a los interesados desde el inicio y

frecuentemente entregando el máximo valor posible.

¿Cómo se asegura el enfoque en el valor?:

 Entregando incrementos “Terminados” (Definición de Terminado)

 Priorizar los elementos de mayor valor (en el Product Backlog)
 Validar los prototipos con los interesados antes del desarrollo
 Validar los incrementos con los interesados (En la Revisión del Sprint) 

TECNICAS

Speed Boat es una técnica que se puede utilizar para llevar a cabo la Retrospectiva del
Sprint. Los miembros del equipo hacen que son tripulantes en un speed boat.

 El barco debe llegar a una isla, lo cual es simbólico de el objetivo del producto
 Los remos ayudan a avanzar (cosas que hacemos bien)
 Los motores les ayudan a llegar a la isla (cosas por adoptar)
 Los anclajes les impiden llegar a la isla. (cosas que hacemos mal)

Scrum Board

El Scrum Board o tablero Scrum es una herramienta visual que permite al equipo de
desarrollo mantener la comunicación constante, fortaleciendo el conocimiento de las
actividades que se están desarrollando y en qué etapa del proceso están cada una de
ellas. El Scrumboard se actualiza con regularidad a medida que el equipo produce más
trabajo. Sin embargo, al final del Sprint, el Scrum Board se restablecerá o borrará y un
nuevo Scrum Board se creará para el próximo Sprint.

Las siguientes consideraciones sobre el Scrum Board son verdaderas:

 El Scrum Board generalmente se actualiza durante la reunión diaria, cada

integrante de los Developers tiene autonomía para actualizar su conjunto de
elementos asignados en el Sprint Backlog. Por tanto, son los Developers quienes
actualizan el Scrum Board (tablero Scrum) y el Scrum Master se encarga de
hacerle inspección.
 Está compuesto por 4 columnas: Pendiente, En progreso, En prueba (En
revisión), "Terminado".
 Existen herramientas tecnológicas para gestionar el scrum board como Jira y
Trello. También puede ser mantenido de manera física con un tablero en donde
se pegan "sticky notes".

La actualización de este, lo hace el Scrum Master una vez terminada la reunión diaria,
con la información suministrada por los Developers

Permite planificar, rastrear y monitorear el progreso del trabajo

Burndown Chart del sprint

Es un emisor de información que muestra la cantidad de trabajo pendiente que queda

en el Sprint actual.
El emisor del gráfico en las dos dimensiones:

 El eje vertical se construye a partir de la sumatoria de puntos de historia a

desarrollar en el sprint.
 El eje horizontal corresponde a la duración del sprint en días hábiles.

Aclaraciones Burndown Chart

 Una posible variación es que el Burnup chart muestre el trabajo completado en

sprint.
 Los Developers y su Scrum Master son los responsables de la actualización del
Burndown Chart
 Por lo general la actualización se realiza durante los scrum diarios.

Registro de obstáculos/impedimentos

 El registro de obstáculos, o registro de impedimentos es un listado en el que se

registran todos los obstáculos que se presentan en el equipo, con su respectiva
gestión y resolución.
 El Scrum Master lo actualiza según lo que comunican los Developers (por lo
general en los Scrum Diarios).
 En algunas organizaciones este listado es global y sirve como base de
conocimiento para todos los integrantes de los distintos equipos Scrum.

No es para compartir con los socios

Desarrolladores (Developers)

Los Desarrolladores son las personas que se comprometen a crear un Incremento

utilizable cada Sprint. Las habilidades específicas que necesitan los Desarrolladores
son a menudo amplias y varían según el dominio de trabajo.

Los Desarrolladores son responsables de:

 Crear un plan para el Sprint: el Sprint Backlog

 Asegurar la calidad con el cumplimiento de la Definición de Terminado
(Definition of Done)
  Adaptar su plan de trabajo diario para alcanzar el Objetivo del Sprint (Sprint
Goal)
 Responsabilizarse del trabajo.

Nota: Se llaman “Desarrolladores”, porque desarrollan el producto (no necesariamente

software)

DEVELOPERS

Los desarrolladores, son quienes determinan la complejidad del trabajo, así como la
duración de los Sprints (claro, en consenso con el Scrum Master y el Product Owner)

PRODUCT OWNER

• Es el representante de todas las personas interesadas (stakeholders) en los

resultados del proyecto . actúa como interlocutor único ante el equipo Scrum, con
autoridad para tomar decisiones.

• Es el rol encargado de garantizar los resultados del proyecto.

• El Dueño de Producto (P.O) es una única persona, no un comité.

• Este rol es considerado como “La voz del cliente"

¿Qué son los artefactos?

Los artefactos de Scrum representan el trabajo o el valor. Están diseñados para

maximizar la transparencia de la información clave.

Cada artefacto contiene un compromiso para asegurar que proporciona información

relevante y de esta manera se pueda medir el progreso:

 Para el Product Backlog el compromiso es el Objetivo del Producto (Product

Goal).
 Para el Sprint Backlog el compromiso es el Objetivo del Sprint (Sprint Goal).
 Para el Incremento es la Definición de Terminado (Definition of Done).
  Los Developers poseen el Sprint Backlog y el Product Owner posee el Product
Backlog

Historias de Usuarios

Las historias de usuario contienen requerimientos y funcionalidades que desea el

usuario final.

Una historia de usuario incluye tres elementos sobre el requerimiento:

1. ¿Quién?, en donde se indica el Rol que tiene un requerimiento, y se hace a través de

la palabra "Como...",

2. ¿Qué?, indica el requerimiento del usuario a través de la palabra "Quiero..." y

3. ¿Por qué?, el cual corresponde a los beneficios que desea el usuario expresados a
través de la palabra "Para..." Los requerimientos expresados en las historias de usuario
son oraciones breves, sencillas y fáciles de entender

Una vez que el Product Owner ha recibido los requerimientos del negocio del cliente y
los ha escrito en forma de historias de usuario viables, éste trabaja con el cliente y
patrocinador para entender los requerimientos del negocio que proporcionan el
máximo valor empresarial. El Product Owner debe entender lo que el cliente quiere y
valora a fin de organizar los elementos del Product Backlog (historias de usuario),
según su importancia relativa.

Las características necesarias se describen en forma de historias de usuario. Dichas

historias son requisitos específicos señalados por varios Stakeholders que se
relacionan con el producto o servicio propuesto. Cada historia de usuario contará con
sus criterios de aceptación, que son los componentes objetivos mediante las cuales se
juzga la funcionalidad de una historia de usuario. Los criterios de aceptación los
desarrolla el Product Owner según su experiencia en los requerimientos del cliente. El
Product Owner después comunica las historias de usuario que están en el Backlog
Priorizado del Producto a los Developers, buscando un común acuerdo. Los criterios
de aceptación deben delinear explícitamente las condiciones que deben satisfacer las
historias de usuario. Los criterios de aceptación claramente definidos son de suma
importancia para la entrega eficaz y oportuna de la funcionalidad definida en las
historias de usuario, lo cual, en última instancia, determinan el éxito del proyecto.

Recomendaciones para escribir Historias de Usuario.

 Desglosar en tareas: Dividir las HU en tareas más pequeñas, las hace

manejables para el equipo.
 Identificar dependencias: Para priorizar y abordar el trabajo de forma
estructurada.
 Describir los Criterios de aceptación: Son específicos para cada historia de
usuario, y son usados como una lista de verificación.
 Solicitar feedback: Pedir comentarios para entender mejor las expectativas y
necesidades de clientes y usuarios.

Estimación de historias de usuario y tareas

Estimación de las Historias de Usuario y tareas

Es muy importante realizar la estimación de las historias de usuario para poder hacer
planificaciones más precisas. La unidad de medida de las historias de usuario son los
Puntos de Historia

Nota: Esta estimación suele darse en la Reunión de Planificación del Sprint

Es muy importante estimar el trabajo para lograr planificaciones más precisas.

¿Cuál es la unidad de medida para estimar las Historias de Usuario?

La unidad de medida para las historias de usuario y tareas son los Puntos de Historia.

Nota: Esta estimación suele darse enla Planificación del Sprint

Uno de los problemas más comunes con la estimación es sólo estimar la dificultad, o
sólo estimar el tiempo; idealmente se deben estimar ambos.

Priorizar las Historias de Usuario

La priorización de las HU, se basa en las entradas y las necesidades de los proyectos,
teniendo en cuenta el Valor, Riesgo o incertidumbre y las dependencias.

Product Backlog (Lista de pendientes Producto)

Es una lista ordenada de todos los elementos que serán desarrollados, y es la única
fuente de requisitos para cualquier cambio a realizarse en el producto.

 El Product Backlog enumera todas las características, funcionalidades,

requisitos, mejoras y correcciones que se deban hacer sobre el producto para
entregas futuras.
 Los elementos del Product Backlog tienen como atributos la descripción, la
prioridad, la estimación y el valor para negocio.

Priorizar el Product Backlog – historias de usuarios

Es priorizado y ordenado de acuerdo a las necesidades del cliente y posibles

dependencias y/o riesgos entre los entregables

Los elementos que se deben considerar para la priorización de las historias de usuario
son:

 Valor para el negocio

 dependencia
 Riesgo

Esta práctica está relacionada con la planificación en paralelo, debido a que mientras el
equipo termina de desarrollar lo establecido para el último Sprint, el Product Owner
realiza una priorización de las historias de usuario que pueden considerarse para el
siguiente Sprint y que se pueden tomar como base para guiar el rumbo del equipo. Es
importante que esta priorización se realice antes de que se lleve a cabo la Reunión de
Planificación del Sprint con el fin de optimizar el tiempo. Los elementos que se deben
considerar para la priorización de las historias de usuario son:

 Valor para el negocio

 Riesgo
 Dependencia
Para asegurar que un proyecto cumpla con los requisitos de calidad, Scrum adopta un
enfoque de mejora continua mediante el cual el equipo aprende de sus experiencias y
de la participación de los socios, a fin de actualizar constantemente la lista priorizada
de pendientes del producto con cualquier cambio de requisitos. Dicha lista nunca se
completa sino hasta el térnino o la conclusión del proyecto. Cualquier cambio en los
requisitos debe reflejar los cambios en el entorno empresarial, ya sean internos o
externos, y el equipo se debe adaptar continuamente a fin de alcanzar esos requisitos.

• El refinamiento del Product Backlog es el acto de añadir detalles, estimaciones y

orden a los elementos del Product Backlog

• Es una actividad continua en la cual el Product Owner y los Desarrolladores

examinan, revisan y detallan los elementos del Product Backlog que posiblemente se
desarrollarán en el siguiente Sprint.

• El refinamiento usualmente consume no más del 10% del tiempo de la Reunión de

Revisión del Sprint.

El equipo puede llevar a cabo el refinamiento paralelamente al desarrollo del actual

sprint, con esto se logrará que la planificación del siguiente Sprint sea muchísimo más
eficiente

Una vez que se finaliza y se asigna la lista de pendientes del sprint, no se deben
agregar nuevas historias de usuario; sin embargo, tal vez sea necesario agregar
aquellas tareas de las historias de usuario asignadas que se pasaron por alto o que
fueron ignoradas. Si surgen nuevos requerimientos durante un sprint, estos se
agregarían a la lista priorizada de pendientes del producto en un futuro sprint

Sólo hay una excepción a la regla de no modificar el alcance de un sprint una vez que
ha comenzado. Si los Developers determinan que se ha sobreestimado en gran medida
el esfuerzo durante el sprint y no tiene capacidad para poner en práctica historias de
usuario adicionales, el equipo puede preguntarle al Product Owner cuáles historias de
usuario deben incorporarse al sprint actual.
Compromiso: Sprint Goal (Objetivo del Sprint)

 Es el Objetivo único para el Sprint, el cual se verá reflejado al entregar el

incremento de producto al final de un Sprint.
 El objetivo de Sprint se define durante la Planificación de Sprint y, a
continuación, se agrega al Backlog de Sprint.
 A medida que los desarrolladores trabajan durante el Sprint, tienen en cuenta el
Objetivo del Sprint. Si el trabajo resulta ser diferente de lo que esperaban,
colaboran con el Product Owner para negociar el alcance del Sprint Backlog
dentro del Sprint sin afectar el Objetivo del Sprint.

Estos compromisos existen para reforzar el empirismo y los valores de Scrum para el
Equipo Scrum y sus partes interesadas.

Product Goal

En la definición del objetivo del producto, aún no se ha conformado el equipo

completo, por lo cual los Developers no participan en la definición del objetivo del
producto

El Product Goal, se define en la etapa 1: Inicio del proyecto, y algunos aspectos que se
identifican son:

 Las restricciones que enfrentará el proyecto (tiempo-costo-alcance)

 Las expectativas del cliente frente al proyecto
 La identificación de los beneficios que el proyecto generará para el cliente

 Es el Objetivo único para el Sprint, el cual se verá reflejado al entregar el

incremento de producto al final de un Sprint.
 El objetivo de Sprint se define durante la Planificación de Sprint y, a
continuación, se agrega al Backlog de Sprint.
 A medida que los desarrolladores trabajan durante el Sprint, tienen en cuenta el
Objetivo del Sprint. Si el trabajo resulta ser diferente de lo que esperaban,
colaboran con el Product Owner para negociar el alcance del Sprint Backlog
dentro del Sprint sin afectar el Objetivo del Sprint.

Sprint Backlog (Lista de Pendientes del Sprint)

  El Sprint Backlog se compone del Sprint Goal (por qué), el conjunto de
elementos del Product Backlog seleccionados para el Sprint (qué), así como un
plan procesable para entregar el Incremento (cómo).
 El trabajo a realizar durante el Sprint (Sprint Backlog) y el Objetivo del
Sprint (Sprint Goal) se definen en la Planificación del Sprint.

Sprint Backlog

El Sprint Backlog es una predicción hecha por el Equipo Scrum acerca de qué
funcionalidad formará parte del próximo Incremento (Sprint) y del trabajo necesario
para entregar esa funcionalidad en un Incremento “Terminado”.

Este artefacto por lo general tiene los siguientes elementos:

1. Historias de usuario priorizadas, tareas o compromisos que se van a desarrollar

en el Sprint.
2. Número de semanas del Sprint (Duración del Sprint)
3. Presupuesto del Sprint, estimación del trabajo
4. Riesgos que podrían afectar el Sprint.
5. Cambios que serán atendidos/implementados en el Sprint
6. "Firmas” de compromiso por parte del Equipo Scrum.

Este evento es facilitado principalmente por el Product Owner

Eventos o ceremonias

El Sprint (Las iteraciones)

 El corazón de Scrum es el “Sprint”.

 El Sprint es un contenedor para todos los eventos/ceremonias.
 Corresponde a un bloque de tiempo de 1 - 4 semanas (1 mes) en el que se crea
un incremento de producto “terminado”, utilizable y potencialmente
desplegable.
 El corazón de Scrum es el Sprint, es un compartimiento o periodo de tiempo
(time-box) de 1 a 4 semanas durante el cual se crea un incremento de producto
“Terminado” utilizable y potencialmente desplegable
El Sprint está compuesto por los siguientes eventos:

 Planificación 
 Scrum diario
 Revisión
 Retrospectiva 

Limitar el tiempo de los eventos (Time-boxing)

Algunas de las ventajas de cumplir con los bloques de tiempo asignado son los
siguientes:

 Se evita que el equipo pierda motivación.

 Menos gastos generales para el proyecto.
 Se garantiza una alta velocidad para los equipos.
 Las prácticas relacionadas con el desarrollo de entregables son más eficientes.

Desarrollar el Sprint: El objetivo de esta actividad es el desarrollo de los entregables

del sprint, los manuales o documentación relacionada considerando siempre la
definición de "terminado".

Si los Developers determinan que se ha sobrestimado en gran medida el esfuerzo

durante el sprint y no tiene capacidad para poner en práctica historias de usuario
adicionales, el equipo puede preguntarle al Product Owner cuáles historias de usuario
han de incorporarse en el sprint actual.

Realizar los Daily Scrum ( 15 minutos): El objetivo de los daily es mantener

coordinados a los Developers durante el desarrollo del Sprint

Planificación del Sprint: Seleccionar el trabajo a desarrollar. El insumo principal de

este evento es el Product Backlog incluyendo además:

 El último incremento del producto.

 La capacidad proyectada de los Developers para el sprint.
 La velocidad de los Developers.
 Fallas encontradas al producto o incremento de producto (Registro de errores -
Log de errores).
El trabajo a realizar durante el Sprint y el Sprint Goal se planifican en la reunión de
planificación de Sprint.

Planificar la implementación: Una actividad clave es coordinar con los distintos

equipos de operaciones del cliente para preparar la implementación.

Algunos elementos clave en esta actividad son:

 ¿Cuándo se hará la entrega/implementación ?

 ¿Qué usuarios recibirán el nuevo producto?
 La implementación del producto afectará las operaciones ?
 Cómo se notificará a los usuarios?
 ¿Los usuarios están capacitados para usar el nuevo incremento?
 ¿Qué hará el Equipo en caso de que la implementación tenga fallos?

Planificación del Sprint (Sprint Planning)

En las reuniones de planificación, el equipo Scrum se reúne para planificar el trabajo

que se hará en el sprint. El equipo revisa las historias de usuario y tareas que el
Product Owner ha identificado durante la planificación en paralelo, para luego
confirmar y crear el Sprint Backlog en conjunto con todo el equipo.

El Product Owner se encuentra presente durante las reuniones de planificación para

ofrecer claridad sobre las historias de usuario y tareas que se agregarán al Sprint
Backlog para ayudar al equipo a tomar decisiones sobre el diseño. Para ayudar a
garantizar que el equipo no se salga del tema, la reunión debe de tener un bloque de
tiempo asignado con una duración de 2 horas por semana de duración del sprint; esto
ayuda a prevenir la tendencia de desviarse hacia discusiones que deberían realizarse
en otras reuniones.

Al final de la reunión, todo el equipo Scrum confirma la definición del trabajo

pendiente en el Sprint Backlog

El Product Owner expone a los Developers los elementos del Product Backlog que
serán de más prioridad para este Sprint, los cuales componen el objetivo del Sprint,
con esto los Developers trabajan para proyectar la funcionalidad que se desarrollará
durante el Sprint

 El número de elementos del Product Backlog seleccionados para el Sprint

depende únicamente de los Developers
 Solo los Developers pueden evaluar qué pueden lograr durante el Sprint que
comienza
 Durante la Planificación del Sprint el Equipo Scrum (principalmente el Product
Owner y los Developers) definen el objetivo del Sprint (Sprint Goal). El objetivo
del Sprint debería lograrse durante el Sprint y proporciona una guía al
Equipo del por qué se está construyendo el incremento

En la Planificación del Sprint, el Scrum Master y los Developers estiman el

esfuerzo/tiempo (Puntos de Historia) necesario para desarrollar la
tarea/requerimiento.

El trabajo a realizar durante el Sprint (Sprint Backlog) y el Objetivo del Sprint (Sprint
Goal) se definen en la Planificación del Sprint.

Este evento es facilitado principalmente por el Product Owner

¿Quiénes participan? Todo el equipo Scrum (P.O + S.M + D) y otros Stakeholders que puedan ser relev
8 horas para un Sprint de 1 mes
Duración máxima
(menos tiempo en Sprints más cortos)
•¿Por qué este Sprint es valioso?

Agenda •¿Qué se puede terminar (done) en este Sprint?

•¿Cómo se realizará el trabajo elegido?

El Scrum Master en la Planificación del Sprint

 Apoya al Product Owner a moderar la participación de todos

 Cuida que se cumpla con la agenda y duración del evento
 Asiste al Product Owner en la definición del trabajo a realizar
 Apoya en la resolución de dudas que tengan los Developers
 Apoya a los Developers al momento de realizar las estimaciones del trabajo
  En la Planificación del Sprint, el Scrum Master y los Developers estiman el
esfuerzo/tiempo (Puntos de Historia) necesario para desarrollar la
tarea/requerimiento.

Compromiso: Sprint Goal (Objetivo del Sprint) Cuando se realiza la planificación

del Sprint se define el objetivo del sprin o Sprint Goal

 Es el Objetivo único para el Sprint, el cual se verá reflejado al entregar el

incremento de producto al final de un Sprint.
 El objetivo de Sprint se define durante la Planificación de Sprint y, a
continuación, se agrega al Backlog de Sprint.
 A medida que los desarrolladores trabajan durante el Sprint, tienen en cuenta el
Objetivo del Sprint. Si el trabajo resulta ser diferente de lo que esperaban,
colaboran con el Product Owner para negociar el alcance del Sprint Backlog
dentro del Sprint sin afectar el Objetivo del Sprint.

El Scrum diario (Daily Scrum)

La reunión diaria optimiza la colaboración y el desempeño del equipo, al permitir

inspeccionar el trabajo diariamiente y proyectando el trabajo que queda pendiente:

 Este evento tiene una duración de máximo 15 minutos

 Participan el Scrum Master y los Developers

Es un evento de 15 minutos para los Developers que sirve para inspeccionar el

progreso hacia el objetivo del Sprint (Sprint Goal) y adaptar el Sprint Backlog según sea
necesario.

Los Scrums diarios mejoran la comunicación, se identifican los impedimentos,

promueven la rápida toma de decisiones y, en consecuencia, eliminan la necesidad de
otras reuniones.

La Revisión del Sprint (Sprint Review)

La reunión de Revisión del Sprint tiene un bloque de tiempo asignado de cuatro horas
por un sprint de un mes y puede escalarse según la duración del sprint. Durante la
reunión de Revisión del Sprint, los Developers presentan los entregables del actual
sprint al Product Owner, quien puede aceptar o rechazar los entregables

 El Equipo Scrum presenta los resultados de su trabajo a los principales

interesados y se discute el progreso hacia el Objetivo del Producto (Product
Goal).
 La Revisión del Sprint es una sesión de trabajo por lo que se debe evitar limitarla
solo a una presentación.

Los miembros del equipo Scrum y los socios 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. Los Developers demuestran los logros
del sprint, incluyendo las nuevas funcionalidades o los productos elaborados. Esto
brinda una oportunidad para que el Propietario del Producto y el(los) socio(s)
inspeccionen lo que se ha completado hasta el momento y determinen si deben
realizarse cambios en el proyecto o en los procesos en sprints posteriores

¿Quiénes participan? Todo el equipo Scrum (P.O + S.M + D) + Otros stakeholders que puedan ser rele
4 horas para un Sprint de 1 mes
Duración máxima
(menos tiempo en Sprints más cortos)
•¿Qué elementos se terminaron y cuales No?

Agenda •¿Qué sucedió con los riesgos?

•El Product Owner retroalimenta al equipo respecto a su trabajo.

El Product Owner en la Revisión del Sprint

 Facilita y dirige el evento

 Asegura que el progreso respecto al Objetivo de Producto es discutido en esta
sesión
 Asegura que las partes interesadas clave participen de la sesión.
 Discute el Product Backlog tal y como está.
 Proyecta el objetivo y las fechas de entrega probables basándose en el progreso
hasta la fecha (si es necesario).
 Suele hacer la verificación del incremento de acuerdo a lo planificado (criterios
de aceptación + DoD)
¿Quiénes participan? Todo el equipo Scrum (P.O + S.M + D) + Otros stakeholders que puedan ser rele

La Reunión de Revisión del Sprint, es donde los Developers muetran los entregables
del Sprint al Product Owner y a los socios relevantes. El propósito de esta reunión es
lograr la aprobación y aceptación del Product Owner con respecto al producto o
servicio.

Retrospectiva

La reunión de retrospectiva del sprint es un elemento importante del marco de

"inspección-adaptación" de Scrum y es el último paso en un sprint.

Todos los Developers asisten a la reunión que es organizada y moderada por el Scrum
Master.

Se recomienda que asista el Product Owner, aunque no es obligatorio. Un integrante

del equipo funge 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 y

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

El Equipo Scrum inspecciona cómo fue el último Sprint con respecto a individuos,

interacciones, procesos, herramientas, y su Definición de Terminado.

Se identifican elementos que los llevaron por el mal camino, lo que fue bien durante el
Sprint, los problemas que se encontraron y cómo fueron (o no fueron) resueltos;
además de generar lecciones aprendidas.
Los debates que se llevan a cabo en la Retrospectiva del sprint, deben abarcar tanto lo
que salió mal como lo que salió bien. Sus principales objetivos son 3:

1. Las cosas que el equipo tiene que 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

En Scrum nunca se habla de los integrantes del equipo sino del equipo como un todo,
gana el equipo o pierde el equipo

Agenda:

•¿Cómo nos fue en el Sprint?

•¿Qué salió bien y como podemos mejorar?

•¿Cómo vamos a adoptar esas mejoras?

El Product Owner desempeña un papel importante en la Retrospectiva del Sprint.

Participa en la revisión del último Sprint, contribuye a la identificación de las
lecciones aprendidas, y puede sugerir mejoras a la Definición de terminado (DoD),
que es una lista de los criterios que se deben cumplir para que un producto se
considere "terminado".