Curso Oficial SMC RM Certified

Programa
de Entrenamiento
Oficial en SCRUM-MASTER
INFORMACIÓN DE CONFIDENCIALIDAD
Toda información contenida en este documento es considerada privilegiada

y confidencial, ya que este material incluye descripciones metodológicas de
propiedad exclusiva de VMEdu, ninguna parte de este documento podrá ser
reproducida por cualquier medio sin la autorización correspondiente

VMEdu@Todos los derechos reservados
Scrum Master Cer?fied (SMC™)
Los profesionales cerHficados como Scrum Master CerHfied (SMC™) Henen un conocimiento prácHco
de los equipos Scrum para implementar y trabajar en un ambiente Scrum. El propósito de esta
cerHficación es confirmar que los aspirantes han adquirido conocimientos suficientes sobre cómo aplicar
Scrum en sus proyectos y adaptar la metodología a diferentes escenarios.
Los profesionales cerHficados como SMC™ son facilitadores que aseguran que el equipo Scrum sea
provisto de un ambiente conducHvo que le permita completar saHsfactoriamente el proyecto. El Scrum
Master guía, facilita y enseña las buenas prácHcas de la metodología a todos los involucrados en el
proyecto, elimina los impedimentos en el equipo y se asegura que los procesos estén siendo
ejecutados
EXAMEN
DETALLES DEL EXAMEN
q  Opción múl?ple de respuesta

q  100 preguntas por examen
q  Se otorga un punto por cada respuesta correcta
q  Duración 120 minutos
q  Examen supervisado en línea
q  Tasa actual de aprobación 95%
TEMAS
1.  Vista General de Agile y Scrum
•  Visión General de Agile
•  Manifiesto de Agile •  Scrum Master
•  Equipo Scrum (Scrum Team)
•  Principios de Agile
•  Métodos Agiles •  Desarrollo IteraHvo

•  Vista General de Scrum
4. Escalando con Scrum
•  Ventajas de Scrum
•  Escalabilidad de Scrum

•  Scrum en Programas y Portafolios
2. Fases de los Proyectos Scrum
•  Reuniones Scrum of Srum (SoS)
•  Inicio
•  Transición a Scrum
•  Plan y EsHmaciones
•  Mapeo de Roles Tradicionales a Scrum
•  Implementación
•  Manteniendo el Involucramiento del
•  Revisiones y RetrospecHvas Stakeholder
•  Liberación •  La Importancia del Soporte EjecuHvo
•  Entradas, Herramientas, Salidas para cada Proceso en
cada

3. Roles de Scrum
•  Roles Centrales
•  Roles no Centrales
•  Dueño del Producto (Product Owner)
VISTA GENERAL DE AGILE Y SCRUM
q  RESUMEN DE ÁGIL

El palabra “ágil” generalmente hace

referencia a ser capaz de moverse o

responder rápido y fácil. En cualquier Hpo de

disciplina
de administración, ser ágil es una
cualidad, por lo
es algo bueno que se debe
buscar. La ges?ón de Proyectos Agile
especialmente, implica la adaptabilidad
durante la creación de un producto , servicio
o cualquier otro resultado.

ES NECESARIO TENER EN CUENTA LA ESTABILIDAD EN SUS PROCESOS DE ADAPTACIÓN.

q  EL GRAN INTERES POR AGILE

Ágil depende de la planificación adapHva y del

desarrollo y la entrega iteraHva. Se centra

principalmente en el valor de las personas al hacer

eficazmente el trabajo. Aunque las metodologías

adaptaHvas e incrementales han exisHdo desde los
años cincuenta.
SÓLO LAS METODOLOGÍAS QUE SE AJUSTAN AL MANIFIESTO ÁGIL SON GENERALMENTE

CONSIDERADAS COMO "ÁGILES".
q  AGILE MANIFESTO
En febrero

del 2001, un grupo de 17 gurús de la informáHca, desarrolladores de
soaware
y administradores, se reunieron para discuHr los métodos de desarrollo
de soaware.
Formaron la Alianza Ágil (Agile Alliance) y las discusiones en estas

reuniones resultaron después en un Manifiesto para el desarrollo ágil de soaware

(Manifesto for Agile Soaware Development). El manifiesto fue escrito por Flowler
y Highsmith (2001) y suscrito después por todos los par?cipantes a fin de
establecer los lineamientos básicos de cualquier metodología ágil.
Desarrollo Agil : Manifesto
Propósito del manifestó Agil :
Estamos descubriendo mejores formas de desarrollar soaware haciéndolo y
ayudando a que otros lo hagan.

A través de este trabajo hemos llegado a valorar:
Esto quiere decir : Aunque valoramos los elementos de la

derecha, valoramos más los elementos de la izquierda.
hJp://agilemanifesto.org/iso/es/manifesto.html
Aunque los procesos y las herramientas ayudan a terminar con éxito un

proyecto, son las personas quienes asumen, par?cipan e implementan
un proyecto y determinan cuales procesos y herramientas u?lizar.
Aunque la documentación es necesaria para cualquier proyecto, muchos equipos se centran en

la recopilación y descripciones de los entregables, cuando el valor real que se le entrega al
cliente es en forma de soNware funcional. Por lo tanto, en vez de la documentación detallada,
el enfoque ágil está en la entrega de un soNware funcionando en incrementos a lo
largo del proyecto
Anteriormente a los clientes se les ha visto como par?cipantes externos, involucrados

principalmente al inicio y al final del proyecto y cuya relación esta escrita en un contracto. Ágil
cree en un enfoque de valor compar?do en el cual los clientes se consideran colaboradores.
El equipo de desarrollo y el cliente trabajan unidos para el proyecto

Actualmente los requerimientos del cliente, las tecnologías y los factores empresariales
cambian constantemente, es fundamental abordar el desarrollo de productos de forma
adapta?va que permita la incorporación de cambios en cortos ciclos de vida de
desarrollo de producto.
1.  Kent Beck

2.  Mike Beedle
3.  Arie van Bennekum
4.  Alistair Cockburn
5.  Ward Cunningham
6.  MarHn Fowler
7.  James Grenning
8.  Jim Highsmith
9.  Andrew Hunt
10.  Ron Jeffries
11.  Jon Kern
12.  Brian Marick
13.  Robert C. MarHn
14.  Steve Mellor
15.  Ken Schwaber
16.  Jeff Sutherland
17.  Dave Thomas

q  12 - PRINCIPIOS DEL MANIFIESTO ÁGIL (Fowler y Highsmith 2001)
Este documento establece explícitamente los principios básicos que un equipo Agile Hene que
incorporar a su cultura de trabajo.
Principios Implicaciones
Nuestra mayor prioridad es saHsfacer al cliente •  SaHsfacer al cliente (no la oficina de gesHón de proyectos)
mediante la entrega temprana y conHnua de •  Con la entrega temprana y conHnua (para obtener
soaware con valor. retroalimentación y tener Hempo para solucionar
problemas)
•  De valioso soaware (se centra en el valor y el producto
final es decir, soaware no documentación)
Aceptamos que los requisitos cambien, incluso •  Aceptar el cambio, que va a suceder de todos modos.
en etapas tardías del desarrollo. Los procesos •  Esforzarse para proporcionar información de úlHma hora,
Agiles aprovechan el cambio para proporcionar la funcionalidad de alto valor (ventaja compeHHva).
ventaja compeHHva al cliente. •  Más Hempo puede ser uHlizado en el producto final
aceptando, en lugar de luchar en contra.
Entregamos soaware funcional frecuentemente, •  Entregar con frecuencia.
entre dos semanas y dos meses, con preferencia •  Obtener retroalimentación temprano y con frecuencia.
al periodo de Hempo más corto posible. •  Detectar si se puede proceder o la necesidad de cambiar
las cosas.
•  ManHene s clientes compromeHdos.
q  PRINCIPIOS DEL MANIFIESTO ÁGIL
Los responsables de negocio y los •  Los desarrolladores conocen y enHenden el negocio.
desarrolladores trabajamos juntos de •  Organizar reuniones (a diario más frecuentes).
forma coHdiana durante todo el proyecto. •  Los representantes empresariales logran una mejor
comprensión de lo que es diocil / costoso desarrollar y lo
que es fácil / barato.
•  Mantenga parHcipación de los empresarios
Los proyectos se desarrollan en torno a •  Equipos empoderadas conoan en su experiencia y su
individuos moHvados. Hay que darles el trabajo en equipo.
entorno y el apoyo que necesitan, y •  Proporcionar apoyo cuando sea necesario.
confiarles la ejecución del trabajo. •  La diferencia en el impacto de "tener la mejor gente”
frente a "tener los mejores procesos y herramientas" es
de 10: 1.
•  MoHvar a la gente
El método más eficiente y efecHvo de •  Las emociones y el lenguaje corporal son partes
comunicar información al equipo de importantes de la comunicación.
desarrollo y entre sus miembros es la •  La realidad dicta que no siempre puede ser cara a cara
conversación cara a cara. la comunicación; es imposible, uHlizar otros medios de
comunicación, como el vídeo.
El soaware funcionando es la medida •  Haga soaware que trabaje en el foco primario. La
principal de progreso. documentación se convierte en una segunda prioridad a
tomar
•  Medir "hecho" de soaware.
Los procesos ágiles promueven el •  Mientras metodologías ágiles están orientados a corto
desarrollo sostenible. Los promotores, plazo flexibilidad y valor, también se esfuerzan por
desarrolladores y usuarios debemos ser maximizar el valor más Hempo
capaces de mantener un ritmo constante •  No quemar a las personas valiosas.
de forma indefinida.

•  En el mundo del soaware, una vez que el soaware se
La atención conHnua a la excelencia entrelaza en gran medida, se vuelve resistente al cambio.
técnica y al buen diseño mejora la •  Mantenga sostenible (Escalable) el soaware (similar al
agilidad. anterior principio para las personas).
•  Pasa un poco de esfuerzo se manHene la flexibilidad del
soaware (hacer refactorización). Si su producto llega a ser
inflexible y resistente a cambio, entonces incluso las
mejores intenciones no te permiHrán, dirección de los
requisitos cambiantes rápidamente.
La simplicidad, o el arte de maximizar la •  En el mundo del soaware, el 60 por ciento de las
canHdad de trabajo no realizado, es caracterísHcas incorporadas son rara vez (o nunca) uHlizado.
esencial. •  Evite código muerto que desperdicia esfuerzo y causa
problemas.
•  UHlice el método más sencillo posible
Las mejores arquitecturas, requisitos y •  Para obtener lo mejor de las personas, dejar que ellos se
diseños emergen de equipos auto- organicen en su trabajo.
organizados. •  Aumenta compromiso y orgullo en su trabajo.
•  El equipo sabe mejor lo que está funcionando y lo que no.
A intervalos regulares el equipo •  Se trata de las lecciones aprendidas, pero se hace a lo largo
reflexiona sobre como ser más efecHvo del proyecto, no sólo al final.
para a conHnuación ajustar y •  Porque el cambio es posible durante el proyecto, no espere
perfeccionar su comportamiento en hasta después del proyecto para las lecciones aprendidas;
consecuencia. discuHrlas con regularidad, y ajustar durante el proyecto.
•  El equipo va a definir los cambios necesarios y poner en
prácHca ellos.
•  Al hacerlo, pueden beneficiarse inmediatamente de la
mejoras en el proyecto actual.
q  DECLARACIÓN DE INTERDEPENDENCIA
La gesHón de proyectos Agile (Declaración de

independencia) fue redactada a principios del 2005
por un grupo de 15 lideres de proyectos como un
complemento del Manifiesto Ágil. Enumera seis
valores de gesHón necesarios para reforzar una
mentalidad de desarrollo ágil, par?cularmente en la
ges?ón de proyectos complejos e inciertos.

La declaración destaca que los equipos del proyecto,
los clientes y demás socios son interdependientes y
están conectados, lo cual se debe reconocer a fin de
lograr el éxito. Los valores por si mismos son
también interdependientes.

q  DECLARACIÓN DE INTERDEPENDENCIA
Nosotros...

ü  Aumentamos el retorno sobre la inversión enfocándonos en la aportación conHnua de
valor.
ü  Entregamos resultados fiables mediante la parHcipación de clientes en las interacciones
frecuentes, así́ como la propiedad comparHda.
ü  Esperamos la incer?dumbre y la gesHonamos a través de iteraciones, con anHcipación y
adaptación.
ü  Damos rienda suelta a la crea?vidad y la innovación reconociendo que las personas
son la fuente ulHma de valor, y creando un ambiente donde pueden ser la diferencia.
ü  Aumentamos el rendimiento mediante la orientación del grupo a los resultados y la
responsabilidad comparHda para la efecHvidad del equipo.
ü  Mejoramos la eficacia y fiabilidad a través de estrategias, procesos y pracHcas
especificas.

Anderson. D., AugusHne, S., Avery, C., Cockburn, A., Cohn, M., et al. 2005

q  METODOS AGILES
Una serie de metodologías ágiles se originaron y ganaron fuerza en la década de 1990 y

principios del 2000. Si bien son diferentes en una variedad de aspectos, lo que ?enen en
común se deriva de su integración con El Agile Manifestó.
Los siguientes métodos ágiles se discuten brevemente a conHnuación:

ü  Lean Kanban (Reducción de Perdidas)
ü  Programación extrema
ü  Métodos Crystal (Crystal Methods)
ü  Métodos de desarrollo de sistemas dinámicos(Dynamic Systems Development Methods)
ü  Desarrollo orientado a funcionalidades (Feature Driven Development)
ü  Desarrollo guiado por pruebas (Test Driven Development)
ü  Desarrollo adapta?vo de sokware (AdapHve Soaware Development)
ü  Proceso unificado Ágil (Agile Unified Process)
ü  Desarrollo guiado por el dominio (Domain Driven Development)
A mediados de los 80, Hirotaka Takeuchi y Ikujiro Nonaka definieron

una estrategia de desarrollo de Producto flexible donde el equipo de
desarrollo
trabaja como una unidad para alcanzar un objeHvo Guía SBOK TM 2013
común.

Ambos describieron un enfoque innovador para el desarrollo de

Producto al que ellos llaman un enfoque holísHco o "rugby", "donde
un equipo intenta llegar hasta el final como una unidad, pasando el
balón hacia atrás y hacia delante”. Ellos basan su enfoque en los
estudios de casos de diversas industrias de fabricación.

Ken Schwaber y Jeff Sutherland desarrollaron el concepto de Scrum
y su aplicabilidad al desarrollo de soaware durante una presentación
en la Conferencia internacional sobre programación, lenguajes y
aplicaciones orientadas a objetos (OOPSLA) en 1995 en AusHn, Texas.
Desde entonces, varios pracHcantes, expertos autores de Scrum han Enfoque adapta?vo e itera?vo
seguido perfeccionando la conceptualización y metodología de
Scrum.

q  PRINCIPIOS SCRUM
1. CONTROL DE PROCESOS EMPÍRICO
Este principio es lo primordial en la filosooa de Scrum, se
basa en tres ideas principales la TRANSPARENCIA,
INSPECCIÓN, Y LA ADAPTACIÓN.

2. AUTO-ORGANIZACIÓN
Se centra en los trabajadores, que entregan un valor mayor
cuando son auto-organizados lo cual resulta en equipos con
un gran compromiso y responsabilidad que a su vez esto
produce un entorno innovador y creaHvo

3. COLABORACIÓN
Este principio se centra en las tres dimensiones básicas
relacionadas con el trabajo colaboraHvo: conciencia,
arHculación y apropiación.
q  PRINCIPIOS SCRUM
4. PRIORIZACIÓN BASADA EN VALORES

Este principio se enfoca en ofrecer el máximo valor al negocio, desde el principio del
proyecto hasta su conclusión.

5. TIME BOXING
Este principio describe cómo el Hempo se considera una restricción limitante en Scrum, y
cómo se uHliza para ayudar a manejar eficazmente la planificación y ejecución del proyecto.

6. DESARROLLO ITERATIVO
Este principio define el desarrollo iteraHvo y enfaHza cómo manejar mejor los cambios y
crear Productos que saHsfagan las necesidades del Cliente.
ASPECTOS SCRUM

Deben ser abordados y manejados a lo largo de un proyecto Scrum. Los cinco
aspectos Scrum son los siguientes:

1.  Organización
2.  Jus?ficación de negocios
3.  Calidad
4.  Cambio
5.  Riesgo

PROCESOS EN SCRUM
Los procesos de Scrum abordan las acHvidades y el flujo especifico de un proyecto
Scrum.
En total hay 19 procesos que se agrupan en cinco fases

Fase Procesos
1.  Crear la Visión del Proyecto
2.  IdenHficar al Scrum Master y a los interesados
3.  Formación del Equipo Scrum

Iniciación
4.  Desarrollo de las Épicas
5.  Crear la Lista de priorizada de Pendientes del Producto
6.  Realizar la Planificación de lanzamiento
1.  Crear Historias de Usuarios
2.  Aprobar, EsHmar y asignación de las Historias de Usuario

Planificación y EsHmación
3.  Crear Tareas
4.  EsHmar tareas
5.  Crear la Lista de Pendientes del Sprint

PROCESOS EN SCRUM

Los procesos de Scrum abordan las acHvidades y el flujo especifico de un proyecto Scrum.
En total hay diecinueve procesos que se agrupan en cinco fases

Fase Procesos
1.  Creación de Entregables
Implementación 2.  Llevar acabo la reunión Diaria
3.  Mantenimiento de la lista Priorizado de Pendientes del Producto
1.  Convocar Scrum de Scrums
Revisión y RetrospecHva 2.  Demostrar y Validar el Sprint
3.  RetrospecHva del Sprint
1.  Envío de Entregables

Lanzamiento
2.  RetrospecHva del Proyecto
¿VENTAJAS DE UTILIZAR SCRUM?

1.- Adaptabilidad 13.- Entorno de Alta Confianza
2.- Transparencia 14.- Propiedad Colec?va
3.- Retroalimentación Con?nua 15.- Alta Velocidad
4.- Mejora con?nua 16. Medio Ambiente mo?vador
5.- Entrega Con?núa de Valor
6.- Ritmo sostenible
7.- Entrega rápida de Alto Valor
8.- Proceso de Desarrollo Eficiente
9.- Mo?vación
10.- Resolución de Problemas de Forma más Rápida
11.- Entregables Efec?vos
12.- Centrado en el cliente

ROLES EN SCRUM
ORGANIZACIÓN
Los roles de Scrum se dividen en dos grandes categorías:

q  ROLES PRINCIPALES : Funciones obligatorias para el proyecto , responsables del éxito
de cada Sprint.
q  ROLES SECUNDARIOS: Funciones no básicas pueden incluir miembros del equipo que
estén interesados en el proyecto, que no Henen un papel formal en el equipo del
proyecto,

Hay papeles básicos y no básicos en todos los equipos. Decidir quién es núcleo y que es no
básico, no siempre es fácil.

ROLES EN SCRUM
q  ROLES PRINCIPALES
Hay 3 roles principales en Scrum que son en úlHma instancia responsables de cumplir con los
objeHvos del proyecto; ellos son el propietario del producto(Product Owner), Scrum Master y
el Equipo Scrum. Juntos se les conoce como el Equipo Core Scrum.

La siguiente figura da una vista de los Roles de Scrum.

ROLES EN SCRUM
q  DUEÑO DEL PRODUCTO

Representa los grupos de interés y es responsable de
asegurar que el equipo scrum ofrezca valor.

El Product Owner describe los requerimientos del
negocio en forma de historias de usuarios con las
aportaciones de los miembros del equipo Scrum Core
y gesHona la Prioridad del Product Backlog. En algunos
casos, los miembros del equipo de Scrum pueden
escribir historias de usuarios bajo la supervisión del
propietario del producto.

El propietario del producto también es responsable de
asegurar la comunicación clara de funcionalidades de
productos al Equipo scrum y razón por la cual es
llamado la Voz del Cliente.
ROLES EN SCRUM
Responsabilidades del Propietario del producto.
Proceso Responsabilidades del Propietario del Producto
•  Define la Visión del Proyecto
Crear la Visión del Producto •  Ayuda a crear el Acta de ConsHtución del Proyecto y el
Presupuesto del Proyecto
•  Ayuda a finalizar la elección del Scrum Master para el proyecto

IdenHficar al Scrum Master y a los interesados
•  IdenHfica a los Stakeholder(s)
•  Ayuda a determinar los miembros del Equipo Scrum
•  Ayuda a desarrollar un Plan de Colaboración

Formar el Equipo Scrum
•  Ayuda a desarrollar el Plan para la Formación del Equipo con los
Scrum Master(s)
Desarrollo de Épica(s) •  Crea Épica(s) y Personajes o Personas

•  Prioriza los elementos del Backlog del Producto
Crear el Priorizada Backlog Producto
•  Define el Criterio de Terminado
•  Crea el Cronograma de Planificación del Lanzamiento

Realizar la Planificación del Release
•  Ayuda a determinar el Longitud del Sprint
ROLES EN SCRUM
Proceso Responsabilidades del Producto Owner
•  Ayuda a Crear Historias de Usuarios

Crear Historias de Usuarios
•  Define el Criterio de Aceptación para cada Historia de Usuario.
Aprueba, esHma y se compromete con Historias •  Aprueba las Historias de Usuarios

de Usuarios •  Facilita al Equipo Scrum y se compromete a las Historias de Usuarios
•  Le explica las Historias de Usuarios al Equipo Scrum, mientras crea

Crear Tareas
el Lista de Tareas
•  Le proporciona orientación y aclaración al Equipo Scrum sobre la

EsHmar el Trabajo
esHmación de esfuerzo para las tareas
•  Le aclara los requisitos al Equipo Scrum mientras crea el Pendientes

Crear la Lista de Pendientes de Sprint
del Sprint
Crear Entregables •  Le aclara los Requisitos del Negocio al Equipo Scrum
Mantenimiento Priorizado de los Pendientes del
•  ManHene Priorizado el Backlog del Producto
Producto
ROLES EN SCRUM
Proceso Responsabilidades del Producto Owner
•  Acepta / Rechaza los Entregables
•  Proporciona retroalimentación necesaria para el Scrum Master y el

Demostrar y Validar el Sprint
Equipo Scrum
•  Actualiza el Plan de Lanzamiento y el Priorizada Backlog Producto
•  Ayuda con el lanzamiento de los Producto y coordina esto con el

Envío de los Entregables
Cliente
RetrospecHva del Proyecto •  ParHcipa en la reunión de RetrospecHva del Sprint

ROLES EN SCRUM
q  SCRUM MASTER

Tiene la responsabilidad de asegurarse que los
procesos de Scrum se sigan correctamente por todos
los miembros del Equipo Central Scrum, incluyendo
el propietario del producto.

El Scrum Master supervisa los lanzamientos,
Reuniones, Planificaciones y convoca a otras
reuniones. El papel del Scrum Master se basa en el
concepto de liderazgo de servicio en el que los líderes
logran resultados por dar atención a las necesidades
del equipo.

EL SCRUM MASTER TAMBIÉN INSTRUYE A TODOS LOS INTERESADOS ACERCA DE
LOS VALORES Y MÉTODOS DE SCRUM. ESTA RESPONSABILIDAD ES MÁS
IMPORTANTE Y CRÍTICA AL INICIO, CUANDO ES LA TRANSICIÓN A LOS MÉTODOS
DE SCRUM.
ROLES EN SCRUM
Responsabilidades del SCRUM MASTER
Proceso Responsabilidades del Scrum Master
IdenHficar al Scrum Master y al/los
•  Ayuda a idenHficar al/los Stakeholder(s) para el proyecto.
Stakeholder(s)
•  Facilita la selección del equipo Scrum.
•  Facilita la creación del Plan de Colaboración y el Plan para la Formación

Formar el Equipo Scrum del Equipo. (Team Building Plan)
•  Asegura que los recursos de respaldo están disponibles. para el

funcionamiento del proyecto sin problemas.
Desarrollo de Épica(s) •  Facilita la creación de la(s) Épica(s) y Personas.
•  Ayuda al Producto Owner en la creación del Backlog Priorizado del

Crear la Lista de Pendientes del Producto Producto y en la definición de los Criterios de Termino/Realización. (Done
Criteria)
•  Coordina la creación del Cronograma de Planificación. (Release Planning

Dirige la Planificación del Release Schedule)
•  Determina la longitud del Sprint - “Semanas”. (Length of Sprint)
•  Asiste al equipo Scrum en la creación de las Historias de Usuarios y sus

Crear Historias de Usuarios
Criterios de Aceptación.
ROLES EN SCRUM
Aprueba, esHma y se compromete con •  Facilita reuniones del equipo Scrum para esHmar y crear historias de
Historias de Usuarios usuarios.
•  Facilitador del equipo Scrum en la creación de la Lista de Tareas para el

Crear Tareas
próximo Sprint
•  Asiste al Equipo Scrum en esHmar el esfuerzo necesario para completar las

EsHmar tareas
tareas acordadas para el Sprint
Crear la lista de pendientes del Sprint •  Asiste al Equipo Scrum en el desarrollo del Sprint Backlog y en el Gráfico de
(Sprint Backlog) Trabajo Pendiente. (Burndown Chart)
•  Apoya al equipo Scrum en la creación de los entregables (Deliverables)
acordados para el Sprint
Crear Entregables
•  Ayuda a actualizar la Pizarra Scrum (Scrumboard) y el Registro de
Impedimentos. (Impediment Log)
•  Asegura que la Pizarra Scrum y el Registro de Impedimentos permanezcan
Realizar un Standup Diario
actualizados
Mantenimiento Priorizado de los

•  Facilita la reuniones de revisión del Backlog priorizado del producto.
Pendientes del Producto
ROLES EN SCRUM

•  Se asegura que los Incidentes que afectan al Equipo Scrum se discutan y
Convocar Scrum de Scrums
resuelvan
•  Facilita la presentación de los Entregables ya completados por el Equipo

Probar y Validar el Sprint
Scrum para la aprobación del Producto Owner.
•  Se asegura que exista un ambiente ideal para el Equipo Scrum del proyecto
RetrospecHva del Sprint
en los sucesivos Sprints
•  Representa al Equipo Principal de Scrum (Scrum Core Team) para

RetrospecHva del Proyecto
proporcionar lecciones del proyecto actual, si es necesario.
Tenga en cuenta que el papel del Scrum Master es muy diferente a la función
desempeñada por un director de proyecto en un modelo de Cascada tradicional, en la
que el director de proyecto trabaja como gerente o líder del proyecto. El Scrum Master
funciona como un facilitador y él/ella está en el mismo nivel jerárquico que cualquier
otra persona en el Equipo Scrum.
ROLES EN SCRUM
q  EQUIPO SCRUM

El Equipo Scrum es un grupo de personas que son responsables de la comprensión de los
requerimientos del negocio especificados por el propietario del producto, la esHmación
de historias de usuario y la creación de los entregables del proyecto.

ROLES EN SCRUM
CARACTERÍSTICAS DEL EQUIPO SCRUM

q  Auto-organizado

q  Mul?-funcional

q  Cara a cara de la comunicación

q  La entrega del producto itera?vo
ROLES EN SCRUM
Responsabilidades del SCRUM TEAM
Proceso Responsabilidades del Scrum Team
•  Proporciona entradas (inputs) para la creación del Plan de colaboración
Formar el Equipo Scrum y Plan de desarrollo del equipo
Desarrollo de Épica(s) •  Asegura una comprensión clara de la(s) Épica(s) y de Personas
•  EnHenden las Historias de los en la lista priorizada de pendientes del

Crear la Lista de Pendientes del Producto producto.
•  Están de acuerdo con los miembros del Equipo Principal de Scrum

sobre la duración del Sprint.
Realización del Plan de lanzamiento •  Busca clarificación sobre los nuevos productos o cambios, si los hay, en
los productos existentes en la lista priorizada de pendientes del
producto
•  Le proporciona entradas al Product Owner en la creación las historias
Crear Historias de Usuarios de los usuarios.
•  EsHma los historias de usuarios aprobadas por el Product Owner

Aprueba, esHma y se compromete con
•  Se compromete con las historias de usuario que hay que hacer en un
Historias de Usuarios Sprint
•  Desarrolla la lista de tareas basada en las historias de los usuarios ya

Crear Tareas acordadas y asociadas. (dependencias)
ROLES EN SCRUM
•  Calcular el esfuerzo para las tareas idenHficadas y si es necesario
EsHmar las Tareas
actualiza la lista e tareas.
Crear la lista de pendientes del Sprint

•  Desarrolla el Sprint Backlog y el Sprint Burndown Chart.
(Sprint Backlog)
•  Crea Entregables
Crear Entregables •  IdenHfica Riesgos y ejecuta acciones de miHgación, si las hay.
•  Actualiza el Impediment Log y las dependencias.
•  Actualiza el Burndown Chart, Scrumboard y el Impediment Log.

•  Discuten issues que enfrenta cada miembro y busca soluciones para
moHvar al equipo.
Realización de la reunión diarias •  IdenHfican riesgos, si los hay.
•  Presentar cambios en los requerimientos (Change Requests), si se
requieren.
Mantenimiento de la lista priorizada de

•  ParHcipan en las reuniones de revisión de PrioriHzed Product Backlog
Pendientes del Producto
•  Proporciona entradas al Scrum Master para las reuniones de Scrum of

Convocar Scrum de Scrums Scrum (SoS).
ROLES EN SCRUM
Demostración y Validación del Sprint Mostrar entregables completados al Product Owner para su aprobación.
RetrospecHva del Sprint IdenHfican oportunidades de mejora si las hay del Sprint actual y deciden si
están de acuerdo sobre las posibles mejoras viables para el próximo Sprint.
RetrospecHva del Proyecto ParHcipan en la reunión de retrospecHva del proyecto

ROLES EN SCRUM
q  DINAMICAS DE EQUIPO
El enfoque y método de Scrum inicialmente pueden parecer muy diferente y diocil para
un nuevo Equipo Scrum.
Cualquier equipo por lo general se desarrolla a través de un proceso de cuatro etapas
durante su primer proyecto Scrum. Este proceso se conoce como Modelo de Dinámica
de Grupo de Tuckman.
Las cuatro etapas del modelo son:

Ø  Forming (Formación)

Ø  Storming (Enfrentamiento)

Ø  Norming (Normalización)

Ø  Performing (Desempeño).
ROLES EN SCRUM
q  SELECCIÓN DEL SCRUM TEAM
ü  El Scrum Team es la base de cualquier proyecto Scrum y tener a los miembros
adecuados para el equipo es vital para la entrega exitosa de los proyectos Scrum. Los
miembros del Scrum Team son generalistas y especialistas. (Tienen conocimiento
general de varios campos y son expertos en al menos uno, pero más allá de la
experiencia, son las habilidades sociales de los miembros del equipo que determinan
el éxito.)

ü  Los miembros ideales del Scrum Team son independientes, auto-moHvados, se enfocan
en el cliente, y Henen un senHdo alto de responsabilidad y de la colaboración. El equipo
debe ser capaz de fomentar un ambiente de reflexión independiente y de tomar
decisiones con el fin de extraer los mayores beneficios de la estructura.

ROLES EN SCRUM
q  VENTAJAS DE EQUIPOS MULTIFUNCIONALES

ü  Toma de decisiones más rápida
ü  Mejora la comunicación
ü  Obje?vo de Orientación (Son muy enfocados en el resultado deseado. El Equipo Scrum

Hene un conjunto definido de objeHvos durante cada Sprint y es lo suficientemente
flexible para gesHonar un cambio en los objeHvos antes del próximo Sprint.)
ü  Propiedad colec?va (El equipo en su conjunto es responsable de la entrega de los

resultados, y cualquier éxito o fracaso está en el nivel de equipo.)
ü  La innovación con?nua
ROLES EN SCRUM
q  ROLES NO CENTRALES
Son aquellos que no son obligatoriamente necesarios para un proyecto Scrum y pueden no
estar involucrados en el proceso de Scrum. Sin embargo, es de importancia saber sobre
estos roles secundarios ya que podrían desempeñar un papel importante en algunos
proyectos Scrum.

Los roles secundarios pueden ser:

ü  SOCIO(S)
Es un termino que incluye a los clientes, los usuarios y patrocinadores, que a menudo
interactúan con el Product Owner, Scrum Master y Scrum Team para proporcionarles las
entradas (inputs) y facilitar la creación del producto del proyecto, servicio, o cualquier otro
resultado.
u  Clientes
u  Los usuarios
u  Patrocinador

ROLES EN SCRUM
ü  VENDEDORES
Los vendedores incluyen a individuos u organizaciones externas que ofrecen productos y

servicios que no están dentro de las competencias básicas de la organización del proyecto.

ü  CUERPO DE ASESORAMIENTO SCRUM
Es una función opcional. Por lo general, se compone de un grupo de documentos y/o un

grupo de expertos que normalmente están involucrados en la definición de los objeHvos
relacionados con la calidad, las regulaciones gubernamentales, la seguridad y otros
parámetros clave de la organización. Estos objeHvos guían la labor llevada a cabo por el
Product Owner, Scrum Master, y Scrum Team. El Scrum Guidance Body también ayuda a
capturar las mejores pracHcas que se deben uHlizar en todos los proyectos Scrum en la organización.

FASES DE SCRUM
FLUJO DE TRABAJO

•  El ciclo de Scrum comienza con la fase de inicio, durante la cual se determina la visión del
proyecto y se crea la lista priorizada de pendientes del producto.

•  Posteriormente este trabajo es terminado en una seria de Sprint, cada Sprint comienza con
una reunión de planificación del Sprint , durante la cual se determinan las tareas paral
siguiente Sprint.

•  Un Sprint suele durar entre una y seis semanas durante el cual el Equipo Scrum trabaja en la
creación de los Entregables en incrementos del Producto potencialmente listos en .

•  Durante el Sprint, se llevan a cabo las reuniones diarias de pie muy concretos donde los
miembros del equipo discuten progresos diarios y cualquier otro impedimentos.

•  Al final del Sprint, se lleva a cabo una reunión de revisión del Sprint , donde el Product Owner
recibe una demostración del entregable y decide si lo acepta o rechaza.
•  El ciclo de Sprint termina con una ulHma reunión de RetrospecHva del Sprint
FASES DE SCRUM

Un Proyecto Scrum sigue un modelo de cinco fases. Las cinco fases son las siguientes:
1. Inicio
2. Planificación y Es?mación
3. Implementación
4. Revisión y Retrospec?va
5. Lanzamiento
La reunión diaria es una ac?vidad del equipo Scrum, mientras que el propietario
del producto juega un papel dominante en la reunión de revisión de Sprint.

FASES DE SCRUM Scrum Flow
Release Daily
Planning
MeeOng Create
Deliverables Daily
Release Schedule
Standup
MeeOng
Sprint
1-6 weeks
Project Project Vision Priori?zed Sprint Accepted

Business Case Statement Product Backlog Backlog Deliverables
Project Vision MeeOng Sprint Planning MeeOng Sprint Review MeeOng
Retrospect MeeOng
FASES DE SCRUM
PLANIFICACIÓN Y REVISIÓN Y
INICIO IMPLEMENTACIÓN LANZAMIENTO
ESTIMACIÓN RETROESPECTIVA
Creación de la visión Creación de Historias de Creación de Convocar a un Scrum de

Envió de entregables
del Proyecto Usuario. entregables. Scrum
Aprobación, esHmación
IdenHficación del SM y Realizar reunión Demostración y RetrospecHva del
asignación de Historia
Socios diaria de pie validación del Sprint Proyecto.
de Usuario
Mantenimiento de la
Formación del equipo
Creación de Tareas lista priorizada de RetrospecHva del Sprint
SCRUM
pendientes P.
Desarrollo de Épicas EsHmación de Tareas
Creación de lista
Creación de la lista de
Priorizada de
pendientes del Sprint
Pendientes
Realizar la planificación
de lanzamiento
FASE DE INICIO
PROCESOS RELACIONADOS CON LA INICIACIÓN

q  Creación de la visión del proyecto.
q  IdenHficación del Scrum Master y los socios.
q  Formación del Equipo Scrum
q  Desarrollo las Épicas.
q  Crear de la lista priorizada de pendientes del producto.
q  Realizar la planificación de lanzamiento
FASE DE INICIO

q  PROCESO 1: CREAR VISIÓN PROYECTO
.
En este proceso, se revisa el caso de negocio del
proyecto a fin de crear una Declaración de la Visión del
Proyecto que servirá de inspiración y proporcionará un
enfoque de todo el Proyecto. En este proceso se
idenHfica al propietario del producto.

El propietario del producto debe entender el caso de negocio del proyecto y crear la
visión del proyecto relacionada con el caso de negocio del proyecto. El propietario
del producto debe tener en cuenta y comprender en términos de mercado también.

FASE DE INICIO
ENTRADA: Principal entrada para este proceso.

q  CASO DE NEGOCIO DEL PROYECTO
Puede ser un documento bien estructurado o simplemente una declaración verbal que
expresa la razón para iniciar un proyecto. Independientemente del formato a menudo
incluye información sustancial sobre los antecedentes del proyecto, los objeHvos del
negocio y los resultados deseados, un FODA y Gap Análisis, una lista de los riesgos
idenHficados y las esHmaciones de Hempo, esfuerzo y costo.

HERRAMIENTAS : Principales Herramienta para este procesos.

q  REUNIÓN DE VISIÓN DEL PROYECTO
La reunión de la visión del proyecto es una reunión con los socios del programa, el
propietario del producto del programa, el Scrum Master del programa, y el jefe
propietario del producto. Estos ayudan a idenHficar el contexto empresarial, los
requerimientos de negocio, y las expectaHvas de los socios a fin de desarrollar una
declaración de la visión del proyecto eficaz.

FASE DE INICIO

SALIDAS : Principales salidas para este proceso.

q  PROPIETARIO DEL PRODUCTO IDENTIFICADO
Uno de los resultados de este proceso es idenHficar al Propietario del producto. El
propietario de producto es la persona responsable de lograr el valor máximo empresarial
para el proyecto.

q  DECLARACIÓN DE LA VISIÓN DEL PROYECTO
El resultado clave del proceso Crear la Visión del Proyecto es una Declaración de Visión
del Proyecto bien estructurado. Una buena visión del proyecto explica la necesidad del
negocio y que es lo que el proyecto Hene como objeHvo saHsfacer, en lugar de como se
va a saHsfacer la necesidad.

FASE DE INICIO
q  ELEVATOR PITCH (DECLARACIÓN DE LA VISIÓN DEL PROYECTO)

Para generar la visión del producto presentaré la técnica del elevator pitch, una de las
acHvidades de la Incepción Ágil. Esta toma su nombre de una supuesta situación en la
que, en lo que dura un viaje en ascensor, algo menos de 2 minutos, se debe despertar el
interés del interlocutor por el proyecto, ya sea un inversor, un cliente potencial o un
posible colaborador.
En el contexto de la planificación ágil esta técnica ayuda a arrancar conversaciones que
permiten comparHr información, alinear y enfocar a las personas involucradas en la
dirección correcta del proyecto/producto y hacia un mismo objeHvo y, eventualmente
hasta permite tomar decisiones. Será a parHr de esta visión, que marca el valor de
negocio, por la que el Propietario del Producto priorizará los epicas y las historias de
usuario.

Se trata de un mensaje corto, de tres o cuatro frases, donde se condensa la propuesta de
valor, es decir el problema idenHficado y la manera en que se pretende resolverlo,
transmiHendo ideas claras, concisas y sintéHcas.

FASE DE INICIO
q  EJEMPLO

PARA sociedades propietarias de drones.
QUIEN Henen necesidad de asegurar sus drones y
cubrir su responsabilidad civil.
EL producto prodrone QUE ES UN seguro
gesHonable de forma on-line.
QUE es un producto específico para los
profesionales de drones.
A DIFERENCIA DE nuestra competencia que solo
dispone de un producto de contratación
presencial.
NUESTRO PRODUCTO es totalmente
personalizable de forma on-line en cuanto a
coberturas y duración se refiere.

Como consejo para la uOlización de este patrón de forma posiOva,
si hay elementos en negaOvo en la parte de A DIFERENCIA DE,
propongo escribirlos en posiOvo en NUESTRO PRODUCTO,
convierte nuestro mensaje en más posiOvo y por tanto en más
poderoso.
FASE DE INICIO
PROCESO 2 : IDENTIFICACIÓN DEL SCRUM MASTER Y LOS
SOCIO(S)

En este proceso, se idenHfica al Scrum Master y al socio uHlizando
criterios de selección específicos.

El propietario del producto puede aceptar la entrada de otras
fuentes, tales como el Programa de Scrum Master, Matriz de
Recursos Organizacional, Matrix Habilidades y Requisitos, el
Cuerpo de Orientación Scrum, y así sucesivamente para elegir
una persona como Scrum Master.

ENTRADAS : Las principales entradas.

q  PROPIETARIO DEL PRODUCTO (ver salidas del proceso Crear
Proyecto Visión)
q  DECLARACIÓN DE LA VISIÓN DEL PROYECTO (ver salidas de
Crear Proyecto Visión proceso)

FASE DE INICIO
HERRAMIENTAS
q  CRITERIOS DE SELECCIÓN
1. Habilidades para la resolución de problemas.
2. Disponibilidad.
3. Compromiso.
4. EsHlo de Liderazgo de Servicial

SALIDA
q  SCRUM MASTER IDENTIFICADO
Un Scrum Master es un facilitador (Líder de Servicial) que se asegura de que el Equipo
Scrum esté dotado de un ambiente propicio para completar el proyecto con éxito.
q  SOCIO(S) IDENTIFICADOS
Es un término colecHvo que incluye a los clientes, usuarios y patrocinadores, con frecuencia
interactúan con el equipo principal Scrum e influyen en el proyecto.

Es importante recordar que los stakeholders incluye a todos los clientes, usuarios y
patrocinadores, quienes a menudo interactúan con el Product Owner, Scrum Master y
Scrum Team para proveer entradas y facilitar la creación de los productos del proyecto.

FASE DE INICIO
PROCESO 3: FORMACIÓN DEL SCRUM TEAM
En este proceso se idenHfica a los miembros del equipo, normalmente, el Propietario del
producto es el responsable principal de la selección de los miembros del equipo, pero con
frecuencia lo hace en colaboración con el Scrum Master.

ENTRADAS
q  PROPIETARIO DEL PRODUCTO
q  SCRUM MASTER
q  DECLARACION DE LA VISIÓN DEL PROYECTO

HERRAMIENTAS

q  SELECCIÓN DEL EQUIPO SCRUM
El Equipo Scrum es la base de cualquier proyecto de Scrum y tener a los miembros
adecuados para el equipo es vital para la entrega exitosa de los proyectos Scrum. Los
miembros del equipo Scrum son generalistas/especialistas ya que cuentan con
conocimiento de diversos campos y son expertos en al menos uno.
FASE DE INICIO
SALIDAS

q  EQUIPO SCRUM IDENTIFICADO

El Equipo Scrum es a veces conocido como el Equipo de Desarrollo, es un grupo o equipo de
personas que son responsables de la comprensión de los requerimientos del negocio
especificados por el propietario del producto, la esHmación de las historias de los usuarios y
la creación de los entregables del proyecto.
FASE DE INICIO
PROCESO 4: DESARROLLO DE EPICAS
En este proceso la declaración de la visión del proyecto sirve como la base para el desarrollo
de las épicas , se pueden llevar a cabo reuniones de grupos de usuarios para hablar sobre las
épicas que sean adecuadas.

ENTRADAS

q  EQUIPO PRINCIPAL SCRUM
q  DECLARACIÓN DE LA VISIÓN DEL PROYETO

HERRAMIENTAS

q  REUNIONES DE GRUPO DE USUARIOS
Involucra a los socios relevantes (principalmente usuarios o clientes del producto), ellos
proporcionan al equipo principal Scrum, información de primera mano acerca de sus
expectaHvas. Esto ayuda en la formulación de los Criterios de Aceptación para el producto
y proporciona información valiosa para el desarrollo de las Épicas.

FASE DE INICIO
SALIDAS

q  ÉPICAS
Las Épicas se redactan en las etapas iniciales del proyecto, cuando la mayoría de las
historias de usuario son funcionalidades de alto nivel o descripciones de productos que
están ampliamente definidas. Las épicas son historias de usuarios grandes sin refinar en la
lista priorizada d e pendientes del producto.

q  PERSONAS
Los protoHpos son personajes ficHcios altamente detallados. Estos representan a la
mayoría de los usuarios y otros socios que puede ser que no uHlicen directamente el
producto final. Los protoHpos se crean para idenHficar las necesidades de los usuarios. La
creación de protoHpos específicos puede ayudar al equipo a entender mejor a los usuarios,
sus necesidades y metas. Basado en una protoHpo, el propietario del producto puede
priorizar de manera más efecHva las funciones para crear la lista priorizada de pendientes
del producto.

Creación de un proto?po: Implica la asignación de un nombre fic?cio y de preferencia una foto para
el personaje, como una fotografia de archivo . Al proto?po se le incluirá́ atributos muy específicos
como la edad, el género, la educación, el medio ambiente, los intereses y metas.
FASE DE INICIO
PROCESO 05: CREACION DE LA LISTA PRIORIZADA DE PENDIENTES DEL PRODUCTO.

En este proceso, se refina y crean las épicas, y luego se priorizan para crear una lista
priorizada de pendientes del producto, en ese momento también se establecen los criterio
de terminado.

El Product Backlog es una lista de requisitos que cuando se convierta en funcionalidades
del producto potencialmente entregables, cumplirá con la Visión del producto.

ENTRADAS

q  ÉPICAS
q  PROTOTIPOS (PERSONAS)

FASE DE INICIO
HERRAMIENTAS
METODOS DE PRIORIZACIÓN DE LAS HISTORIAS DE USUARIO: Se presentan algunas de las
técnicas que se uHlizan para dar prioridad a las historias de usuarios o requerimientos en la
lista priorizada de pendientes del producto sobre la base del valor en el negocio.

q  ESQUEMA DE PRIORIZACIÓN MoSCoW
ObHene su nombre de las primeras letras de las frases "must have" (debe tener), should
have‖ (debería tener), "could have‖ (podría tener), y "will not have‖ (no tendrá)”.Las
eHquetas están en orden de prioridad decrecientes con historias de usuarios con
caracterísHcas “Debería tener” siendo aquella sin las que el producto no tendrá valor, e
historias de usuario con caracterísHcas de “me gustaría que tuviera” , siendo aquellas que a
pesar de que seria bueno tener , no se es necesario incluir.

q  COMPARACIÓN POR PARES
Es una técnica donde se prepara una lista de todas las Historias de Usuarios en la lista
Priorizada de pendientes del Producto. A conHnuación, cada historia de Usuario se toma de
forma individual y se compara con las otros Historias de Usuarios en la lista, uno a la vez.
Cada vez que dos Historias de Usuarios se comparan, se toma una decisión en cuanto a cuál
de los dos es más importante. Por medio de este proceso, se puede generar una lista de
priorizada de las historias de usuarios.
FASE DE INICIO
HERRAMIENTAS

q  METODO DE LOS 100 PUNTOS
El Método de 100 Puntos fue desarrollado por Dean Leffingwell y Don Widrig (2003). Se
trata de darle al Cliente 100 puntos que pueden usar para votar por los Historias de
Usuarios que son más importantes. El objeHvo es dar más peso a las Historias de Usuarios
que son de mayor prioridad en comparación con las otras Historias de Usuarios
disponibles. Cada miembro del grupo asigna puntos a las diversas Historias de Usuarios,
dando más puntos a los que se sienten son más importantes. Al finalizar el proceso de
votación, la priorización se determina calculando el total de puntos asignados a cada
historias de usuarios.
FASE DE INICIO
SALIDAS
q  LISTA PRIORIZADA DE PENDIENTES DEL PRODUCTO
El Propietario del Producto desarrolla una lista Priorizada de pendientes del Producto, que
conHene una lista priorizada de los requerimientos del negocio y de los Proyectos escritos en
forma de Épica(s), que son historias de usuarios de alto nivel. El lista priorizada de
pendientes del producto se basa en tres factores principales: el valor, riesgo o
incer?dumbre, y dependencias. También se le conoce como la lista de pendientes del
producto del riesgo ajustado, dado a que incluye Riesgos idenHficados y evaluados
relacionados con el Proyecto. También incluye cambios aprobados que pueden ser
priorizados adecuadamente en el la lista priorizada de pendientes del producto.

q  CRITERIO DE TERMINADO
Criterio de Terminado es un conjunto de reglas que se aplican a todos las historias de
Usuarios. Una definición clara de terminado es críHca, ya que elimina la ambigüedad de los
requisitos y ayuda a que el equipo se adhiera o se fije a las normas de calidad obligatorias.
Esta clara definición se uHliza para crear los Criterios de Terminado, que son un resultado
del proceso de Crear la Lista de Pendientes del Producto. Una historia de Usuario se
considera terminada cuando se demuestra y se aprueba por el propietario del Producto que
juzga sobre la base de los Criterios de Terminado y los Criterio de Aceptación de la Historia
del Usuario.
FASE DE INICIO
Ejemplo
Ejemplo de criterio de terminado:

Proyecto: Diseñar las nuevas variantes de un coche deporHvo popular en LRA Ltd.

Criterio de terminado:
1.  El diseño es aprobado por la división de QA.
2.  El protoHpo pasa todas las pruebas solicitadas por la División de Aerodinámica.

q 

FASE DE INICIO
q  CRITERIO DE TERMINADO (DONE)

Es importante que el dueño de producto y el equipo estén de acuerdo en una definición
clara de “terminado”. ¿Está terminada una historia cuando todo el código ha sido
chequeado? ¿O está terminada cuando se ha instalado en un entorno de pre-producción y
ha sido verificada por un equipo de pruebas de integración? Siempre que es posible,
uHlizamos la definición “lista para pasar
a producción”, aunque a veces debemos conformarnos con “instalado en preproducción y
lista para las pruebas de aceptación”.

Ejemplo
Todos los criterios de aceptación funcionan correctamente
Todos los archivos fuente están en el repositorio y el build se ejecuto saHsfactoriamente.

.

FASE DE INICIO
PROCESO 6: REALIZAR LA PLANIFICACIÓN DE LANZAMIENTO
En este proceso, el equipo principal de Scrum revisa las historias de usuarios en la lista
priorizada de pendientes del producto para desarrollar un cronograma de planificación del
Lanzamiento, que es esencialmente un programa de implementación por fases que se puede
comparHr con los socios del proyecto. También se determina la duración del Sprint en este
proceso.

Las caracterís?cas de negocio con valor superior, serán de mayor prioridad en la Priori?zed
Product Backlog , Esto asegura el valor más alto posible después de cada Sprint.

ENTRADAS

q  EQUIPO PRINCIPAL SCRUM*
q  SOCIOS*
q  DECLARACIÓN DE LA VISIÓN DEL PROYECTO*
q  LISTA PRIORIZADA DE PENDIENTES DEL PRODUCTO*
q  CRITERIO DE TERMINADO*
FASE DE INICIO
HERRAMIENTAS

q  SESIONES DE PLANIFICACIÓN DE LANZAMIENTO*
Las reuniones de planificación del lanzamiento se llevan a cabo para desarrollar un plan de
lanzamiento. El plan define cuando varios conjuntos de funcionalidad o Productos
uHlizables serán entregados al Cliente. En Scrum, el objeHvo principal de una reunión de
planificación de lanzamiento es hacer que el Equipo Scrum tenga una visión general de los
lanzamiento y el calendario de entrega del Producto que están desarrollando para que
puedan alinearse con las expectaHvas del propietario del producto y los socios relevantes
principalmente (Patrocinador del Proyecto ).

q  METODOS DE PRIORIZACIÓN DE LANZAMIENTO*
Los métodos de priorización de lanzamiento se uHlizan para desarrollar un Plan del
lanzamiento. Estos métodos son específicos de la organización y generalmente son
determinados por la alta dirección de la organización.

Las organizaciones ?enen una estrategia con la liberación de los Producto. Algunas
organizaciones prefieren despliegue con?nuo, donde se produce una liberación o lanzamiento
después de la creación de la funcionalidad ú?l especificada. Otras organizaciones prefieren
despliegue por etapas, donde las liberaciones se hacen en intervalos predefinidos de ?empo.
FASE DE INICIO
SALIDAS

q  CRONOGRAMA DE PLANIFICACIÓN DE LANZAMIENTO*
Un Cronograma de Planificación del Lanzamiento es uno de los resultados más importantes
del proceso llamado realizar la planificación de lanzamiento. Un cronograma de
Planificación del Lanzamiento indica que los entregables van a ser lanzados a los Clientes,
junto con intervalos planificados, y fechas para los lanzamientos.

q  DURACIÓN DEL SPRINT
Basado en las diversas entradas que incluyen los requerimientos del negocio y el
cronograma de planificación, el propietario del Producto y el equipo deciden sobre el
duración del Sprint para el proyecto. Una vez determinado, la duración del Sprint a
menudo sigue con frecuencia la misma durante todo el proyecto.

Un Sprint podría ser asignado a un bloque de 1 a 6 semanas. Sin embargo, para
obtener los máximos beneficios de un proyecto Scrum, siempre se recomienda mantener
el Sprint en un bloque se ?empo de 4 semanas, a menos que existan proyectos con
requisitos muy estables, donde los Sprints pueden extenderse hasta 6 semanas.

FASE DE PLANIFICACIÓN Y ESTIMACIÓN
PROCESOS RELACIONADOS CON LA PLANIFICACIÓN DE TAREAS DE ESTIMACIÓN

La fase de Planificación y esHmación consiste en procesos relacionados con la
planificación y esHmación de tareas.

q  Creación de las historias de usuario.
q  Aprobar, EsHmar y comprometerse con las historias de usuario
q  Creación de Tareas
q  EsHmación de Tareas
q  Creación de la lista de pendientes del Sprint
PROCESO 1 : CREACIÓN DE HISTORIAS DE USUARIO

En este proceso se crean las historias de usuarios y los criterios de aceptación de las
historia del usuario. Los historias de usuarios son generalmente escritos por el propietario
del producto y están diseñados para asegurar que los requisitos del cliente estén
claramente representados, y pueden ser plenamente comprendidos por todos los socios.
Se pudieran llevar a cabo ejercicios de historias de usuarios. Los cuales involucran al
equipo Scrum, resultando en la creación de dichas historias. Estas se incorporan a la lista
de pendientes del producto.

ENTRADAS

q  LISTA PRIORIZADA DE PENDIENTES DEL PRODUCTO
q  CRITERIOS DE TERMINADO
q  PROTOTIPOS

HERRAMIENTAS

q  EXPERIENCIA EN LA REDACCIÓN DE HISTORIAS DE USUARIO
El propietario del producto, con base en su interacción con los socios, y su conocimiento
del negocio, en la experiencia y las aportaciones del equipo, desarrolla las historias de
usuarios que formarán la lista inicial pendientes del Producto para el proyecto.
La lista priorizada de pendientes del Producto representa la suma total de lo que debe
completarse para el proyecto.

El objeHvo de este ejercicio es crear historias de usuarios elaborados y refinados que
pudieran ser aprobadas, esHmadas y asignadas por el Equipo Scrum. En ocasiones, el
propietario del producto puede incluir a un analista de negocios para que ayude con la
redacción de historias de usuario.

Aunque el propietario del Producto Hene la responsabilidad de escribir las historias de
usuario, y generalmente lleva a cabo esta acHvidad por sí mismo, Se puede llevar a cabo un
taller de historia de usuario si así se desea.

SALIDAS
q  HISTORIAS DE USUARIO
Los historias de usuarios se apegan a una estructura específica y predefinida, y es una
manera simple de la documentación de los requisitos y de la funcionalidad deseada del
usuario final.

Una historia de usuario indica tres cosas acerca de la exigencia:

¿Quién, qué y por qué?.

Los requisitos expresados en Historias de Usuarios son declaraciones breves, simples y
fáciles de entender. El formato estándar predefinido da como resultado en una mejor
comunicación mejorada entre los socios, así como mejores esHmaciones por parte del
equipo. Algunos Historias de Usuarios pueden ser demasiado extensas para poder
manejarse dentro de un sólo Sprint.

A estas amplias historias de usuarios a menudo se llaman Épicas. Una vez que los Épicas
aparecen en la lista priorizada de pendientes del producto para completarse en otro
Sprint, se fragmentan a un más y se convierten en historias de usuarios.

EJEMPLO

Formato:
Como <rol/ persona>, yo debería <requisito> así́ <beneficio>.
Ejemplo de historia de usuario:
Como administrador de banco de datos, debería reverHr una canHdad especifica de
actualizaciones de base de datos para que la versión deseada de esta se restaure.

q  CRITERIOS DE ACEPTACIÓN DE LAS HISTORIAS DEL USUARIO*
Cada historia de usuario cuenta con un criterio de aceptación. Las historia de usuario
suelen ser subjeHvas, de tal forma que los criterios de aceptación proporcionan la
obje?vidad requerida para que las historias de usuario se consideren como terminadas o
no terminadas durante la revisión del Sprint.
EJEMPLO
CRITERIOS DE ACEPTACIÓN DE LAS HISTORIAS DEL USUARIO*
Proto?po del cliente (persona): Janine es una profesional de 36 años; está casada y Hene tres hijos.
Es una mujer ocupada y exitosa que equilibra su vida profesional y personal. Se siente cómoda con la
tecnología y le gusta adoptar productos y servicios innovadores. Siempre está conectada al Internet a
través de múlHples disposiHvos y regularmente hace compras en portales de comercio electrónico.

Historia de usuario: “Como compradora en línea, debo contar con la posibilidad de ahorrar y ver mi
orden desde cualquiera de mis disposiHvos para poder completar el proceso de orden cuando mejor
me convenga”.

Criterios de aceptación:
• Todas las órdenes en progreso deben guardarse como pendiente (Borrador) cada 5 segundos en la
cuenta del usuario que haya iniciado una sesión.

• Las nuevas órdenes pendientes deben mostraste como noHficaciones en cualquier disposiHvo
(Móvil o email)
PROCESO 2 : APROBACIÓN, ESTIMACIÓN Y ASIGNACIÓN DE HISTORIAS DE USUARIO

Después de crear las historias de los usuarios, estas Henen que ser aprobadas por el
propietario del producto, esHmadas y compromeHdas por el Equipo Scrum.

u  Aprobar: El propietario del producto evalúa las historias de usuarios, para que estén
alineadas con los requerimientos del negocio y que correspondan a sus respecHvos
criterios de aceptación.

u  Es?mado: Después de que las historias del usuario son aprobados por el propietario del
producto, el equipo central de Scrum comienza a trabajar en la es?mación de ellas.
EsHmar con precisión los plazos y requisitos del trabajo es un aspecto críHco para
cualquier empresa que quiere garanHzar una gran experiencia en la entrega del proyecto
para su cliente.

u  Asignación: Después de la esHmación, el equipo Scrum se compromete a un
subconjunto de historias de usuarios autorizados y es?madas para el siguiente Sprint,
por lo tanto, las historias de los usuarios aprobadas, esHmadas y asignadas se convierten
en parte de la Pila de Sprint (Sprint Backlog).
ENTRADAS
Los siguientes son los principales acHvidades de este proceso:
q  HISTORIA DE USUARIO
q  CRITERIOS DE ACEPTACIÓN DE LAS HISTORIAS DE USUARIO

HERRAMIENTAS
q  REUNIONES DEL GRUPO DE USUARIOS
Implica convocar a los a relevantes Socios (principalmente usuarios o clientes del producto).
Ellos proporcionan al equipo principal Scrum, información de primera mano acerca de las
expecta?vas de los usuarios.

SALIDAS
q  APROBAR, ESTIMAR, Y COMPROMETERSE CON LAS HISTORIAS
Una vez aprobados las historias de usuario son esHmadas por el equipo uHlizando las
disHntas técnicas de esHmación. Después de la esHmación el equipo se compromete a un
subconjunto de historias de usuarios que creen pueden completar en el próximo Sprint.
Estas historias de usuario aprobados, es?mados y asignadas se conver?rán en parte del
Sprint Backlog.
q  PLANNING POKER
Es una técnica de esHmación que implementa el consenso para esHmar los tamaños
relaHvos de las historias de usuario o el trabajo necesario para desarrollarlos.

En el póker de planificación, a cada miembro del equipo se le asigna una baraja. Cada carta
está enumerada en forma secuencial y los números representan la complejidad del
problema en términos de Hempo o esfuerzo, según lo esHmado por el miembro del equipo.

El propietario del producto elige una historia de usuario de la lista priorizada de pendientes
del producto y se la presenta al equipo. Los miembros del equipo Scrum evalúan la historia
de usuario e intentan entenderla mejor, antes de brindar su es?mación para su desarrollo.

Después, cada miembro elige una carta de la baraja que represente su esHmación para la
historia de usuario. Si la mayoría, o todos los miembros del equipo seleccionan la misma
carta, entonces el cálculo que indique la carta será el esHmado para esta historia de usuario.
Si no hay un consenso, entonces los integrantes del equipo discuten las razones de la
selección.

q  FIRST TO FIVE

Es un mecanismo sencillo y rápido para lograr el consenso en un grupo y guiar una
conversación. Tras el debate inicial sobre una propuesta o una decisión pendiente, se les
pide a los miembros del equipo Scrum que voten en una escala de 1 a 5 uHlizando sus
dedos.

1.  Un dedo: No estoy de acuerdo con la conclusión del grupo y tengo grandes inquietudes.
2.  Dos dedos: No estoy de acuerdo con la conclusión del grupo y me gustaría hablar sobre
algunos puntos.
3.  Tres dedos: No estoy seguro y me gustaría sumarme a la conclusión de consenso del
grupo.
4.  Cuatro dedos: Estoy de acuerdo con la conclusión del grupo y me gustaría discuHr
algunos asuntos menores.
5.  Cinco dedos: Estoy totalmente de acuerdo con la conclusión del grupo.

q  ESTIMACION POR AFINIDAD

La esHmación por afinidad (del inglés: Affinity EsOmaOon) es una técnica que se uHliza para
esHmar rápidamente un gran número de historias de usuarios con el uso de categorías.
UHlizando notas adhesivas o fichas y cinta, cada equipo coloca las historias de usuario en la
pared o en cualquier otra superficie en orden desde la más pequeña hasta la más grande.

Cada integrante del equipo inicia con un conjunto de historias de usuario de toda la lista
priorizada de pendientes del producto para colocarse por tamaño relaHvo. Esta colocación
inicial se hace en silencio.

Una vez que todos han colocado en la pared sus historias de usuario, el equipo las revisa y
las puede mover según sea necesario.

Esta segunda parte del ejercicio incluye discusiones. Por úlHmo, el propietario del producto
indicará en la pared algunas categorías de tamaño. Dichas categorías pueden ser pequeñas,
medianas o grandes, o bien, pueden estar enumeradas uHlizando valores de punto de la
historia para indicar el tamaño relaHvo.
Después el equipo reubicará las historias de usuario en dichas categorías en el paso final del
proceso.

q  PROCESO 3: CREACIÓN DE TAREAS
En este proceso, las historias de usuario , aprobadas esHmadas y asignadas se dividen en
tareas específicas y se compilan en un Lista de Tareas. Con frecuencia, una reunión de
planificación de tareas se convocará para llevarlo a cabo.
ENTRADAS
Principal entrada:

En las etapas iniciales del desarrollo, la mayoría de las historias de usuarios son descritas
sobre funcionalidades de alto nivel, por lo que estas Henen que subdividirse en tareas más
simples y facHbles.

HERRAMIENTAS
q  REUNIÓN DE PLANIFICACIÓN DE TAREAS
SALIDAS
q  REUNIÓN DE PLANIFICACIÓN DE TAREAS
En el marco de esta reunión, los miembros del equipo Scrum revisan las historias de los
usuarios compromeHdos y discuten en detalle para eliminar ambigüedades y resolver todas
las preguntas.
En la primera parte de la reunión de planificación de tareas, el propietario del producto
sugiere cuales historias de usuarios deben ser parte de la Sprint en base a la es?mación
proporcionada por el Equipo Scrum sobre cuántas historias de usuario pueden realizarse
en un Sprint.

En la segunda parte de la reunión de planificación de tareas, el Equipo Scrum determina
cómo converHr las historias de usuarios seleccionadas en incrementos del producto y
dividirlas en tareas.
Para ayudar a que el grupo se concentre en el tema, esta reunión es ?me-boxed(Bloque de
?empos asignado), con una duración estándar limitada de dos horas por semana de
duración del Sprint
PROCESO 4: ESTIMACIÓN DEL TAREAS
En este proceso, durante las reuniones de planificación de tareas, el equipo principal Scrum
esHma el esfuerzo necesario para realizar cada tarea en la lista. El resultado de este proceso
es un lista del esfuerzo esHmado.

ENTRADAS
Los siguientes son los principales acHvidades de este proceso:
q  LISTA DE TAREAS
q  CRITERIOS DE ACEPTACIÓN DE LAS HISTORIAS DE USUARIO

HERRAMIENTAS
q  REUNIONES DE ESTIMACIÓN DE TAREAS
Las reuniones de esHmación de tareas le permiten al equipo Scrum esHmar el trabajo
necesario para completar una tarea o conjunto de tareas, idenHficando el esfuerzo de las
personas y otros recursos necesarios para llevar a cabo los trabajos dentro de un Sprint
determinado. En tales reuniones, los integrantes del equipo Scrum uHlizan la lista de tareas
para calcular la duración y el esfuerzo de las historias de usuario que se completarán en el
Sprint.
q  CRITERIOS DE ESTIMACIÓN
El objeHvo principal del uso de los criterios de esHmación uHlizar es mantener los tamaños
relaHvos de esHmación y minimizar la necesidad de volver a realizar el calculo. Los criterios
de aceptación se pueden expresar de muchas maneras, dos ejemplos comunes son los
puntos de historia y ?empo ideal.
SALIDA

q  LISTA DE TAREAS DEL ESFUERZO ESTIMADO
Es una lista de las tareas asociadas con las historias de
usuario asignadas que se incluyen en un Sprint.

Normalmente la precisión de las esHmaciones varía
dependiendo de las habilidades del equipo. El
esfuerzo esHmado se expresa en términos de los
criterios de esHmación aceptadas por el equipo.

El lista de tareas del esfuerzo esHmado la uHliza el
equipo Scrum durante la reuniones de planificación
del Sprint para crear la lista de pendientes del Sprint
Sprint y la Grafica de trabajo pendiente(Burndown
Chart)

q  PROCESO 5: CREACIÓN DE LA LISTA DE PENDIENTES DEL SPRINT
En este proceso, el equipo principal Scrum lleva a cabo un reunión de planificación del
sprint donde el grupo crea una lista priorizada de pendientes del Sprint que conHene todas
las tareas que deben completarse en el Sprint.

El Scrumboard debe mantenerse preferentemente manualmente en papel o una pizarra
blanca y se muestra para mejorar la transparencia, pero también puede ser mantenida
electrónicamente en una hoja de cálculo.
PLANEAR Y ESTIMAR
q  PROCESS 5: CREACIÓN DE LA LISTA DE PENDIENTES DEL SPRINT

SCRUMBOARD
ENTRADAS
q  LISTA DE TAREAS DEL ESFUERZO ESTIMADO
q  DURACIÓN DEL SPRINT

HERRAMIENTAS

q  REUNIONES DE PLANIFICACIÓN DEL SPRINT *
Durante las reuniones de planificación del Sprint, las historias de usuario que son
aprobadas, esHmadas y asignadas, se someten a discusión del equipo Scrum.
Cada miembro del equipo Scrum también u?liza la lista de tareas del esfuerzo para
seleccionar las tareas en las que planean trabajar en el Sprint, con base en sus
habilidades y experiencias.

El equipo Scrum elabora también la lista de pendientes del Sprint y la grafica de
pendientes del sprint(Burndown Chart) con el uso de historias de usuario y la lista de
tareas del esfuerzo esHmado durante los reuniones de planificación del Sprint.

SALIDAS

q  LISTA DE PENDIENTES DEL SPRINT
A la lista de las tareas a ser ejecutadas por el equipo Scrum en el siguiente Sprint se llama
lista de pendientes del Sprint.
Es una prácHca común que la lista de pendientes del Sprint se represente en un tablero
Scrum(Scrumboard), el cual brinda un percepción visual constante sobre el estado de las
historias de usuarios en la lista de pendientes.

q  GRAFICA DE TRABAJO PENDIENTE DEL SPRINT(SPRINT BURNDOWN CHART)
Sprint Burndown Chart es un grafico que muestra la canHdad de trabajo pendiente en el
actual sprint. El Sprint Burndown Chart inicial es acompañado por una burndown planeado.
El Sprint Burndown Chart debe actualizarse al final de cada día al completar el trabajo. Este
grafico muestra el progreso que se ha hecho por el equipo Scrum y también permite la
detección de cálculos que pudieron haber sido incorrectos.

Si la Gráfica del Trabajo pendiente del Sprint muestra que el Equipo Scrum no va por el
rumbo correcto en el trayecto del sprint, el Scrum Master debe iden?ficar los obstáculos o
impedimentos y tratar de eliminarlos, para una conclusión sa?sfactoria.
PLANEAR Y ESTIMAR

FASE DE IMPLEMENTACIÓN
La fase de implementación está relacionada a la ejecución de las tareas y acHvidades para

crear el producto de un proyecto. Estas acHvidades incluyen la creación de varios
entregables, la realización de reuniones diarias (Daily Standup MeeHngs) y el
mantenimiento (revisiones, ajustes y actualización periódica) de la lista de pendientes del
producto en intervalos frecuentes.

PROCESOS RELACIONADOS CON LA IMPLEMENTACIÓN

q  Creación de Entregables.
q  Reunión Diaria de pie(Standup).
q  Mantenimiento(Refinamiento)de la lista priorizada de
pendientes del producto.(Groom PrioriHzed Product
Backlog ) .
PROCESO 1: CREACIÓN DE ENTREGABLES

En este proceso, el Equipo Scrum trabaja en las tareas Pendientes del Sprint para crear
Entregables del Sprint. A menudo se uHliza un Tabla de Scrum para realizar el seguimiento
del trabajo y acHvidades que se llevan a cabo. Los Incidentes o problemas que enfrenta el
Equipo Scrum podrían actualizarse en un Impedimento Log.
ENTRADAS
q  TABLERO SCRUM

La transparencia de Scrum proviene de las herramientas de información abiertamente
visibles como el Scrumboard, que muestra el progreso del equipo. El equipo u?liza un
Scrumboard para planificar y realizar un seguimiento de los progresos realizados
durante cada Sprint.

Registro de impedimentos (Impediment Log)*
Es cualquier obstáculo o barrera que reduce la producHvidad del Scrum Team. Los
impedimentos deben ser idenHficados, resueltos y eliminados para que el Equipo Scrum
siga trabajando con eficacia. Los impedimentos pueden ser internos del equipo, tales
como flujo de trabajo ineficiente o falta de comunicación, o pueden ser externos.
Algunos ejemplos de impedimentos externos pueden incluir problemas de licencia de
soNware o los requisitos de documentación innecesarios.
HERRAMIENTAS
q  EXPERIENCIA DEL EQUIPO*
Esto se refiere a la experiencia colecHva de los miembros del equipo Scrum para entender las
historia de usuario y tareas en la lista de pendientes del Sprint con el fin de crear los
entregables finales. La experiencia del equipo se uHliza para evaluar las entradas necesarias
para ejecutar el trabajo previsto del proyecto. El juicio y la experiencia de cada miembro se
aplica a todos los aspectos técnicos y de ges?ón del proyecto durante el proceso de
creación de entregables.
SALIDAS
q  ENTREGABLES DEL SPRINT*
La entrega debe poseer todas las caracterísHcas y funcionalidades definidas en las historias
de usuario incluidas en el Sprint, las cuales deben ser probadas con éxito.

q  TABLERO SCRUM ACTUALIZADO*
El Scrumboard se actualiza con regularidad a medida que el equipo produce más trabajo.

q  REGISTRO DE IMPEDIMENTOS ACTUALIZADO*
El registro de impedimentos se actualiza a medida que se idenHfican o se planifican
soluciones a los impedimentos
PROCESO 2 : REALIZAR REUNIÓN DIARIA DE PIE

Reunión Diaria de Standup es una reunión diaria de
corta duración, Time-boxed de 15 minutos. Los
miembros del equipo se reúnen para informar de sus
progresos en el Sprint y planificar las ac?vidades del
día.
La Reunión Diaria de Standup es facilitada por el Scrum
Master, donde cada miembro del Equipo Scrum
proporciona información de:
•  ¿Qué terminé ayer?
•  ¿Qué voy a terminar hoy?
•  ¿Qué impedimentos u obstáculos (si los hay) estoy
enfrentando en la actualidad?

Al centrarse en estas tres preguntas, todo el equipo
puede tener una comprensión clara de la situación
laboral.

ENTRADAS
q  SCRUM MASTER
q  GRAFICA DE TRABAJO PENDIENTE DEL SPRINT

HERRAMIENTAS
q  REUNION DIARIA DE PIE(Daily Standup MeeOng)*
La Reunión Standup diaria es una reunión diaria de corta duración que es de 15 minutos. Los
miembros del equipo se reúnen para reportar su progreso en el Sprint y planificar las
acHvidades del día.

q  TRES PREGUNTAS DIARIAS
En La reunión diaria facilitada por el Scrum Master, cada miembro del Scrum Team
proporciona información en forma de respuestas a tres preguntas especificas:
¿Qué terminé ayer?, ¿Qué voy a terminar hoy?, ¿Qué impedimentos u obstáculos (si los
hay) estoy enfrentando en la actualidad?.
SALIDAS
q  GRAFICA DE TRABAJO PENDIENTE DEL SPRINT
El Sprint Burndown chart es un gráfico que representa la canHdad de trabajo que queda en el
curso de Sprint.

q  REGISTRO DE IMPEDIMENTOS ACTUALIZADO

PROCESO 3: MANTENIMIENTO DE LA LISTA PRIORIZADA DE PENDIENTES DEL PRODUCTO

El tercer proceso en la fase de Implementación es el proceso Mantenimiento de la lista
priorizada de pendientes del Producto. Este proceso asegura que los elementos prioritarios
en la priorizada Product Backlog son refinados (filtrados/depurados), se recomienda
desHnar entre un 7% a 10% del Hempo de cada Sprint para refinar el atraso.

El propietario del producto es responsable de la preparación del Product Backlog priorizado,
que consiste en agregar o cambiar elementos prioritarios del Product Backlog para cumplir
los requisitos modificados y para proporcionar Historias de Usuario más detalladas para el
próximo Sprint.

Dado que el propietario del producto es responsable del Mantenimiento de la lista
priorizada de pendientes del Producto, él o ella ?ene múl?ples reuniones con las partes
interesadas.

ENTRADAS
q  PENDIENTES DEL PRODUCTO

HERRAMIENTAS
q  REUNIONES DE REVISIÓN DE LA LISTA PRIORIZADA DE PENDIENTES DEL PRODUCTO
La intención del reunión de revisión de la lista priorizada de pendientes del producto es
asegurar que las historias de usuario y los criterios de aceptación se en?endan y se
redacten adecuadamente por el propietario del producto de modo que reflejen los
requisitos de los Socios(clientes), que las historias de usuarios sean entendidas por todos
los miembros de equipo Scrum.

SALIDAS
q  LISTA PENDIENTES DEL PRODUCTO ACTUALIZADO
La lista actualizada de pendientes puede ser actualizado con nuevas historias de usuario,
nuevas solicitudes de cambio, nuevos IdenHfied Risks, User Stories actualizados o la nueva
priorización de User Stories existentes.

FASE DE REVISIÓN Y RETROSPECTIVA
La fase de revisión y retrospecHva se ocupa de la revisión de los entregables y del

trabajo que se ha realizado y determina las formas para mejorar las prac?cas y
métodos implementados para realizar el trabajo del proyecto. En las grandes
organizaciones , el proceso de revisión y retrospecHva puedes también incluir el
convocar a reuniones de Scrum de Scrum

PROCESOS RELACIONADOS CON LA REVISIÓN Y RETROSPECTIVA

q  CONVOCAR A UN SCRUM DE SCRUM
q  DEMOSTRACIÓN Y VALIDACIÓN DEL SPRINT
q  RETROESPECTIVA DEL SPRINT
q  PROCESO 1: CONVOCAR A UN SCRUM DE SCRUMS

Estas son reuniones preferentemente cortas (pero generalmente no ?me-boxed para
permi?r un mayor intercambio de información entre los equipos), donde los
representantes de los Equipos Scrums se reúnen para comparHr el estado de sus
respecHvos equipos. El Scrum of Scrums (SoS) MeeHng se llevará a cabo en intervalos
predeterminados o cuando sea requerido por los Equipos Scrum para facilitar el
intercambio de información entre ellos.

Cada representante de los Equipos Scrum proporcionan información de sus equipos.

q  PROCESO 1: REUNIÓN DE SCRUM DE SCRUMS

ENTRADAS
q  SCRUM MASTER O REPRESENTANTE DEL EQUIPO SCRUM
Un miembro de cada equipo Scrum representará a su equipo en el Scrum of Scrums (SoS)
MeeHng. En la mayoría de los casos es el Scrum Master, pero a veces alguien más puede
representar al equipo.

HERRAMIENTAS
q  REUNIÓN DE SCRUM OF SCRUMS
Estas son reuniones preferentemente cortas, donde los representantes de los equipos Scrum
se reúnen para comparHr el estado de los equipos respecHvos.

q  CUATRO PREGUNTAS POR EQUIPO
1) ¿En qué ha estado trabajando (ac?vidades) mi equipo desde la ulHma reunión?
2) ¿Qué va a hacer (ac?vidades) mi equipo hasta la próxima reunión?
3) ¿Qué esperaban otros equipos que mi equipo hiciera y que aún no se han hecho?
(Impedimentos)
4) ¿Qué planea hacer nuestro equipo que pudiera afectar a otros equipos?
Generalmente la reunión de Scrum de Scrums , se realiza en una sala de juntas, sin embargo si
los equipos no están en el mismo lugar, se puede realizar por medio de un video conferencia
SALIDAS

q  MEJOR COORDINACIÓN DEL EQUIPO
La reunión de Scrum of Scrums (SoS) facilita la coordinación de trabajo entre varios equipos
Scrum. Eso resulta de gran importancia cuando hay tareas que impliquen dependencias
entre equipos. Las incompaHbilidades y discrepancias entre el trabajo de los diferentes
equipos quedan expuestas rápidamente.

q  PROCESO 2: DEMOSTRACIÓN Y VALIDACIÓN DEL SPRINT
El Equipo Scrum demuestra el Sprint Deliverable al Producto Owner y a los Stakeholders
relevantes en un Reunión de Revisión del Sprint. El propósito de esta reunión es asegurar
la aprobación y aceptación del Producto Owner de los Entregables creados en el Sprint.

ENTRADAS
q  ENTREGABLES DEL SPRINT
q  CRITERIO DE ACEPTACIÓN DE LAS HISTORIAS DE USUARIO

HERRAMIENTAS
q  REUNIÓN DE REVISIÓN DEL SPRINT*
Los miembros del equipo principal Scrum y los socios relevantes parHcipan 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.
SALIDAS
q  ENTREGABLES ACEPTADOS
Los entregables que cumplen con los criterios de
aceptación de las historias de usuario son aceptados
por el propietario del producto. El objeHvo de un
Sprint es crear entregables potencialmente listos
para ser entregados o presentar incrementos de
productos que cumplan con los criterios de
aceptación definidos por el cliente y el propietario
del producto.

q  ENTREGAS RECHAZADAS
Si los entregables no cumplen con los criterios de
aceptación, tales entregables son rechazados. Estos
generalmente se llevan a cabo en un Sprint
posterior , para corregir cualquier problema.
Esto no es muy recomendable ya que el objeHvo de
cada Sprint es que los entregables cumplan con los
criterios aceptación.
q  PROCESO 3: RETROSPECTIVA DEL SPRINT
Tras la reunión de revisión de Sprint, el equipo Scrum se reúne para una reunión de
retrospecHva de Sprint. En esta reunión discuten lo que salió bien y mal durante el úlHmo
Sprint, buscando idenHficar posibles mejoras en el proceso. (Lecciones aprendidas).
Para poder implementarlos en el futuros Sprint , generalmente como consecuencia de esta
reunión pudieran resultar acciones de mejora Aceptadas o recomendaciones del cuerpo de
asesoramiento Scrum.

ENTRADAS
q  SCRUM MASTER
q  SALIDAS DE LA DEMOSTRACIÓN Y VALIDACIÓN DEL SPRINT

HERRAMIENTAS

q  REUNIÓN DE RETROSPECTIVA DEL SPRINT*
Es un elemento importante del marco de Scrum llamado "inspección-adaptación" y es el
paso final en un Sprint. Todos los miembros del equipo Scrum asisten a la reunión, que es
facilitada o moderada por el Scrum Master. Los debates en el Retrospect Sprint MeeHngs
abarcan tanto lo que salió́ mal como lo que salió́ bien. Los objeHvos principales de la reunión
son idenHficar tres elementos específicos:
1) Las cosas que el equipo necesita seguir haciendo: mejores prácHcas.
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 un lista de mejoras accionables aceptadas.
SALIDAS

q  MEJORAS ACCIONABLES ACEPTADAS
Es el primer resultado del proceso de retrospecHva del Sprint. Forma parte de la lista de
elementos accionable 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 futuro Sprints.

FASE DE LANZAMIENTO

La fase de lanzamiento hace énfasis en la entrega al cliente de los entregables
aceptados, así́ como en la idenHficación, documentación, e interiorización de las
lecciones aprendidas durante el proyecto.

PROCESOS RELACIONADOS CON EL LANZAMIENTO

q  Envió de los entregables
q  Retrospec?va del Proyecto.
FASE DE LANZAMIENTO
q  PROCESO 1: ENVIO DE LOS ENTREGABLES

Después de que el propietario del producto valida
los entregables (Sprint) de acuerdo con la definición
y los Criterios de Terminado, los Entregables
Aceptados están listos para la liberación de las
partes interesadas.

Sin embargo, no todos los Sprint acaban con un
lanzamiento. La decisión de cuándo liberar el
incremento del producto potencialmente
entregable a las partes interesadas se hace en el
proceso de la planificación del lanzamiento.

Los documentos de planificación del calendario de
lanzamiento conHenen los entregables que deben
ser liberados y en que fechas. Por lo tanto, los
principales insumos para el proceso del Envió de
entregables son los Entregables Aceptados y el
Cronograma de Planificación de lanzamiento.

FASE DE LANZAMIENTO
ENTRADAS
q  PROPIETARIO DEL PRODUCTO
q  SOCIOS PARTES INTERESADAS
q  ENTREGABLES ACEPTADOS
q  CRONOGRAMA DE PLANIFICACIÓN DEL LANZAMIENTO

q  PLAN PILOTO(PILOTING PLAN)

Un plan piloto es una entrada opcional que se puede uHlizar para trazar una
implementación piloto en detalle. El alcance y los objeHvos del despliegue, “target
deployment user base” (objeHvo base de usuarios de despliegue), un cronograma de
implementación, planes de transición, preparación de usuarios necesaria, los criterios de
evaluación para el despliegue y otros elementos claves relacionados con el despliegue se
especifican en el plan piloto y son comparHdos con los interesados o socios.

FASE DE LANZAMIENTO
HERRAMIENTAS

q  METODOS DE DESPLAZAMIENTO ORGANIZACIONAL
Los mecanismos de despliegue de cada organización Henden a ser diferentes en función
de su industria. Dependiendo del producto que se entrega, el despliegue puede tener
lugar de forma remota o puede implicar el envío osico o transición de un elemento.
Debido a que la implementación Hende a implicar un alto nivel de riesgo, las
organizaciones suelen tener mecanismos de implementación bien definidos y
establecidos, con procesos detallados para garanHzar el cumplimiento de todas las
normas aplicables y medidas del Aseguramiento de calidad.

q  PLAN DE COMUNICACIÓN
Este plan especifica los registros que deben ser creados y mantenidos durante todo el
proyecto. Una variedad de métodos se uHlizan para transmiHr información importante
del proyecto a los interesados o socios. El plan de comunicación define estos métodos, así́
como quien es el responsable de varias acHvidades de comunicación. como los
entregables se ponen a prueba, el estado de las acHvidades de prueba se comunica según
el plan.

FASE DE LANZAMIENTO
SALIDAS

q  ACUERDOS DE ENTREGABLES FUNCIONALES
(WORKING DELIVERABLES AGREEMENT)

Las entregas que cumplen con los criterios de
aceptación reciben un cierre de negocio formal y la
aprobación por parte del cliente o patrocinador.

El alcanzar una aceptación formal del cliente es
f u n d a m e n t a l p a r a e l r e c o n o c i m i e n t o . L a
responsabilidad para su obtención será́ definida por las
políHcas de la empresa y no es necesariamente la
responsabilidad del propietario del producto.

FASE DE LANZAMIENTO
PROCESO 2: RETROSPECTIVA DEL PROYECTO

La reunión retrospecHva del proyecto se lleva a cabo con el
objeHvo de idenHficar las mejores prácHcas, la mejora de
los procesos y recomendaciones para (Cuerpo de la Guía
Scrum)

Esto no sólo ayuda a mejorar la colaboración y la eficiencia
de los equipos, sino que también idenHfica mejoras en la
aplicación general de Scrum. Las sugerencias, opiniones y
conocimientos reunidos en la reunión del proyecto de
retrospecHva se graban para futuras consultas.

ENTRADAS
q  REUNIÓN DE RETROSPECTIVA DEL PROYECTO

FASE DE LANZAMIENTO
HERRAMIENTAS
q  REUNIÓN DE RETROSPECTIVA DEL PROYECTO
Es una reunión para determinar las formas en que la colaboración y la eficacia entre el
equipo puede mejorar en futuros proyectos. También se discuten aspectos posiHvos,
negaHvos y posibles oportunidades de mejora.

SALIDAS
Los principales resultados:

q  MEJORAS ACCIONABLES ACORDADAS
Los resultados primarios del proceso de retrospecHva del sprint. Forman parte de la lista de
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.
q  ELEMENTOS DE ACCIÓN ASIGNADOS Y FECHAS LIMITES

Una vez que se han elaborado y refinado los elementos de acción asignados y las fechas
limite, el equipo Scrum puede considerar los puntos de acción para implementar las
mejoras. Cada elemento de acción contará con una fecha limite de conclusión.

¿Qué es Scrum?
LINEA DE TIEMPO DE UN PROYECTO SCRUM
SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 . . . SPRINT X
Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint
Planning Review Planning Review Planning Review Planning Review Planning Review
& Retro & Retro & Retro & Retro & Retro
•  Un proyecto de Scrum consta de varios Sprints

•  Cada Sprint Hene la misma duración (Hme-boxed) para la duración del Proyecto
Scrum.
•  El Hempo se fija para cada Sprint, pero los cambios de alcance se basan en lo que
el equipo puede lograr durante ese período y el trabajo a realizar en base a la
lista priorizada del de producto.
¿Qué es Scrum?
LINEA DE TIEMPO DE UN PROYECTO SCRUM

SPRINT SPRINT SPRINT SPRINT SPRINT SPRINT SPRINT SPRINT SPRINT
1 2 3 4 5 6 7 8 9
Release 1 Release 2 Release 3
Estrategias de planificación de liberación:

•  Impulsado por Hempos
•  Impulsado por caracterísHcas
¿Qué es Scrum?
Ciclo de Sprint (Ejemplo de 2 semanas):
SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY
1 2 3 4 5 6 7
SPRINT 1 PLANNING Sprint Work Day 2 Sprint Work Day 3 Sprint Work Day 4 Sprint Work Day 5
MEETING: 4 HRS Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m
Sprint Work Day 1

Daily Standup 15m
8 9 10 11 12 13 14
Sprint Work Day 6 Sprint Work Day 7 SPRINT 1 REV 2HR
Sprint Work Day 8 Sprint Work Day 9
Daily Standup 15m Daily Standup 15m SPRINT RETRO 2HR
Daily Standup 15m Daily Standup 15m
15 16 17 18 19 20 21
SPRINT 2 PLANNING: Sprint Work Day 2 Sprint Work Day 3 Sprint Work Day 4 Sprint Work Day 5
4HRS Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m
Sprint Work Day 1

Daily Standup 15m
22 23 24 25 26 27 28
Sprint Work Day 6 SPRINT 2 REV 2HR
Sprint Work Day 7 Sprint Work Day 8 Sprint Work Day 9
Daily Standup 15m SPRINT RETRO 2HR
Daily Standup 15m Daily Standup 15m Daily Standup 15m
¿Qué es Scrum?
Ciclo de Sprint (Ejemplo de 2 semanas):
1 2 3 4 5 6 7
Sprint Work Day 1

Daily Standup 15m
8
Sprint Work Day 6
9 Sprint 1
10
Sprint Work Day 7
11
Sprint Work Day 8
12
Sprint Work Day 9
SPRINT 1 REV 2HR
13 14
Daily Standup 15m Daily Standup 15m SPRINT RETRO 2HR

Daily Standup 15m Daily Standup 15m
15 16 17 18 19 20 21
Sprint Work Day 1
SPRINT 2 PLANNING: Sprint Work Day 2 Sprint Work Day 3 Sprint Work Day 4 Sprint Work Day 5
Daily Standup 15m
4HRS Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m
22 23
Sprint Work Day 6
Sprint 2
24
Sprint Work Day 7
25
Sprint Work Day 8
26
Sprint Work Day 9
SPRINT 2 REV 2HR
27 28
Daily Standup 15m SPRINT RETRO 2HR

Daily Standup 15m Daily Standup 15m Daily Standup 15m
¿Qué es Scrum?
1 MES (4 SEMANAS) CICLO SPRINT - EJEMPLO
1 2 3 4 5 6 7

(Task Planning & Task

Es?ma?ng)
8 9 10 11 12 13 14
Sprint Work Day 5 Sprint Work Day 6 Sprint Work Day 7 Sprint Work Day 8 Sprint Work Day 9
Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m
15 16 17 18 19 20 21
Sprint Work Day 10 Sprint Work Day 11 Sprint Work Day 12 Sprint Work Day 13 Sprint Work Day 14
Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m
22 23 24 25 26 27 28
Sprint Work Day 15 Sprint Work Day 16 Sprint Work Day 17 SPRINT 1 REVIEW:
Sprint Work Day 18
Daily Standup 15m Daily Standup 15m Daily Standup 15m 4HRS
Daily Standup 15m
SPRINT 1
RETROSPECT: 4HRS
¿Qué es Scrum?
Tema: Website User Interface
EPICA HISTORIA DE USUARIO TAREA
Como comprador (Mary),

Crear nombre de
quiero registrar una cuenta Reúna información de
Como comprador, Crear página de registro usuario y contraseña
para poder proporcionar mi perfil de usuario
quiero comprar 3 Campos 2
información personal sin 1 obligatoria: Nombre,
2
ar…culos en línea volver a escribir correo electrónico, # ...
para no tener que ir Formulario para 3
nuevamente Crear formulario de inicio
a una Henda osica seleccionar las
de sesión de invitado
2 preferencias de correo Reúna información de
electrónico / perfil opcional:
Como comprador (Mary), noHficación ... género, dirección .. 3
quiero ingresar a mi cuenta Mostrar iconos para
PayPal, AMEX, MC, Visa
para poder ver mi 2 Opciones de recibos:
información personal Crear una tarjeta
Impresión, correo opcional de
Campo de descuentos electrónico, txt. 2 recompensas 2
para tarjetas de regalo y
códigos promocionales 1
Método de
autenHcación:
Captcha 2
SPRINT BACKLOG
PRIORITIZED PRODUCT BACKLOG
Crear página de Reúna Crear una
Crear nombre tarjeta opcional
inicio con el información de
de usuario y de
Como cliente, quiero acceder al sistema logoHpo de la perfil de
Priority: 1 contraseña recompensas 2
de comesHbles en línea de VMfoods para empresa, T & C, usuario
EsHmate: 13 Campos
que pueda ver información y servicios Contáctenos 3 1
obligatoria: Mostrar iconos
específicos para mí Nombre, correo para PayPal, 3
electrónico, AMEX, MC, Visa
Reúna 2
Crear
información de
formulario de Receipt
perfil opcional: Formulario para
Como comprador de comesHbles en línea, inicio de sesión opHons:
Priority: 2 género, seleccionar las
quiero tener múlHples opciones de EsHmate: 8 de invitado Print, email,
2 dirección .. 2 preferencias de
pasarela de pago para poder comprar txt. 2
correo electrónico /
productos comesHbles servicios
noHficación ... 3
Opciones de
recibos:
Impresión, Método de Campo de descuentos para
Como un comprador de comesHbles en
correo 2 autenHcación: 1 tarjetas de regalo y
2
línea, quiero poder navegar por la Henda Priority: 2 electrónico, txt. Captcha códigos promocionales 1
de comesHbles y agregar productos a un EsHmate: 32
carrito de la compra para que pueda
seleccionar ar…culos para comprar
Como comprador de comesHbles en línea,

Priority: 3
quiero tener múlHples opciones de EsHmate: 32
pasarela de pago para poder comprar
productos comesHbles servicios
Product Scrum
Owner Master Scrum Team
Como un comprador de comesHbles en
línea, quiero poder navegar por la Henda
de comesHbles y agregar productos a un Priority: 4 Lista priorizada de pendientes del producto
carrito de la compra para que pueda
EsHmate: 32 Una Lista de Producto suele contener caracterísHcas, funciones,
.
seleccionar ar…culos para comprar requerimientos, mejoras y correcciones que aún están “pendientes” para
. completar el sistema (o producto). Obviamente de ese listado saldrán las
. tareas que elegiremos en cada Sprint o Ciclo de nuestro proyecto Scrum.
. Cada items suele llamarse PBI (Product Backlog Item)
BLOQUE DE TIEMPO
•  Reuniones relacionadas con Scrum
Sprint (1 a 6
Semanas)
Reuniones de
retrospec?va del Sprint (4
Reuniones diarias de Horas por Sprint de un
Pie mes)
(15 Minutos) Duración de
las reuniones
con bloques
de ?empo
Reuniones de revisión del

Reuniones de planificación Sprint (4 Horas por Sprint
del Sprint (8 Horas por de un mes)
Sprint de un mes)
BURN DOWN CHART
Un "Burndown Chart" es una representación gráfica del trabajo a realizar en el ?empo

(Pendiente).
Las acHvidades que restan por hacer (Sprint Backlog) se encuentran en el eje verHcal y el
Hempo en el eje horizontal. A medida que el Hempo transcurre se irán percibiendo los
cambios en el trabajo por completar. Es muy úHl para predecir la fecha de culminación de un
Sprint al culminar todas las labores.

Lo ideal es que permita visualizar:

la fecha de inicio del Sprint
la fecha de culminación real del Sprint
la fecha de culminación esHmada del Sprint
total de puntos de historia esHmados
Hempo total del Sprint
BURN DOWN CHART
Burned Down Balance Daily
Date Planned Actual Planned Actual Completed
60 60
DIA 1 20 15 40 45 15
DIA 2 20 25 20 20 25
DIA 3 20 13 0 7 13
Historias DIA 1
Funcionalidad 1 4
Funcionalidad 2 3
Funcionalidad 3 4
Funcionalidad 4 4
15
Historias DIA 2
Funcionalidad 5 4
Funcionalidad 6 5
Funcionalidad 7 8
Funcionalidad 8 8
25
Historias DIA 3
Funcionalidad 9 3
Funcionalidad 10 3
Funcionalidad 11 3
Funcionalidad 12 4
13
BURN UP CHART
El gráfico Burn-up es muy similar al

Burn Up Chart . Pero con la diferencia
que se parte del cero, y se va
marcando la canHdad de trabajo
completado al final del Sprint, por

ello la curva va hacia arriba, no hacia
abajo.
En la figura de abajo, la línea verde es
el objeHvo y la gráfica va hacia arriba.
ESCALABILIDAD DE SCRUM
Para ser eficaz los Equipos Scrums deben tener
idealmente de seis a diez miembros. Esta prácHca
lleva a la idea errónea de que el marco de Scrum sólo
se puede uHlizar para proyectos pequeños. Sin
embargo, se puede escalar fácilmente para el uso
eficaz en grandes proyectos.

El proceso Scrum of Scrum facilita la coordinación
entre los Equipo Scrums lo que permite una aplicación
eficaz en los proyectos grandes. Los proyectos grandes
o complejos a menudo se implementan como parte de
un Programa o Portafolio.

Los proyectos grandes pueden tener múl?ples Equipo
Scrums trabajando de forma paralela por lo que es
necesario sincronizarse y facilitar el flujo de
información y mejorar la comunicación.

q  SCRUM EN PROGRAMAS Y PORTAFOLIOS.

ü  PROGRAMAS
Las funciones importantes para la gesHón de Programa en Scrum son:

1.  Producto Owner del Programa :Define los objeHvos y las prioridades estratégicas para el
Programa.
2.  Scrum Master del Programa :Resuelve problemas, remueve impedimentos, facilita, y lleva a
cabo reuniones para el Programa.

Estas funciones son similares a las del propietario del producto y Scrum Master excepto que
saHsfacen las necesidades de su Programa a o unidad de negocio en lugar de los de un sólo Equipo
Scrum.
ü  PORTAFOLIOS
Roles importantes para la gesHón del portafolio en Scrum son:
1.  Portafolio del propietario del Producto : Define los objeHvos estratégicos y las prioridades del
Portafolio.
2.  Portafolio del Scrum Master : Resuelve problemas, elimina Impedimentos, facilita, y lleva a
cabo reuniones para el Poraolio.
ESCALABILIDAD(I)
Ilustración cómo Scrum se puede u?lizar en toda la organización para los Portafolios,
Programas o Proyectos.
q  TRABAJAR CON PORTAFOLIO Y EQUIPOS DE PROGRAMA

Al aplicar Scrum para gesHonar proyectos en el marco de un Programa o un Portafolio se
recomienda que los principios generales de Scrum que se presentan en esta publicación se
cumplan. Se enHende sin embargo que con el fin de acomodar el Programa a en su totalidad
o acHvidades relacionadas con el Portafolio e interdependencias pueden ser necesarios
pequeños ajustes en el conjunto de herramientas, así como la estructura organizaHva.

q  LA GESTIÓN DE COMUNICACIÓN CON LOS EQUIPOS DE PORTAFOLIO Y PROGRAMAS

Los problemas y los cuesHones que se enfrentan al uHlizar Scrum dentro de un Programa o
Portafolio implican principalmente a la coordinación entre los numerosos equipos. Esto
puede conducir al fracaso si no se maneja con cuidado.

q  REUNIONES DE SCRUM OF SCRUMS (SOS)

Un Scrum of Scrums (SoS) MeeHng es un elemento importante al escalar o ajustar Scrum a
proyectos grandes. Por lo general, hay un representante en la reunión de cada uno de los
Equipo Scrums. Típicamente el representante es el Scrum Master, pero también es común
para cualquier persona del Equipo Scrum asisHr a la reunión si es necesario.

En organizaciones donde hay varios Equipo Scrums trabajando en varias partes de un proyecto
a la misma vez, SoS se puede escalar a otro nivel de lo que se conoce como Reunión Scrum de
Scrum de Scrums.

En esta situación, un SoS MeeHng manHene la coordinación de cada grupo de los Equipo
Scrums y luego una Reunión Scrum de Scrum de Scrums se puede llevar a cabo para
coordinar e integrar los proyectos a un nivel mayor. Los equipos Henen que evaluar
cuidadosamente los beneficios de contar con Scrum de Reunión de Scrum de Scrums, ya que la
tercera capa añade una can?dad significa?va de complejidad logís?ca.


En este ejemplo, hay seis Equipos Scrums que trabajan simultáneamente. Los Equipo Scrums
A, B y C están trabajando en las partes de un proyecto relacionado, mientras que los Equipo
Scrums D, E y F están trabajando en porciones de otro proyecto relacionado.
Una reunión de Scrum de Scrum se lleva a cabo para coordinar las interdependencias entre los
proyectos relacionados. Una reunión de Scrum de Scrum de Scrums se llevará a cabo para
coordinar y ges?onar las dependencias en todos los proyectos.

q  TRANSICIÓN HACIA SCRUM

Los dos métodos básicos para hacer la transición a Scrum son de arriba hacia abajo y de
abajo hacia arriba. En el método de arriba hacia abajo, la transición es ampliamente
comunicada. Se da un esfuerzo por proveer educación acerca del cambio a todos los
involucrados. Esta comunicación puede ser fuente de resistencia al cambio. La otra
posibilidad es cambiar las cosas gradualmente dentro de la cultura de la organización.
Después la transición a Scrum será de forma incremental.

Con una implementación de arriba hacia abajo, podría haber conflictos de comunicación. En
un escenario, el Jefe de ingeniería impuso Scrum en su organización sin la aceptación del
gerente de de producción o de ventas. Esto llevó a grandes conflictos con la función del
propietario del producto, así como su tareas tales , como la creación de la lista priorizada de
pendientes del producto.

q  TRANSICIÓN A SCRUM

Otro aspecto a considerar de la transición es qué tanto de la organización requiere una
transición a los métodos Scrum. La organización entera puede hacer la transición al mismo
Hempo. Sin embargo, este método es más suscep?ble a problemas que pueden resultar en
la interrupción de acHvidades que generan ganancias. Por lo tanto, es generalmente
preferible hacer la transición en diferentes secciones de forma iteraHva para reducir el riesgo
y proporcionar lecciones aprendidas para futuras iteraciones.
Mantener una reserva de elementos pendientes de Scrum, para ser introducidos y
priorizados.

¿Cuáles le proporcionar el mayor valor por su dinero?
¿Cuáles pueden ser fácilmente implantadas?
¿Puede usted tener equipos mulHdisciplinarios?
¿Puede usted tener incrementos para llegar a su lanzamiento?
¿Puede usted iniciar con uno o varios equipos co-ubicados?
En caso de hacer la integración conHnua, ¿Puede incrementar la frecuencia de sus
desarrollos?

q  MAPEO ROLES TRADICIONALES
En Scrum es muy importante para asegurar la exitosa implementación, las siguientes
funciones :
El propietario del Producto es la persona responsable de lograr el máximo valor empresarial
para el proyecto. Él/ella también es responsable de la arHculación de requisitos del Cliente y
de mantener el JusHficación de Negocio para el proyecto. El propietario del Producto
representa la voz del cliente (VOC).
El Scrum Master es un facilitador que asegura que el Equipo Scrum esté dotado de un
ambiente propicio para completar el proyecto con éxito. El Scrum Master guía, facilita y les
enseña las prácHcas de Scrum a todos los involucrados en el proyecto; elimina los
impedimentos que encuentra el equipo; y asegura que se estén siguiendo los procesos de
Scrum.
El Equipo Scrum es el grupo o equipo de Personajes o Personas responsables de la
comprensión de los requisitos especificados del propietario del Producto y de la creación de
los entregables del proyecto.

En algunas empresas el papel tradicional para asegurar la solides a los procesos no es parte
de la función del director del proyecto, pero si esta dentro de una organización de control
de calidad o departamento separado.

q  EL MANTENIMIENTO Y PARTICIPACIÓN DE LOS INTERESADOS

Scrum requiere el apoyo completo de los socios o interesados del proyectos. La
responsabilidad de mantener la parHcipación de los socios o interesados depende del
propietario del producto. Las siguientes son las acciones recomendadas para el
mantenimiento de la parHcipación y el apoyo de los socios.

Asegurar la Colaboración efecHva y la parHcipación de los socios en el proyecto.

•  Evaluar conHnuamente el impacto en el negocio
•  Mantener una comunicación regular con los socios
•  Administrar las expectaHvas de los socios

Un socios clave es el patrocinador : es el individuo que provee los fondos y otros recursos
para un proyecto. Los patrocinadores quieren entender los resultados financieros
relacionados con un producto o servicio, y están por lo general más preocupados por los
resultados finales, que con las tareas individuales.
q  IMPORTANCIA DEL SOPORTE EJECUTIVO

Los ejecuHvos son las personas que financian el proyecto. Por tanto, para que cualquier
proyecto de Scrum sea exitoso, los ejecuHvos deben apoyarlo.

Para conservar el apoyo ejecuHvo:
•  Comuníquese regularmente con los ejecuHvos.
•  Mantenga a los ejecuHvos informados de los úlHmos progresos.
•  Informe a los ejecuHvos de cualquier conflicto o retrasos potenciales en la entrega del
proyecto para minimizar el shock.

q  IMPORTANCIA DEL SOPORTE EJECUTIVO

Es importante que los ejecuHvos que financian el proyecto tengan claridad con respecto a los
siguientes asuntos:

ü  ¿CUÁL ES EL BENEFICIO DE IMPLEMENTAR EL MARCO DE TRABAJO SCRUM?
¿Cómo este cambio crea beneficios y / o previene pérdidas para la organización?
¿Cómo es que estar adaptado es esencial ,en un ambiente de negocios actual?
ü  ¿CUÁLES SON LOS PLAZOS LÍMITE Y COSTOS DE LA TRANSICIÓN?

¿Cuál es el Hempo las fechas limites y el costo de la transición? ( Los cálculos de
mejores casos/óp?mos/peores)
¿Cuáles son los posibles objeHvos al cumplir con el camino?
¿Con que frecuencia se van a reunir los ejecuHvos respecto al progreso del proyecto?

ü  ¿CUÁLES SON LOS RIESGOS QUE INVOLUCRA LA TRANSICIÓN?
¿Cuáles son obstáculos o riesgos potenciales en la implementación?
¿Cuál es el costo y Hempo adicional requerido para miHgar cada uno de estos riesgos?
¿DUDAS,PREGUNTAS,COMENTARIOS?

Curso Oficial SMC RM Certified

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Curso Oficial SMC RM Certified

Diunggah oleh

Hak Cipta:

Format Tersedia

Programa

Toda información contenida en este documento es considerada privilegiada

q Opción múl?ple de respuesta

ES NECESARIO TENER EN CUENTA LA ESTABILIDAD EN SUS PROCESOS DE ADAPTACIÓN.

q EL GRAN INTERES POR AGILE

SÓLO LAS METODOLOGÍAS QUE SE AJUSTAN AL MANIFIESTO ÁGIL SON GENERALMENTE

Esto quiere decir : Aunque valoramos los elementos de la

Aunque los procesos y las herramientas ayudan a terminar con éxito un

Aunque la documentación es necesaria para cualquier proyecto, muchos equipos se centran en

Anteriormente a los clientes se les ha visto como par?cipantes externos, involucrados

1. Kent Beck

La gesHón de proyectos Agile (Declaración de

Una serie de metodologías ágiles se originaron y ganaron fuerza en la década de 1990 y

A mediados de los 80, Hirotaka Takeuchi y Ikujiro Nonaka deﬁnieron

4. PRIORIZACIÓN BASADA EN VALORES

1. Crear la Visión del Proyecto

2. IdenHﬁcar al Scrum Master y a los interesados

3. Formación del Equipo Scrum

5. Crear la Lista de priorizada de Pendientes del Producto

6. Realizar la Planiﬁcación de lanzamiento

1. Crear Historias de Usuarios

2. Aprobar, EsHmar y asignación de las Historias de Usuario

4. EsHmar tareas

5. Crear la Lista de Pendientes del Sprint

1. Creación de Entregables

Implementación 2. Llevar acabo la reunión Diaria

3. Mantenimiento de la lista Priorizado de Pendientes del Producto

1. Convocar Scrum de Scrums

Revisión y RetrospecHva 2. Demostrar y Validar el Sprint

3. RetrospecHva del Sprint

1. Envío de Entregables

¿VENTAJAS DE UTILIZAR SCRUM?

• Ayuda a ﬁnalizar la elección del Scrum Master para el proyecto

• Ayuda a determinar los miembros del Equipo Scrum

• Ayuda a desarrollar un Plan de Colaboración

Desarrollo de Épica(s) • Crea Épica(s) y Personajes o Personas

• Crea el Cronograma de Planiﬁcación del Lanzamiento

Proceso Responsabilidades del Producto Owner

• Ayuda a Crear Historias de Usuarios

Aprueba, esHma y se compromete con Historias • Aprueba las Historias de Usuarios

• Le explica las Historias de Usuarios al Equipo Scrum, mientras crea

• Le proporciona orientación y aclaración al Equipo Scrum sobre la

• Le aclara los requisitos al Equipo Scrum mientras crea el Pendientes

Proceso Responsabilidades del Producto Owner

• Acepta / Rechaza los Entregables

• Proporciona retroalimentación necesaria para el Scrum Master y el

• Actualiza el Plan de Lanzamiento y el Priorizada Backlog Producto

• Ayuda con el lanzamiento de los Producto y coordina esto con el

RetrospecHva del Proyecto • ParHcipa en la reunión de RetrospecHva del Sprint

• Facilita la selección del equipo Scrum.

• Facilita la creación del Plan de Colaboración y el Plan para la Formación

• Asegura que los recursos de respaldo están disponibles. para el

Desarrollo de Épica(s) • Facilita la creación de la(s) Épica(s) y Personas.

• Ayuda al Producto Owner en la creación del Backlog Priorizado del

• Coordina la creación del Cronograma de Planiﬁcación. (Release Planning

• Determina la longitud del Sprint - “Semanas”. (Length of Sprint)

• Asiste al equipo Scrum en la creación de las Historias de Usuarios y sus

• Facilitador del equipo Scrum en la creación de la Lista de Tareas para el

• Asiste al Equipo Scrum en esHmar el esfuerzo necesario para completar las

Mantenimiento Priorizado de los

Proceso Responsabilidades del Scrum Master

• Facilita la presentación de los Entregables ya completados por el Equipo

• Representa al Equipo Principal de Scrum (Scrum Core Team) para

q  Opción múl?ple de respuesta

q  EL GRAN INTERES POR AGILE

1.  Kent Beck

1.  Crear la Visión del Proyecto

2.  IdenHﬁcar al Scrum Master y a los interesados

3.  Formación del Equipo Scrum

5.  Crear la Lista de priorizada de Pendientes del Producto

6.  Realizar la Planiﬁcación de lanzamiento

1.  Crear Historias de Usuarios

2.  Aprobar, EsHmar y asignación de las Historias de Usuario

4.  EsHmar tareas

5.  Crear la Lista de Pendientes del Sprint

1.  Creación de Entregables

Implementación 2.  Llevar acabo la reunión Diaria

3.  Mantenimiento de la lista Priorizado de Pendientes del Producto

1.  Convocar Scrum de Scrums

Revisión y RetrospecHva 2.  Demostrar y Validar el Sprint

3.  RetrospecHva del Sprint

1.  Envío de Entregables

•  Ayuda a ﬁnalizar la elección del Scrum Master para el proyecto

•  Ayuda a determinar los miembros del Equipo Scrum

•  Ayuda a desarrollar un Plan de Colaboración

Desarrollo de Épica(s) •  Crea Épica(s) y Personajes o Personas

•  Crea el Cronograma de Planiﬁcación del Lanzamiento

•  Ayuda a Crear Historias de Usuarios

Aprueba, esHma y se compromete con Historias •  Aprueba las Historias de Usuarios

•  Le explica las Historias de Usuarios al Equipo Scrum, mientras crea

•  Le proporciona orientación y aclaración al Equipo Scrum sobre la

•  Le aclara los requisitos al Equipo Scrum mientras crea el Pendientes

•  Acepta / Rechaza los Entregables

•  Proporciona retroalimentación necesaria para el Scrum Master y el

•  Actualiza el Plan de Lanzamiento y el Priorizada Backlog Producto

•  Ayuda con el lanzamiento de los Producto y coordina esto con el

RetrospecHva del Proyecto •  ParHcipa en la reunión de RetrospecHva del Sprint

•  Facilita la selección del equipo Scrum.

•  Facilita la creación del Plan de Colaboración y el Plan para la Formación

•  Asegura que los recursos de respaldo están disponibles. para el

Desarrollo de Épica(s) •  Facilita la creación de la(s) Épica(s) y Personas.

•  Ayuda al Producto Owner en la creación del Backlog Priorizado del

•  Coordina la creación del Cronograma de Planiﬁcación. (Release Planning

•  Determina la longitud del Sprint - “Semanas”. (Length of Sprint)

•  Asiste al equipo Scrum en la creación de las Historias de Usuarios y sus

•  Facilitador del equipo Scrum en la creación de la Lista de Tareas para el

•  Asiste al Equipo Scrum en esHmar el esfuerzo necesario para completar las

•  Facilita la presentación de los Entregables ya completados por el Equipo

•  Representa al Equipo Principal de Scrum (Scrum Core Team) para

Desarrollo de Épica(s) •  Asegura una comprensión clara de la(s) Épica(s) y de Personas

•  EnHenden las Historias de los en la lista priorizada de pendientes del

•  Están de acuerdo con los miembros del Equipo Principal de Scrum

•  EsHma los historias de usuarios aprobadas por el Product Owner

•  Desarrolla la lista de tareas basada en las historias de los usuarios ya

•  Actualiza el Burndown Chart, Scrumboard y el Impediment Log.

•  Proporciona entradas al Scrum Master para las reuniones de Scrum of

ü  Obje?vo de Orientación (Son muy enfocados en el resultado deseado. El Equipo Scrum

ü  Propiedad colec?va (El equipo en su conjunto es responsable de la entrega de los

q  ELEMENTOS DE ACCIÓN ASIGNADOS Y FECHAS LIMITES

•  Un proyecto de Scrum consta de varios Sprints

ü  ¿CUÁLES SON LOS PLAZOS LÍMITE Y COSTOS DE LA TRANSICIÓN?