Scrum trainer freddy vargas clase 3

Temario
4. Fases de Scrum
4.1. Inicio
4.2. Plan y estimación
4.3. Implementación
4.4. Revisión y retrospectiva
4.5. Lanzamiento
5. Escalando Scrum
5.1. Escalabilidad de Scrum
5.2. Scrum in programas y portfolios
5.3. Reuniones de Scrum de Scrums (SoS)
5.4. Transición a Scrum
5.5. Trazo de las funciones tradicionales de
Scrum
5.6. Mantener involucrados a los socios
5.7. Importancia del apoyo ejecutivo
1. Descripción de Agile
1.1. El surgimiento de Agile
1.2. El manifiesto de Agile
1.3. Principios del manifiesto de Agile
1.4. Declaración de interdependencia
1.5. Métodos de Agile
1.6. Agile vs. TM
2. Descripción de Scrum
2.1. Principios de Scrum
2.2. Aspectos de Scrum
2.3. Procesos de Scrum
2.4. Ventajas de Scrum
3. Scrum Roles
3.1. Funciones de Scrum
3.1.1. Propietario del producto
3.1.2. Scrum Master
3.1.3. Equipo de Scrum
3.2. Funciones no central

2. Descripción de Scrum
2.1. Principios de Scrum
2.2. Aspectos de Scrum
2.3. Procesos de Scrum
2.4. Ventajas de Scrum

Orígenes de Scrum
• Jeff Sutherland
• Scrums iniciales en Easel Corp en 1993
• IDX 500 personas haciendo Scrum
• Ken Schwaber
• ADM
• Se presenta Scrum en OOPSLA 96 con Sutherland
• Autor de tres libros sobre Scrum
• Mike Beedle
• Patrones Scrum en PLOPD4
• Ken Schwaber and Mike Cohn
• Fundaron conjuntamente la Scrum Alliance en 2002,
inicialmente dentro de la Agile Alliance

Introducción a SCRUM
• La palabra SCRUM procede del vocabulario del rugby y significa melé; es
decir, que los compañeros del equipo se amontonan, forman una piña y
empujan todos en la misma dirección.
• SCRUM es una estrategia de gestión donde se aplican de manera regular
un conjunto de prácticas para mejorar el trabajo colaborativo y obtener el
mejor resultado posible en la gestión de un proyecto software.

• Scrum es un proceso ágil que nos permite centrarnos
en ofrecer el más alto valor de negocio en el menor
tiempo.
• Nos permite rápidamente y en repetidas ocasiones
inspeccionar software real de trabajo (cada dos
semanas o un mes).
• El negocio fija las prioridades. Los equipos se auto-
organizan a fin de determinar la mejor manera de
entregar las funcionalidades de más alta prioridad.
• Cada dos semanas o un mes, cualquiera puede ver el
software real funcionando y decidir si liberarlo o seguir
mejorandolo en otro sprint.
Scrum en 100 palabras

SCRUM
Es un marco de trabajo
Existen una serie de
roles
Se marcan una serie de
eventos
Es un conjunto de
buenas prácticas para
desarrollar software de
una manera iterativa.

Scrum ha sido utilizado por:
•Microsoft
•Yahoo
•Google
•Electronic Arts
•High Moon
Studios
•Lockheed Martin
•Philips
•Siemens
•Nokia
•Capital One
•BBC
•Intuit
•Intuit
•Nielsen Media
•First American Real
Estate
•BMC Software
•Ipswitch
•John Deere
•Lexis Nexis
•Sabre
•Salesforce.com
•Time Warner
•Turner Broadcasting
•Oce

Scrum ha sido utilizado para:
• Software comercial
• Desarrollos internos
• Desarrollos bajo Contrato
• Proyectos Fixed-price
• Aplicaciones Financieras
• Aplicaciones certificadas
ISO 9001
• Sistemas Embebidos
• Sistemas con requisitos
7x24 y 99.999% de
disponibilidad
• Joint Strike Fighter
• Desarrollo de video juegos
• Sistemas críticos de soporte
vital, aprobados por laFDA
• Software de control satelital
• Sitios Web
• Software para Handheld
• Teléfonos portátiles
• Aplicaciones de Network
switching
• Aplicaciones de ISV
• Algunas de las más grandes
aplicaciones en uso

Características
• Equipos auto-organizados
• El producto avanza en una serie de “Sprints" de dos semanas a
un mes de duración
• Los requisitos son capturados como elementos de una lista de
“Product Backlog"
• No hay prácticas de ingeniería prescritas
• Utiliza normas generativas para crear un entorno ágil para la
entrega de proyectos
• Uno de los “procesos ágiles”

Principios de SCRUM
Ahora vamos a ver los 6 principios clave de
SCRUM
• 1. Control de Proceso Empírico
• 2. Auto-Organización
• 3. Colaboración
• 4. Priorización basada en valor
• 5. Tiempo Definido
• 6. Desarrollo iterativo

Control de Proceso Empírico
“CONTROL DE PROCESO EMPIRICO”
El cual esta basado en las ideas de
• · Transparencia
• · Inspección
• · Adaptación

Transparencia
Los aspectos significativos del proceso
deben ser visibles para aquellos que son
responsables del resultado.
La transparencia requiere que dichos
aspectos sean definidos por un estándar
común, de tal modo que los observadores
compartan un entendimiento común de lo
que se están viendo

Inspección
Los usuarios de Scrum deben
inspeccionar frecuentemente los
artefactos de Scrum y el progreso
hacia un objetivo para detectar
variaciones indeseadas.
Su inspección no debe ser tan
frecuente como para que interfiera en
el trabajo.
Las inspecciones son más
beneficiosas cuando se realizan de
forma diligente por inspectores
expertos en el mismo lugar de trabajo.

Adaptación
Uno de los tres pilares del
control del proceso empírico;
la retroalimentación se usa
para hacer un ajuste al
producto de trabajo que se
está desarrollando o al
proceso por el cual se está
desarrollando.

SPRINT
• El corazón de Scrum.
• Duración máxima de 1 mes.
• Es el contenedor de los demás
eventos.
• Consiste en: Sprint planning, Daily
meeting, Sprint review y Sprint
retrospective.
• La cancelación de un Sprint solo la
puede hacer el Product Owner.

SPRINT PLANNING
• Se define el trabajo a
realizar, debe participar
todo el equipo entero.
• Para un sprint de 1 mes, la
duración es de 8 horas.
• Se eligen las tareas del
product backlog
siguiendo las siguientes
normas:
• ¿Qué se va a hacer en
el sprint?
• ¿cómo lo vamos a hacer?
• El resultado es un sprint
backlog y un sprint goal.

DAILY MEETING
• Dura 15 minutos o menos.
• Debe participar si o si el equipo de desarrollo, el SM y
PO no tienen por qué estar.
• Se responden las siguientes 3 preguntas:
• ¿Qué hice ayer?
• ¿Qué voy a hacer hoy?
• ¿Tengo algún impedimento que necesito que me
solucionen?
• Oportunidad de inspección y adaptación.

SPRINT REVIEW
• Se hace al final de Sprint, es la única reunión en donde
participa el cliente.
• El PO presenta los cambios hechos en el Sprint, y el
equipo de desarrollo hace la demostración de lo
desarrollado.
• Dura 4 horas para un Sprint de 1 mes.
• El cliente da feedback que nos ayudará a adaptarnos y
a decidir con qué seguir.
• El resultado de este evento es un Product backlog
revisado para optimizar el trabajo del siguiente
Sprint.

SPRINT RETROSPECTIVE
• Se realiza luego del Sprint review
• Duración de 3 horas para un sprint de 1
mes.
• Es una oportunidad del equipo Scrum de
inspeccionarse a sí mismo.
• Se proponen mejoras
relacionadas al proceso
Scrum.
• Al final de la retrospectiva el
equipo tiene un listado de
mejoras que debe aplicar en el
siguiente Sprint.

PRODUCT BACKLOG
• Es un listado de tareas
ordenadas por importancia.
• El orden de las tareas es
responsabilidad exclusiva del
Product Owner.
• El PO está constantemente actualizandolo.
• El equipo de desarrollo escoge las
tareas del PB para crear el Sprint
Backlog
• El equipo de desarrollo estima las
tareas del PB.

• Es el listado de tareas del
Product Backlog que se
harán en cada Sprint. Se
crea en el Sprint
planning.
• Es propiedad
exclusiva del equipo
de desarrollo.
• El Sprint backlog no
cambia en medio del
sprint, solo se pueden
agregar nuevas tareas
por parte del equipo de
desarrollo.
SPRINT BACKLOG

DEFINITION OF DONE / READY
El marco de trabajo Scrum destaca los 3 elementos expuestos previamente como
imprescindibles. Sin embargo, hay otros que, a pesar de no formar parte del core, son
necesario para asegurar la calidad de la metodología Scrum.
Definition of Done (DoD): La DoD es un documento que define qué se considera hecho en
un equipo Scrum. La idea es establecer una serie de criterios comunes para especificar
cuando un ítem está completamente terminado y que aplique a todos los ítems que
forman parte del incremento.
Definition of Ready (DoR): El DoR es un documento que define cuándo un requerimiento
(historia de usuario o similar) se considera listo para que el equipo de desarrollo pueda
entenderlo, valorarlo e incluirlo en un Sprint Planning con idea de acometerlo en un Sprint.

• Es una representación gráfica del estado de trabajo que
resta por hacer dentro de unSprint.
• El eje X muestra el tiempo de desarrollo, el Y las tareas a
hacer.
• El equipo de desarrollo es el encargado de gestionarlo.
• No es obligatorio de usar, lo que es obligatorio es medir
cómo va un Sprint, siempre.
BURN-DOWN CHARTS

AUTO-ORGANIZACION
“AUTO-ORGANIZACION”
Scrum esta diseñado para empleados de hoy
Que tienen mucho mas que ofrecer que solo su
conocimiento técnico.
Y tu puedes entregar el mayor valor cuando se
organizan por ellos mismos.

COLABORACION
“COLABORACION”
• Que involucra que todos los INTERESADOS
trabajando e interactuando juntos para
entregar el mayor valor al cliente

PRIORIZACION BASADA EN VALOR
“PRIORIZACION BASADA EN VALOR”
• Los requerimientos y sus tareas respectivas
son priorizadas basadas en el valor que
representan para el cliente.
• De esta manera, los requerimientos mas
valiosos para el cliente se hacen primero,
conduciendo a incrementar el Retorno de la
Inversión.

TIEMPO DEFINIDO
“TIEMPO DEFINIDO”
• El tiempo es el factor mas crucial en proyectos
SCRUM y las juntas y periodos de trabajo
tienen tiempo definido.
• La junta “Daily Standup” es una junta de 15
minutos
• La duración de un SPRINT es limitada de
acuerdo a las necesidades del proyecto, y
puede variar entre 1 y 6 semanas.

DESARROLLO ITERATIVO
“DESARROLLO ITERATIVO”
• El cual permite correcciones hasta que la
gente involucrada tiene una mejor idea de
Qué requerimientos van a ser cubiertos como
parte del proyecto, e incorporan este
aprendizaje de una manera iterativa.

ENTONCES….
• Scrum es un proceso iterativo e incremental que puede ser utilizado
para desarrollar cualquier producto o administrar cualquier trabajo.
Sus principales atributos son:
– Un enfoque orientado a que los equipos desarrollen productos de
manera iterativa e incremental cuando los requerimientos cambian de
manera rápida
– Un proceso que controla el caos de conflictos de intereses y
necesidades
– Una manera de mejorar las comunicaciones y maximizar la
cooperación
– Una manera de maximizar la productividad
– Escalable a múltiples proyectos y la organización
– Una forma que todos se sientan bien con su trabajo,
entendiendo que cada uno con sus contribuciones
hizo lo mejor que podía hacer

En lugar de hacer todo
de una cosa a la vez ...
...los equipos Scrum
hacen un poco de todo
todo el tiempo
Requisitos Diseño Código Test
• Desarrollo secuencial vs. superpuesto

Aspectos de SCRUM
Ahora, vamos a ver los Aspectos de SCRUM
• 1. Organización
• 2. Justificación de Negocio
• 3. Calidad
• 4. Cambio
• 5. Riesgo

ORGANIZACIÓN
Los roles de SCRUM vienen en 2 categorías:
Roles Principales y Roles no Principales
• Los roles principales incluyen:
• · Product Owner,
• · Scrum master, y
• · Scrum team
Juntos hacen el Scrum CORE team

Los roles no principales incluyen
• · Interesados o Stakeholders
• · “Scrum Guidance Body”
• · “Vendors” o Proveedores

• ROLES CENTRALES
• ROLES NO CENTRALES
Los roles de Scrum se dividen en dos
grandes categorías:

Los roles centrales son
aquellos que
obligatoriamente se
requieren para crear el
producto del proyecto, están
comprometidos con el
proyecto, y por último son
los responsables del éxito de
cada sprint del proyecto y del
proyecto en su totalidad
ROLES CENTRALES

ROLESCENTRALES
Haytrespapelesprincipalesen Scrum

-
Representa los grupos de interés y es
responsable de asegurar que el equipo
scrum ofrecezca 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 gestiona la Prioridad del
Product Backlog.
LaVozdelCliente.
DUEÑO DEL PRODUCTO
(PRODUCT OWNER)

Product Owner
- Representa al cliente
- Tiene la visión de negocio
- Reune el feedback de los usuarios
- Define las nuevas funcionalidades
- Toma las decisiones de producto

.
Representa la voz del cliente
Es responsable de logar el máximo valor de negocio del Proyecto
Es el responsable de decidir sobre los criterios de aceptación para diversas tareas
Proporciona financiación para el proyecto y supervisa el proyecto para
confirmar la realización de beneficios
Define la lista de prioridades de las necesidades
Responsable de preparar la prioritized product backlog para reflejar las
necesidades cambiantes de los clientes
Es el responsable de crear historias de los usuarios en el proceso desarrollar
historias de usuarios
Es responsable de la preparación de la píla de producto priorizada
Es responsable de priorizar los riesgos
Es responsable de mantener involucrados a los socios
Responsabilidades del Propietario
del producto

SCRUM MASTER
• 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.

Scrum master
- Lidera al equipo usando SCRUM
- Gestiona los impedimentos
- Sirve de escudo al equipo
- No es el jefe
- Es un facilitador

Es responsable de proporcionar al equipo Scrum con un entorno
favorable para la creación de entregables
Es responsable de crear una conciencia de las prácticas de Scrum
entre los miembros del equipo Scrum
Es responsable de resolver los conflictos entre los miembros del
equipo Scrum
Es responsable de asegurar que los requisitos y las historias de los
usuarios perteneciente a un sprint acordado no se cambien
Es responsable de asegurar que las reuniones diarias de
Standup/pié se ejecuten de manera oportuna y estructurada
Responsabilidades del SCRUM
MASTER

El Equipo Scrum es un grupo de personas que son responsables de
la comprensión de los requerimientos del negocio especiﬁcados
por el propietario del producto.
EQUIPO SCRUM
(Scrum Team)

Team
- Tienen un perfil técnico
- Comprometidos con el producto
- Capacidades para entregar en plazo
- Se autogestionan en el día a día

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-
motivados, se enfocan en el cliente y tienen un alto sentido 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.
SCRUM TEAM

-Auto-organizado
-Multi-funcional
- Caraa caradelacomunicación
- Laentrega del productoiterativo
CARACTERÍSTICAS DELEQUIPO
SCRUM

Estima las historias de usuarios
En ocasiones al equipo Scrum también se le denomina equipos de
desarrollo
En Scrum es preferible tener a los equipos coubicados
Tiene la autoridad y responsabilidad de determinar las mejores
formas para convertir los elementos de la lista priorizada de
pendientes del producto en entregables completados
Responsabilidades del
SCRUM TEAM

Los roles no esenciales son aquellos papeles que no son
obligatoriamente necesarios para el proyecto Scrum y pueden no
estar involucrados en el proceso de Scrum.
Los Non-core roles pueden incluir lo siguientes:
1. STAKEHOLDER(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.
o Clientes
o Usuarios
o Patrocinador
ROLES NO ESENCIALES

2. VENDEDORES
Losvendedores incluyen aindividuos u organizaciones externas que ofrecen productos y
servicios que no están dentro de lascompetencias básicasde la organización delproyecto.
3. SCRUMGUIDANCEBODY
ElScrumGuidanceBody(SGB)esuna función opcional. Porlo general, secompone de un
grupo de documentos y/o un grupo de expertos que normalmente están involucrados en
la deﬁnición de los objetivos relacionados con
gubernamentales, la seguridad y otros parámetros
la calidad, las regulaciones
clave de la organización. Estos
objetivos guían la labor llevada acabo por el Product Owner, ScrumMaster y ScrumTeam.

ENTREGA BASADA ENVALOR
Un proyecto es un NEGOCIO COLABORATIVO para cualquiera que desee
crear nuevos productos o servicios, o para obtener resultados según han
sido deﬁnidos en el Project Vision Statement (Declaración de la Visión del
Proyecto). Los proyectos son por lo general afectados por limitaciones de
Tiempo, costo, alcance, calidad, recursos y la capacidad de la
organización.
Por lo general se busca que los resultados generados por los proyectos
resulten en algún tipo de valor de negocio o servicio.
Dado a que el valor es una razón principal de cualquier organización para
seguir adelante con un proyecto, la entrega basada en valor (Value-Driven
Delivery) debe ser el foco principal. El ofrecer valor es algo que está
arraigado en el marco de Scrum.

Con el ﬁn de aportar Value-driven Delivery (Entrega basada en valor), es importante:
- Entender lo que le agrega valor a los clientes y a los usuarios, y dar
prioridad a las necesidades de alto valor del Prioritized Product Backlog.
- Disminuir la incertidumbre y encargarse de los riesgos que potencialmente puedan
disminuir el valor en caso se materialicen. Es importante trabajar en estrecha
colaboración con el Stakeholder del proyecto y mostrar incrementos de productos.
- Crear entregables basados en las prioridades previamente deﬁnidas en la
producción incrementos durante cada Sprint. De esta forma, los clientes
empiezan a darse cuenta del valor desde el principio del proyecto.
- El concepto de entrega basada en valor hace que el marco de Scrum sea muy
atractivo para los Stakeholders y la alta dirección de las empresas.

RESPONSABILIDAD DELOSOTROS
ROLES
Es importante señalar que si bien el Product Owner es el
principal responsable de la Justiﬁcación del Negocio, otras
personas que trabajan en el proyecto Scrum también
contribuyen de manera signiﬁcativa de la siguiente manera:
- El patrocinador
- Los clientes y usuarios -
- En la Guía de Scrum Body
- El Scrum Master
- El Scrum Team

SCRUM:CALIDAD
En Scrum, la calidad se deﬁne como la capacidad del producto o productos
completados que cumplen los Criterios de Aceptación y alcanzan el valor de
negocio que espera el cliente.
Para asegurar que un proyecto cumpla con los requisitos de calidad, Scrum
adopta un enfoque de Mejora Continua donde el equipo aprende de sus
experiencias y del compromiso de los stakeholders.
Esto ayuda a mantener al día el Prioritized Product Backlog con los cambios
en los requisitos. El Prioritized Product Backlog no está completo hasta el
cierre o la terminación del proyecto.
Loserrores odefectossedetectandurantelaspruebasdecalidad
respectivasynocuandoel productoﬁnal
oservicio estácasiterminado

Los requisitos de calidad para un proyecto se determinan tomando varios
factores como son:
- La necesidad del negocio que el proyecto cumplirá.
- La capacidad y la buena disposición de la organización para cumplir
con las necesidades del negocio.
- Las necesidades futuras y actuales de la audiencia.
- El alcance de un proyecto es la suma total de todos los incrementos
del producto y el trabajo necesario para desarrollar el producto
ﬁnal.
- Calidad, es la capacidad de las entregas para cumplir con los requisitos
de calidad del producto y saCsfacer las necesidades del cliente .

GESTION DE CALIDAD EN SCRUM
El CLIENTE es el socio más importante para cualquier proyecto, por lo
tanto es importante entender las necesidades y requerimientos de los
clientes.
Generalmente, en un entorno de Scrum, el Product Owner se centra en
requerimientos y objetivos del negocio, que en conjunto representan la
voz del cliente.).
Control de Calidad en Scrum le permite a los clientes tomar conciencia de
los problemas en el proyecto desde el principio y les ayuda a reconocer si
un proyecto les va a funcionar o no. En Scrum, la Gestión de calidad se
facilita a través de tres actividades interrelacionadas:
• Planiﬁcación de la calidad
• Control de calidad
• Garantía de calidad

CAMBIO
Un principio fundamental de Scrum es el
reconocimiento de los stakeholders (por ejemplo,
clientes , usuarios y patrocinadores) cambian de
opinión acerca de lo que quieren y necesitan en todo
el proyecto que es muy difícil, si no imposible, para
los stakeholders deﬁnir todos los requisitos durante la
iniciación del proyecto. La práctica de Scrum se basa en
la aceptación del cambio y de convertirlo en una
ventaja competitiva.

La solicitud de cambio se presenta por lo general
como Change Requests. Los Change Requests no
son aprobados hasta que se obtiene una
aprobación formal. se recomienda que los
pequeños cambios que no tienen un impacto
signiﬁcativo en el proyecto sean aprobados
directamente por el Product Owner.
SOLICITUDES DE CAMBIO
APROBADAS Y NO APROBADAS

EQUILIBRIO FLEXIBILIDAD Y
ESTABILIDAD
Scrum ayuda a las organizaciones a ser más flexibles y abiertas al cambio. Sin
embargo, es importante entender que aunque el marco de Scrum hace
hincapié́ en la flexibilidad, también es importante tener estabilidad durante
todo el proceso de cambio. De la misma manera que la rigidez extrema es
ineficaz, la flexibilidad extrema también es improductiva. La clave es
encontrar el equilibrio adecuado entre la flexibilidad y la estabilidad ya que
se necesita la estabilidad con el fin de realizar el trabajo.
Por lo tanto, Scrum utiliza desarrollo iterativo y sus otras características y
principios para lograr este equilibrio. Scrum mantiene la flexibilidad de que
las solicitudes de cambio pueden ser creados y aprobados en cualquier
momento durante el proyecto; Sin embargo, consiguen prioridad cuando se
crea o se actualiza el Product Backlog.

Si hay una solicitud de cambio que puede tener un impacto
significativo sobre un Sprint en progreso, el Product Owner,
después de consultar con los StakeHolders decide si se puede
esperar hasta el próximo Sprint o si representa una situación
urgente que puede requerir finalizar el Sprint actual y comenzar
uno nuevo.
El marco de Scrum especifica claramente que el alcance de un
Sprint no se puede cambiar una vez que comienza el Sprint. Si
el cambio requerido es tan importante que los resultados del
Sprint no tendrían ningún valor sin él, entonces el Sprint debe
ser terminado.

QUÉ SON LOS RIESGOS?
Riesgo se deﬁne como un evento incierto, que puede afectar los
objetivos de un proyecto y puede contribuir a su éxito o fracaso.
El Riesgo con un impacto positivo en el proyecto se denomina
oportunidad, mientras que las amenazas son riegos que podrían
afectar negativamente .
La gestión del riesgo debe hacerse con pro-actividad y es un
proceso iterativo que debería comenzar al inicio del proyecto y
continuar durante todo el proyecto. El proceso de gestión del
riesgo debe seguir algunos pasos estandarizados para asegurar
que los riesgos son identiﬁcados, evaluados y un curso de acción
está determinado y para actuar en consecuencia.

DIFERENCIAENTRERIESGOSYPROBLEMAS
LOS RIESGOS: Son las incertidumbres relacionadas con un proyecto que podría
alterar signiﬁcativamente el resultado del proyecto de una manera positiva o
negativa. Dado a que los riesgos son las incertidumbres (futuro), no tienen ningún
impacto actual en el proyecto, pero podrían tener un impacto potencial.
Ejemplo:
Incluso después de un amplio entrenamiento, es posible que los representantes del
servicio al Cliente no estén listos para tomar pedidos el día oﬁcial del lanzamiento.
LOS PROBLEMAS: Son generalmente certezas que se están produciendo en el
proyecto, por lo que no hay necesidad de realizar una evaluación de la
probabilidad como lo haríamos para un riesgo. Los problemas deben atenderse.
Ejemplo:
Los requisitos no son claros.

PROCEDIMIENTO DEGESTIÓNDERIESGOS
(RISKS)
La gestión de riesgos se compone de cinco pasos:
1. Riesgo Identificación: El uso de diversas técnicas para identificar
todos los riesgos potenciales.
2. Riesgo Evaluación: La evaluación y la estimación de los riesgos
identificados.
3. Riesgo Priorización: La priorización del riesgo a ser incluido en el
Prioritized Product Backlog.
4. Riesgo Mitigación: Desarrollo de una estrategia adecuada para hacer
frente al riesgo.
5. Riesgo Comunicación: La comunicación de los resultados de los
primeros cuatro pasos.

Fase Procesos Roles
1. INICIO
1. Crear la Vision del
Proyecto
PO
2. Identificar al Scrum
Master y a los interesados
PO , SM
3. Formar el Equipo Scrum PO , SM , ES
4. Desarrollo de
Epicas/Personas
PO , SM , ES
5. Crear la Lista Priorizada
de Pendientes del Producto
PO , SM , ES
6. Realizar la Planificacion
del Lanzamiento
PO , SM , ES
•PO = Product Owner
•SM = Scrum Master
•ES = Equipo Scrum

I. Iniciación (6 procesos)
En esta fase se crea la Visión del Proyecto que sirve de enfoque y dirección
del mismo. Se crean e identifican roles claves del proyecto como el Scrum
Master, Product Owner, interesados, equipo del proyecto. Así mismo, se
define la lista de prioridades o el Product Backlog la cual sirve de base para la
elaboración del plan de lanzamiento y tamaño de cada Sprint.
Procesos
• Crear la visión del proyecto (Create Project Vision)
• Identificar al Scrum Master y a los interesados o socios del
proyecto (Identify Scrum Master and Stakeholder(s))
• Formación del equipo Scrum (Form Equipo Scrum)
• Desarrollo de épica(s) (Develop Epic(s))
• Creación de la lista priorizada de pendientes del producto (Create
Prioritized Product Backlog)
• Realizar el plan de lanzamiento (Conduct Release Planning)

Procesos
SCRUMIniciar
• Crear la visión del
proyecto
• Identificar al Scrum
Master y al socio
• Formación de un equipo
Scrum
• Desarrollo de épicas
• Creación de la lista
priorizada de
pendientes del producto
• Realizar el pan de
lanzamiento
Planear y Estimar
Historias de
estimar y
historias de
• Elaborar
Usuario
• Aprobar,
asignar
usuario
• Elaboración de tareas
• Estimar tareas
• Elaboración de la lista
de pendientes del Sprint
Implementar
• Crear entregables
• Llevar a cabo el Standup
diario
• Mantenimiento de la
lista priorizada de
Revisión y Retrospectiva
• Convocar Scrum de Scrums
• Demostración y validación
del Sprint
• Retrospectiva de Sprint
Lanzamiento
• Envío de Entregables
• Retrospectiva del Proyecto

Proceso: 1. Crear la Visión del Proyecto
Entradas Caso de Negocio del Proyecto (*)
• Documento bien estructurado o simplemente una declaración
verbal que expresa la razón para iniciar un proyecto.
• Puede ser formal y detallado, o informal y breve.
• Incluye información sobre: antecedentes del proyecto, objetivos
del negocio y resultados deseados, lista de riesgos identificados,
y estimaciones de tiempo, esfuerzo y costo.
• El Proyecto se inicia con la presentación del Caso de Negocio del
Proyecto.

Entradas
Visión de la Compañía
• Ayuda a que el proyecto mantenga su enfoque en los objetivos de la organización
y el futuro probable de la empresa.
• El Propietario del Producto se puede guiar por el Visión de la Compañía para crear
la Declaración de la Visión del Proyecto.
Entradas
Misión de la Compañía
• Ofrece un marco para la formulación de las estrategias de la empresa y orienta la
toma de decisiones en general de la empresa.
Entradas

Estudio de Mercado
• Investigación organizada, la recopilación , la comparación y el análisis de
datos relacionados con las preferencias de los clientes sobre los productos.
• Incluye numerosos datos sobre las tendencias del mercado, la segmentación
del mercado y los procesos de comercialización.
Entradas
Entradas Recomendaciones del Cuerpo de Asesoramiento de
SCRUM
• Grupo de documentos y/o grupo de expertos que están involucrados en la
definición de objetivos relacionados con la calidad, las regulaciones
gubernamentales, la seguridad y otros parámetros claves de la organización.
• NO toma decisiones relacionadas al proyecto.
• Es importante asegurarse de que la visión del proyecto esté alineada con las
recomendaciones proporcionadas por el Cuerpo de Asesoramiento de Scrum y
que los procesos cumplan con las normas y directrices establecidas por el
SBOK (la Administración)

Reunión de la Visión del Proyecto
• Reunión con los Interesados del Programa, Propietario de Producto del Programa,
Scrum Master del Programa, y Jefe Propietario de Producto.
• Ayuda a identificar el contexto empresarial, requerimientos del negocio y las
expectativas de los socios con el fin de desarrollar una Declaración de la Visión del
Proyecto.
• Scrum cree en la participación y colaboración cercana con todos los representantes de
las empresas para obtener su buy-in (convencimiento de su importancia) del proyecto
y para ofrecer un valor más significativo.
Herramientas

Análisis FODA
• Enfoque estructurado para la planificación que ayuda a evaluar las Fortalezas,
Oportunidades, Debilidades y Amenazas relacionados al proyecto.
• La realización del FODA permite la identificación precoz de las prioridades, los
cambios potenciales y los riesgos.
Herramientas

Análisis de Brechas
• Técnica que se utiliza para comparar el estado actual con el estado deseado.
• Normalmente, se inicia un proyecto para que una organización alcance una situación
deseada, por lo que llevar a cabo un Análisis de Brechas ayudaría a quienes toman
decisiones a determinar la necesidad del proyecto.
Herramientas

Identificación del Propietario del Producto (*)
• El Propietario del Producto es la persona responsable de lograr el valor máximo
empresarial para el proyecto.
• Representa la voz del Cliente.
• Cada Equipo Scrum tendrá un Propietario de Producto designado. Un pequeño
proyecto puede tener sólo un Propietario de Producto, mientras que los proyectos
más grandes pueden tener varios.
Salidas
Enunciado de la Visión del Proyecto (*)
• Una buena visión del proyecto explica la necesidad del negocio, y que es lo que el
proyecto tiene como objetivo satisfacer, en lugar de cómo se va a satisfacer la
necesidad.
• No deberías ser muy específico y debe ser flexible, ya que es posible que esté
basado en suposiciones.
• Debe centrase en el problema y no la solución.
Salidas

Fase: Iniciar
Proceso: 2. Identificar al Scrum Master y al Socio(s)

Acta de Constitución del Proyecto
• Es una declaración formal de los objetivos y resultados deseados del proyecto.
• En varias organizaciones, el Acta de Constitución del Proyecto es el documento oficial
y formal que autoriza el proyecto, dándole al equipo la autoridad por escrito para
comenzar el proyecto.
Salidas
Presupuesto del Proyecto
• Documento financiero que incluye el costo de las personas, materiales y otros gastos
relacionados en un proyecto.
• Típicamente es firmado por los Patrocinadores para asegurar que haya suficientes
fondos disponibles.
Salidas

Entradas Disponibilidad y compromiso de las personas
• Antes de seleccionar al Scrum Master y a los Interesados, se debe confirmar su
disponibilidad.
• Sólo los miembros que estarán disponibles y que puedan comprometerse
plenamente con el proyecto deben ser seleccionados.
Entradas Matriz de Recursos Organizacionales
• Es una representación jerárquica de una combinación de una estructura de
organización funcional y una estructura organizativa proyectizada.
• Las organizaciones matriciales reúnen a miembros de varios equipos del proyecto de
diferentes departamentos funcionales.
• Los miembros del equipo en una organización matricial cumplen dos objetivos:
funcionales y de proyecto.
Entradas Matriz de Requerimientos de Habilidades
• Conocido como marco de competencias.
• Se utiliza para evaluar las carencias de habilidades y los requisitos de
formación para los miembros del equipo.

Entradas Jefe Scrum Master
• Los grandes proyectos requieren que múltiples Scrum Masters trabajen en paralelo.
• Es posible que la información obtenida por un equipo se le deba comunicar
adecuadamente a los otros equipos. Es el Jefe Scrum Master el responsable de esta
actividad.
• La coordinación entre distintos Equipos Scrum que colaboran en un proyecto se
realiza a través de la Reunión Scrum de Scrums (SoS). Esto es análogo al Daily
Standup Meeting y es facilitado por el Jefe Scrum Master.
Entradas Requisitos de Personal
• Es importante documentar las funciones y responsabilidades de todos los que se
verían involucrados en la realización de las tareas del proyecto.
• El Propietario del Producto o el Scrum Master colaboran con el Departamento de
Gestión Humana de la empresa para determinar y concluir los requerimientos del
personal.

Costos de Formación y capacitación
• El Propietario de Producto debería evaluar las necesidades de capacitación de los
miembros potenciales del equipo y facilitar la formación para eliminar lacarencia.
• El Propietario del Producto es normalmente responsable de la evaluación y la
selección de los miembros del equipo, pero a menudo lo hace en consulta con el
Scrum Master.
• Una formación adecuada se le debe proporcionar a los miembros del Equipo Scrum,
tanto antes del inicio de los trabajos ya también mientras están trabajando en sus
proyectos. Los miembros del Equipo Scrum deben estar dispuestos a aprender de los
demás y de quienes tienen más experiencia en el equipo.
Herramientas
Costos de los Recursos
• Una de las principales consideraciones en la selección de las personas tiene que
ver con las ventajas y desventajas relacionadas con el nivel de experiencia en
comparación al salario.
Herramientas

Criterios de Selección (*)
• Cuando hay flexibilidad en la elección del Scrum Master, se deben considerar los
siguientes criterios de selección:
 Habilidades para la resolución de problemas.
 Disponibilidad
 Compromiso
 Estilo de Liderazgo Servant
• En la identificación de los Interesados, es importante recordar que se incluye a
todos los clientes, los usuarios y patrocinadores, quienes influyen en el proyecto a lo
largo de su ciclo de vida.
Herramientas
Asesoramiento de Expertos de Recursos Humanos
• Puede ser útil en al identificación del Scrum Master y de los Interesados.
• El Departamento de Recursos Humanos posee un conocimiento específico sobre
los empleados de una organización y las diversas técnicas que pueden ayudar a
identificar.
Herramientas

Identificación del Scrum Master (*)
• El Scrum Master es un facilitador y Servant Leader que se asegura de que el Equipo
Scrum esté dotado de un ambiente propicio para completar el proyecto con éxito.
• Es la responsabilidad del Propietario de Producto identificar al Scrum Master para un
proyecto Scrum.
Salidas
Identificación de StakeHolders ( Interesados)
• Interesados es un término colectivo que incluye a los clientes, los usuarios y los
patrocinadores, con frecuencia interactúan con el Equipo Scrum Principal en el
proyecto durante todo el proceso de desarrollo del producto.
• Es para los socios que el proyecto produce los beneficios deseados de colaboración.
Salidas

Fase: Iniciar
Proceso: 3. Formación de un Equipo Scrum

Entradas Requisitos de Recursos
• Estos requisitos incluyen todos los recursos, sean personas o no, necesarios para
que el Equipo Scrum funcione con eficacia.
• Estos recursos incluyen infraestructura de oficinas, espacios de reunión, los equipos
de trabajo, Scrumboards, etc.
• En caso de equipos virtuales, recursos adicionales, tales como herramientas de
Colaboración, videoconferencia, repositorios de documentos compartidos, servicios
de traducción, etc.

Selección del Equipo Scrum
• El Equipo Scrum es la base de cualquier proyecto de Scrum y el tener a los
• miembros adecuados para el equipo es vital pára 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.
• Los miembros ideales del Equipo Scrum son independientes, auto-motivados, se enfocan en el
cliente, y tiene un sentido de la responsabilidad y lacolaboración.
Herramientas
Asesoramiento de Expertos de Recursos Humanos
• Puede ser útil para la formación del Equipo Scrum.
• El Departamento de Recursos Humanos posee un conocimiento específico sobre
los empleados de una organización y las diversas técnicas que pueden ayudar al
Propietario del Producto, Scrum Master y a los patrocinadores para identificar a
los mejores miembros del equipo.
Herramientas

Costo asociado con el personal
• Todos los costos asociados con los requisitos de las personas deben ser evaluados,
analizados, aprobados y presupuestados.Herramientas
Costos de los Recursos
• Los costos asociados con todos los requisitos no relacionados con las
personas deben ser evaluados, analizados, aprobados y presupuestados.
• Un recurso en el entorno del proyecto es identificado como aquello que se
usa para realizar una trae o actividad, incluyendo pero no limitado a
equipos, materiales, servicios externos y el entorno físico.
Herramientas

Identificación del Equipo Scrum
• También conocido como Development Team, 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 estimación de Historias de Usuario y la creación
definitiva de los entregables del proyecto.
Salidas
Personal de Reemplazo /Sustitutos
• Aunque la disponibilidad y compromiso por los miembros del equipo se confirman
por adelantado, pueden surgir problemas, tales como una enfermedad, emergencia
familiar, o simplemente el hecho de renuncia de un miembro.
• El tener reemplazantes asegura que no haya una disminución importante en la
productividad debido a la falta de un miembro del equipo.
Salidas

Fase: Iniciar
Proceso: 4. Desarrollo de Épicas

Entradas Leyes y regulaciones
• Las leyes son externas a la organización e impuesta por una entidad
gubernamental.
• Las regulaciones pueden ser o bien interna o externa. Las regulaciones internas son
aquellas que son aplicables dentro de la empresa, por lo general basadas en la
política de la empresa. Las regulaciones externas son las relativas a los criterios, las
normas y requisitos gubernamentales establecidos.
• A veces, algunas de las leyes y reglamentos que afectan a múltiples proyectos
Scrum pueden incluirse como parte del Cuerpo de Asesoramiento de Scrum.
Entradas Información previa del proyecto
• Información y conocimientos adquiridos en proyectos anteriores y
similares dentro de la organización son insumos valiosos para el
desarrollo de Épicas y de la evaluación de riesgos.

Entradas Solicitudes de Cambio Aprobados
• Solicitudes de Cambio Aprobadas que vienen del programa o portafolio son entradas
que se añadirán a la lista de cambios del proyecto aprobados para su ejecución en
sprints futuros.
• Cada cambio puede requerir su propia Épica o Historia de Usuario.
• También podría ser resultado de otros procesos de Scrum.
Entradas Solicitudes de Cambio No Aprobados
• Los pedidos de cambios se presentan por lo general como Solicitudes de Cambio y
permanecer en un estado de “no aprobado” hasta que sean formalmente aprobados.
Entradas Riesgos del Programa y Portafolio
• Riesgos relacionados con un portafolio o programa también tendrán un
impacto en los proyectos que forman parte del respectivo portafolio o
programa.
• Durante evaluación de riesgos de portafolio o programa, si se determina
que el riesgo puede afectar a un proyecto individual, la información
relevante debe ser comunicada al Propietario de Producto y equipo
Scrum.

Taller de Historias de Usuario
• El Scrum Master facilita estas sesiones en las que todo el Equipo Scrum Principal
interviene, y en ocasiones, es deseable incluir a otros Interesados.
• Estos talleres ayudan al Propietario de Producto a dar prioridad a los requisitos y
permitir que el Equipo Scrum Principal tenga una perspectiva compartida de los
Criterios de Aceptación.
• Es una buena plataforma para discutir y aclarar todos los elementos de un producto
y a menudo profundizar en los detalles más pequeños para garantizar la claridad.
Herramientas
Reuniones de Grupo de Usuarios (*)
• Implica la participación de socios relevantes (usuarios o clientes del producto). Ellos
• proporcionan información de primera mano acerca de las expectativas del usuario. Esto ayuda en la
formulación de los Criterios de Aceptación para el producto y proporciona información valiosa para el
desarrollo deÉpicas.
• Son de vital importancia en la prevención del trabajo costoso que puedan deberse a la falta de claridad con
respecto a las expectativas yexigencias.
Herramientas

Herramientas
Reuniones de Grupo de Enfoque (Focus Group)
• Se reúnen las personas en una sesión guiada para proporcionar sus opiniones,
percepciones o valoraciones de un producto, servicio o resultado deseado.
• Los participantes tienen la libertad de hacerse preguntas el uno al otro y de obtener
aclaraciones sobre temas o conceptos específicos.
• Cunado los miembros del grupo tienen diferentes opiniones o puntos de vista, no se
escatiman esfuerzos para resolver las diferencias con el fin de llegar a un consenso.
Entrevistas con usuarios o clientes
• Es importante para ganar el contexto y la visión necesaria para desarrollar Épicas.
• Estas entrevistas ayudan a: identificar y entender las necesidades y expectativas del
interesado, reunir opiniones y hechos, comprender la perspectiva del interesado sobre
el producto final y recopilar la retroalimentación sobre el producto.
Herramientas
Cuestionario
• Una forma económica de obtener una perspectiva estadística cuantitativa
Herramientas y cualitativa de una gran número de usuarios o clientes.
• Gran cuidado debe ser ejercido en el diseño de cuestionarios, la selección
del público debe ser adecuada, y la determinación de un método apropiado
de implementación de encuestas.

Cambios Aprobados
• Solicitudes de Cambio No Aprobadas pueden ser aprobadas por el Propietario de
Producto durante el proceso Desarrollo de Épicas, a veces con sugerencias
proporcionada por los socios relevantes.
Salidas
Riesgos identificados
• Al crear Épicas, nuevos riesgos pueden ser identificados y estos riesgos identificados
constituyen una salida muy importante de esta etapa.
Salidas

Épicas ()
• Se escriben 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.
• Son Historias de Usuario grandes sin refinar en la Lista Priorizada de Pendientes del
Producto.
Salidas

Proceso: 5. Creación de la Lista Priorizada de Pendientes del Producto

Entradas Requerimientos del Negocio
• La suma de todos los conocimientos adquiridos a través de diversas herramientas
como entrevistas a los clientes o usuarios, Cuestionarios, Análisis de Brechas,
Análisis FODA, y otras reuniones, ayuda a desarrollar una mejor perspectiva sobre
los requerimientos de negocio y ayuda en la creación de la Lista Priorizada de
Pendientes del Producto.

• Todas las herramientas usadas para los procesos Aprobar, Estimar y
Comprometer Historias de Usuario se pueden utilizar para crear
estimaciones de alto nivel para Épicas cuando creamos la Lista
Priorizada de Pendientes del Producto. Se mencionan las
herramientas:
 Reuniones de Grupos de Usuario
 Planning Poker
 Fist of Five
 Metodo KANO
 Puntos para Estimación de Costos
 Otras técnicas de estimación.
Herramientas
Métodos de Estimación de Historias de Usuario

Lista Priorizada de Pendientes del Producto
• Contiene una lista priorizada de los requerimientos del negocio y de los proyect, que son de altos
niveles de Historias de Usuario.
• Se basa en tres factores principales: el valor, riesgo o incertidumbre, y dependencias.
• También se le conoce como Lista de Pendientes del Producto Ajustados con Riesgo dado que incluye
riesgos identificados y evaluados relacionados con el proyecto.
• Valor. Es la responsabilidad del Propietario de Producto asegurar en primer lugar la entrega de
los productos que ofrezcan el mayor valor. Incluso un producto de gran valor no puede ser parte
del primer release si hay otros productos de mayor valor que son suficientes para un primer
lanzamiento.
• Riesgo o Incertidumbre. Cuánta más incertidumbre existe, más riesgoso es el proyecto. Por lo
tanto, es importante que a los productos de mayor riesgo, se les de la mayor prioridad.
• Dependencias. Las dependencias pueden afectar cómo se priorizan las Historias de Usuario.
Dos de las formas más comunes para resolver dependencias son, o bien dividir una sola historia
en varias partes, o combinar historias interdependientes.
• Estimaciones, Las estimaciones de alto nivel para las Épicas también se encuentran en la Lista
Priorizada de Pendientes del Producto.
Salidas

Criterio Terminado
Conjunto de reglas que se aplican a todas las Historias de
Usuario.
• Una definición clara de “Terminado” es crítica. Ya que
elimina la ambigüedad de los requisitos y ayuda a que
el equipo se adhiera a las normas de calidad obligatoria.
• Una Historia de Usuario se considera “Terminado” cuando
se demuestra y se aprueba por el Propietario del
Producto que juzga sobre la base de los Criterios
“Terminado” y los Criterios de Aceptación de las Historias
de Usuario.
Salidas

Fase: Iniciar
Proceso: 6. Realizar el Plan de Liberaciones

Entradas Calendario de Vacaciones
• Es importante para el Equipo Scrum estar al tanto de las fechas claves y la
disponibilidad de todos los miembros del equipo.
• Esto se puede lograr mediante el uso de un calendario compartido que proporciona
información sobre los días feriados, licencias, faltas al trabajo, los planes de viaje,
eventos, etc.
• Ayudará al equipo en la planificación y ejecución de sprints.

• Se llevan a cabo para desarrollar un Plan de Liberaciones.
• El Plan define cuando varios conjuntos de funcionalidad o productos utilizables serán
entregados al cliente.
• El objetivo principal es hacer que el Equipo Scrum tenga una visión general de las
liberaciones y el calendario de entrega del producto que están desarrollando para que
puedan alinearse con las expectativas del Propietario de Producto y los socios
relevantes.
• No es necesario que en estas sesiones se elabore un Plan de Liberaciones detallado
de todo el proyecto. Este Plan se puede actualizar continuamente a medida que la
información relevante está disponible.
Herramientas
Sesiones de Planificación de Liberaciones
Métodos de Priorización de Liberaciones
• Estos métodos son específicos a la industria y organización y generalmente son
determinados por la alta dirección de la organización.Herramientas

Salidas
Clientes Objetivos para la Liberación
• No todos los lanzamientos se dirigirán a todos los socios o usuarios.
• Los Interesados optan por limitar ciertos comunicados a un subconjunto de usuarios.
• El Plan de Liberación debe especificar los clientes en quienes se va a enfocar la
lberación.
Lista Priorizada de Pendientes del Producto Refinada
• Se puede refinar en este proceso.
• Es posible que haya más claridad sobre las Historias de Usuario en la Lista Priorizada
de Pendientes del Producto después de que el Equipo Principal de Scrum lleve a cabo
Sesiones de Planificación de Liberaciones con los Interesados.
Salidas

Salidas
Cronograma de Planificación de Liberaciones (*)
• Indica que entregas van a ser realizadas a los clientes, junto con intervalos
planificados y fechas para las liberaciones.
• Puede que no haya una liberación prevista a finales de cada Sprint. A veces, una
liberación puede ser planificada después de que un grupo de Sprints se ha
completado.
• La entrega debe ser liberada cuando ofrece valor empresarial suficiente para el
cliente.
Tamaño del Sprint (*)
• Basada en las diversas entradas que incluyen Requerimientos del Negocio y
Calendario de Planificación de Liberaciones, el Propietario del Producto y el Equipo
Scrum deciden sobre el Tamaño del Sprint para el proyecto.
• Una vez determinado, el tamaño del Sprint a menudo sigue siendo el mismo durante
todo el proyecto.
Salidas

Iniciar
• Crear la visión del
proyecto
• Identificar al Scrum
Master y al socio
• Formación de un equipo
Scrum
• Desarrollo de épicas
• Creación de la lista
priorizada de
• Realizar el pan de
lanzamiento
Planear y Estimar
Historias de
estimar y
historias de
• Elaborar
Usuario
• Aprobar,
asignar
usuario
• Elaboración de tareas
• Estimar tareas
• Elaboración de la lista
de pendientes del Sprint
Implementar
• Crear entregables
• Llevar a cabo el Standup
diario
• Mantenimiento de la
lista priorizada de
Revisión y Retrospectiva
• Convocar Scrum de Scrums
• Demostración y validación
del Sprint
• Retrospectiva de Sprint
Lanzamiento
• Envío de Entregables
• Retrospectiva del Proyecto

Fase: Planear y Estimar
Proceso: 7. Elaborar Historias de Usuario

• El Propietario de Producto, basado en su interacción con los socios, conocimiento del negocio,
experiencia y las aportaciones del equipo, desarrolla las Historias de Usuario que formarán la
Lista Priorizada de Pendientes del Producto inicial para el proyecto.
• El objetivo de este ejercicio es crear Historias de Usuario elaborados y refinados que sean
aprobados y calculados, ya a su vez el Equipo Scrum se pueda comprometer.
• Aunque el Propietario del producto tiene la responsabilidad primordial de la escritura de Historias
de Usuario, y a menudo lleva a cabo este proyecto por si solo, un Taller de Escritura de Historias
de Usuario puede ser considerado si se desea.
Herramientas
Reuniones de Grupo de Enfoque
• Técnica cualitativa para medir y entender las necesidades de los usuarios y las
expectativas acerca de un producto propuesto.
• Un pequeño grupo de usuarios es seleccionado para formar el grupo de enfoque.
• Normalmente se adhieren a un determinado formato en el que al grupo se le hacen
preguntas que luego discuten entre ellos.
• Cada reunión del grupo de enfoque puede tener sus propias reglas de discusión a lo
decidido por los organizadores.
• Se llevan a cabo en presencia de un moderador.
Herramientas
Experiencia para escribir Historias de Usuario

Salidas
Historias de Usuario(*)
• Una Historia de Usuario indica tres cosas acerca de la exigencia: ¿Quién, qué y
porqué?
• Los requisitos expresados en Historias de Usuario son declaraciones breves, simples y
fáciles de entender.
• Los resultados de formato estándar predefinidos resultan en una major comunicacón
entre los socios y mejores cálculos determinados por el equipo.

Salidas
Criterios de Aceptación de Historias de Usuario
• Cada Historia de Usuario está asociado con Criterios deAceptación.
• Las Historias de Usuario son subjetivas, por lo que los Criterios de Aceptación
proporcionan la objetividad requerida para que la Historia de Usuario sea considerada
como “Terminado”, o no, durante la Reunión de Revisión.
• El Propietario de Producto define y comunica los Criterios de Aceptación al Equipo
Scrum.
• Es importante, y la responsabilidad del Scrum Master, asegurar que el Propietario del
Producto no cambie los Criterios de Aceptación de una Historia de Usuario que ya
está comprometido a un Sprint.

Fase: Planear y Estimar
Proceso: 8. Aprobar, Estimar y Asignar Historias de Usuario

Entradas Historias de Usuario
• Las Historias de Usuario tienen estimaciones de alto nivel de los procesos de
Creación de la Lista Priorizada de Pendientes del Producto y Elaborar Historias de
Usuario.
• Estas estimaciones sería utilizadas por el Propietario del Producto para crear una
lista de Historias de Usuario aprobados que se estiman con mayor precisión por el
Equipo Scrum.

Estimación de Tamaño
≠
Estimación de Duración

Planning Poker
También llamada Estimation Poker, es una técnica de
estimación o cálculo que utiliza el consenso para
estimar los tamaños relativos de las Historias de
Usuario o el esfuerzo requerido para crearlos.
La historia se presenta y se discute sobre ella.
• Los miembros del equipo escogen la carta con la
estimación.
• Todos dan la vuelta a la carta a la vez.
• Los miembros con la estimación más baja y más alta
exponen sus razones, y se repite el proceso de
estimación.
Herramientas

Fist of FIve
Mecanismo sencillo para llegar a un consenso en un grupo e iniciar 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 del 1 al 5 usando sus dedos.
• El valor en el uso de esta técnica no es sólo la creación de consenso, sino también la
reflexión y la charla ya que a cada miembro del equipo se le pide que explique el motivo de
su clasificación.
• Una vez que el equipo ha discutido, se tomará una decisión colectiva.
• Un dedo: No estoy de acuerdo con la conclusión del grupo y tienen grandes
preocupaciones.
• Dos dedos: No estoy de acuerdo con la conclusión del grupo y me gustaría hablar de
algunos problemas menores.
• Tres dedos: No estoy seguro y me gustaría asumir la conclusión del consenso del grupo.
• Cuatro dedos: Estoy de acuerdo con la conclusión del grupo y me gustaría discutir
algunos problemas menores.
• Cinco dedos: Estoy totalmente de acuerdo con la conclusión del grupo.
Puntos
Herramientas

Puntos para Estimación del Costo
• La estimación del costo se puede lograr mediante el uso de unidades
relativas en lugar de unidades absolutas.
• Con el fin de estimar el costo de implementar una Historia de
Usuario, el Equipo Scrum puede utilizar Puntos de Historia, en lugar de
unidades monetarias.
Delphi
• Técnica de estimación basada en grupo para la determinación de la
cantidad de trabajo que está involucrado y el tiempo que tardará en
completarse.
• Los individuos de un equipo de forma anónima proporcionan
estimaciones para cada función y las estimaciones iniciales se trazan
en una gráfica.
• Posteriormente el equipo analiza los factores que influyeron en sus
estimaciones y proceden a una segunda ronda de estimación. Este
proceso s repite hasta que las estimaciones de los individuos sean
similares y se llegue a un consenso para la estimación final.
• Planning Poker es un ejemplo de esta técnica.
Herramientas

Historias de Usuario Aprobadas, Estimadas y
Comprometidas
• Las Historias de Usuario se estiman por el equipo
utilizando las distintas técnicas de estimación.
• Después de la estimación, el equipo se
compromete en un subconjunto de Historias de
Usuario aprobados y estimados que creen que
pueden completar en el próximo Sprint. Estas
Historias de Usuario se convertirán en parte de la
Lista de Pendientes del Sprint.
Salidas

Proceso: 9. Elaboración de Tareas
Reuniones de Planificación de Tareas
• El equipo Scrum se reúne para planificar el trabajo que se realizará en el
Sprint.
• El equipo revisa las Historias de Usuario ya comprometidos en la parte
superior de la Lista Priorizada de pendientes del Producto.
• El Propietario del Producto está presente en esta reunión en caso se
requiera.
• Esta reunión será time-boxed, con la longitud estándar limitada a dos
horas por semana durante el Sprint.
• A veces también se conoce como Reunión de Planificación del Sprint.
Herramientas

Tarjetas de Vocabulario
• Las Historias de Usuario se escriben en pequeñas Tarjetas.
• Sólo los detalles esenciales están documentados en las tarjetas, que
pueden ser utilizados por el Equipo Scrum para colaborar y discutir.
Descomposición
• Es una herramienta mediante la cual las tareas de alto nivel se dividen en
tareas detalladas con niveles más bajos.
Herramientas

Determinación de Dependencias
• Ayuda a los Equipos Scrum a determinar el orden relativo en el que las
tareas deben ejecutarse para crear los entregables del Sprint.
• Existen numerosos tipos de dependencias: obligatorias y discrecionales,
internas y externas, o alguna combinación de estas dependencias.
• Mandatorias. Que son ya sea inherente a la naturaleza del trabajo, como
una limitación física, o puedan deberse a las obligaciones contractuales o los
requisitos legales.
• Discrecionales. Se colocan en el flujo de trabajo por decisión propia.
Normalmente, son determinados por el Equipo Scrum, basadas en las
experiencias del pasado o en las mejores prácticas.
• Externas. Son las tareas, actividades o productos que están fuera del
alcance del Equipo Scrum, pero son necesarias para completar una tarea de
proyecto o crear una prestación del proyecto.
• Internas. Son las dependencias de tareas
Herramientas

Lista de Tareas
• Lista complete con todas las tareas a la que el Equipo Scrum se ha
comprometido para el Sprint actual.
• Contiene descripciones de cada tarea junto con las estimaciones derivadas
durante el proceso de Elaboración de Tareas.
• Deben incluir cualquier esfuerzo de prueba y de integración de manera
que el Incremento del Producto del Sprint se puedea integrar con éxito en
las entregas anteriores de Sprints.
Dependencias
• Describen la relación e interacción entre diferentes tareas de un proyecto
y pueden ser clasificadas como obligatorias o discrecionales, o interna o
externa.
• Hay numerosas maneras de identificar, definer y presenter las tareas y sus
dependencias. Dos métodos comunes involcucran el uso de diagramas de
flujo del producto y diagramas de Gantt
Salidas
Salidas

Proceso: 10. Estimar Tareas
Criterios de Aceptación de Historias de Usuario
• El Equipo Scrum debe asegurarse de que los Criterios de Aceptación
definidos sean apropiados para las Historias de Usuario y proporcionen
claridad en cuanto a los requisitos para el Equipo Scrum.
• En el desarrollo de los Criterios de Aceptación de Historias de Usuario, lo
siguiente debe ser considerado:
Criterios de Aceptación no deben ser vagos, ambiguos o
demasiado generalizados.
Criterios de Aceptación definidos aseguran de que el equipo sea
capaz de verificar que los resultados estén alineados con las metas
y objetivos de la organización patrocinadora.
Entrada

Reuniones de Estimación de Tareas
• Le permiten al Equipo Scrum estimar el esfuerzo necesario para completar una
tarea o conjunto de tareas y estimar el esfuerzo de las personas y otros recursos
necesarios para llevar a cabo los trabajos dentro de un Sprint determinado.
• El equipo Scrum puede utilizar diversas técnicas como segmentación
(descomposición), la opinión de expertos, estimación análoga, y la estimación
paramétrica.
• También se conoce como Reunión de Planificación del Sprint. También se puede
combinar con la Reunión de Planificación de Tareas
Criterios de Estimación
• El objetivo principal de utilizar estos criterios, es mantener los tamaños d
estimación relativos y minimizar la necesidad de reestimación.
• Se pueden expresar de muchas maneras, dos ejemplos comunes son los Puntos
de Historia y el Tiempo Ideal
Herramientas

Lista de Tareas y su Esfuerzo Estimado
• Lista de las tareas asociadas con las Historias de Usuario incluidos en un Sprint.
• El esfuerzo estimado se expresa en téminos de los Criterios de Estimación
acordados por el Equipo.
• Es usado por el Equipo Scrum durante la Reunión de Planificación del Sprint para
crear la Lista de Pendientes del Sprint y el Gráfico del Trabajo Consumido del
Sprint.
• También se utiliza para determiner cuando el equipo necesita reducer su
compromiso, o cuando puede asumir Historias de Usuario adicionales durante la
Planificación del Sprint.
Lista de Tareas Actualizada
• También puede haber re-estimaciones resultantes de una revision de los
principios de Sprints, o un cambio en la comprensión colectiva del Equipo Scrum
relacionado a las Historias de Usuario y los requisitos.
Salidas
Salidas

Proceso: 11. Elaboración de la Lista de Pendientes del Sprints
Velocidad previa del Sprint
• Velocidad del Sprint es la velocidad en la que el equipo puede completar el
trabajo en un Sprint.
• Por lo general, se expresa en las mismas unidades que las utilizadas para la
estimación.
• Se mantiene un registro de la Velocidad de Sprint del equipo para cada sprint y
se utiliza como referencia en los siguientes Sprints.
• Cualquier cambio en la situación o las condiciones desde el último sprint se
tienen en cuenta para asegurar una estimación precisa de la Velocidad del Sprint
para el próximo sprint.
Calendario del Equipo
• Contiene información sobre la disponibilidad de los miembros del equipo,
incluyendo la información correspondiente a las vacaciones de los empleados,
fechas de licencia, entre otros.
• Ayuda al equipo no sólo en la planificación y ejecución de sprints eficientes, sino
también en la alineación de Sprints con las fechas de liberación.
Entradas
Entrada
Entrada

Reuniones de Planificación del Sprint
• Durante esta reunión, las Historias de usuario, los cuáles son aprobados, calculados,
y con los cuales ya hay un compromiso, serán examinados por el Equipo Scrum.
• El Equipo Scrum también crea la Lista de Pendientes del Sprint y Gráfica del Trabajo
Consumido del Sprint.
Herramientas de Seguimiento del Sprint
• Una variedad de herramientas se puede utilizar para realizar el seguimiento del
trabajo en un Sprint, pero uno de los más comunes es un ScrumBoard, también
conocido como Task Board o Progress Chart.
• El Scrumboard se divide en secciones: To Do (a veces conocido como Work not
Started), Work in Progress, y Completed Work.
Métricas de Seguimiento del Sprint
• Velocidad. Representa el # de Historias de Usuario o# de funcionalidades
entregadas en un solo Sprint.
• Valor del Negocio Entregado. Mide el valor de las Historias de Usuario entregados
desde el punto de vista comercial.
Herramientas
Herramientas
Herramientas

Lista de Pendientes del Sprint
• Lista de las tareas a ser ejecutadas por el Equipo Scrum en el prósimo Sprint.
• Es una práctica, que la Lista de Pendientes del Sprint se represente en un
Scrumboard o tablero de tareas, que proporciona yna representación visible
constantemente de la situación de las Historias de Usuario.
• También se incluyen algunos riesgos asociados con las diversas tareas. Todas las
actividades de mitigación para hacer frente a los riesgos identificados también serán
incluidos como tareas.
Gráfica del Trabajo Consumido del Sprint (Sprint Burndown Chart )
• Es un gráfico que muestra la cantidad de trabajo que queda en el Sprint actual.
• Un gráfico relacionado es una Gráfico del Trabajo Realizado del Sprint (Sprint
Burnup Chart) que muestra el trabajo realizado del Sprint.
Salidas
Salidas
Salidas

Proceso: 12. Crear Entregables
ScrumBoard
El equipo utiliza un Scrumboard para planificar y realizar un seguimiento de los
progresos realizados durante cada SprintEntrada

Registro de Impedimentos
Impedimento es cualquier obstáculo o barrera que reduce la productividad del
Equipo Scrum. • Los impedimentos deben ser registrados formalmente por el
Scrum Master en un registro de impedimentos, y pueden ser discutidos durante
las Reuniones Diarias y la Reunión de Revisión del Sprint.
Entrada

Experiencia del Equipo
Se refiere a la experiencia colectiva de los miembros del Equipo Scrum para entender
las Historias de Usuario y tareas en la Lista de Pendientes del Sprint con el fin de crear
los entregables finales. • Los miembros del Equipo Scrum tienen la autoridad y la
responsabilidad de determinar los mejores medios para convertir los elementos de la
Lista Priorizada de Pendientes del Producto en productos terminados, sin necesidad
de participación de todos los socios del equipo.
Software
• Las herramientas automatizadas pueden ser utilizadas para la programación, la
recopilación de información y la distribución
Herramientas
Herramientas

Entregrables del Sprint
• Al final de cada Sprint, se complete un mínimo de productos o entregables. • La
entrega debe poseer todas las características y funcionalidades definidas en las
Historias de Usuario incluidas en el Sprint, las cuales deben ser probadas con éxito.
Scrumboard actualizado
• Se actualiza con regularidad a medida que el equipo produce más trabajo.
• Al final del Sprint, el Scrumboard se restablecerá o borrará y un Nuevo Scrumboard
se creará para el próximo Sprint.
Riesgos mitigados
• A medida que el Equipo Scrum ejecuta el trabajo de los entregables de acuerdo a
las Historias de Usuario en la Lista Priorizada de Pendientes del Producto, lleva a cabo
las acciones de mitigación que se han definido para abordar cualquier riesgo
identificado.
• El equipo documenta los nuevos riesgos identificados y las medidas de mitigación
adoptadas.
• El registro de los riesgos del proyecto es un documento vivo, actualizado de forma
continua durante todo el proyecto
Salidas
Salidas
Salidas

Proceso: 13. Llevar a cabo el Standup Diario
Experiencia del día previo
• Los miembros del Equipo Scrum mantienen al tanto a sus compañeros de equipo
en la Reunión Diaria.
• Esta sesión se denomina Standup porque los miembros están de pie durante
toda la reunión.
• Los miembros del equipo discuten logros y la experiencia del días anterior.
Entrada

Reunión Diaria Standup
• Es una reunión diaria de corta duración.
• Time-boxed a 15 minutos.
• Los miembros del equipo se reúnen para informar de sus progresos en el Sprint
y planificar las actividades del día.
• La duración de las reuniones es muy corta y se espera que todos los miembros
del Equipo Scrum asistan.
• La reunión no se cancela o se retrasa si uno o más miembros no pueden asistir.
• En la reunión, cada miembro del Equipo Scrum proporciona respuestas a las tres
preguntas diarias.
• Se recomiendan los debates entre el Scrum Master y el equipo o entre algunos
miembros del Equipo Scrum, pero estas discusiones suceden después del Daily
Standup para asegurar que la reunión sea corta.
Herramientas
Herramientas

Tres preguntas diarias
• En la Reunión Diaria Standup, facilitado por el Scrum Master, cada miembro del
Equipo Scrum proporciona información en forma de respuestas a las tres
preguntas específicas:
¿Qué Hice ayer?
¿Qué voy hacer 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.
• En ocasiones, otros elementos pueden ser discutidos, pero esto se reduce al
mínimo para respetar el aspecto time-boxed de la reunión.
• Es muy recomendable que las dos primeras preguntas sean respondidas por los
miembros del equipo de manera cuantificable, si es posible, en lugar de
respuestas largas y cualitativas.
Herramientas

Cuarto de Guerra
• En Scrum, es preferible que el equipo esté colocado, en otras palabras, que
todos los miembros del equipo trabajen en el mismo lugar.
• Está diseñado de tal manera que los miembros del equipo pueden moverse
libremente, trabajar y comunicarse fácilmente ya que se encuentran cerca el uno
del otro.
• Típicamente, hay tarjetas índices, fichas, notas adhesivas, y otras herramientas
de baja tecnología, y de alto contacto, que se encuentran disponibles en el Cuarto
de Guerra para facilitar el flujo de trabajo, la colaboración y la resolución de
problemas.
• La sala es a veces ruidosa debido a las conversaciones del equipo, pero estas
conversaciones contribuyen al progreso del equipo.
• Un buen Cuarto de Guerra no tiene cubículos y permite que todo el equipo se
siente junto para asegurar la comunicación cara a cara, lo que conduce a la
formación de equipos y la apertura.
Videoconferencia
• Cuando el equipo está distribuido, se hace imperativo el uso de herramientas de
videoconferencia para permitir la comunicación cara a cara
Herramientas
Herramientas

Equipo Scrum Motivado
Reuniones Diarias Standup propagan la idea de que cada miembro del equipo es
valioso y es un importante contribuyente, lo que mejora la moral individual del
equipo.
• Esto, junto con el concepto de equipos de auto-organizacón, mejora la
motivación general, conduce a un major rendimiento del equipo y mejora la
calidad de los resultados producidos.
Salidas

Proceso: 14. Mantenimiento de la Lista Priorizada de
Pendientes del Producto
Entregables Rechazados
• En los casos en que una entrega no cumpla con los criterios de aceptación, esto
se considera como entregables rechazados.
• Los entregables rechazados normalmente no se encuentran en una lista
separada. Simplemente permanecen en la Lista Priorizada de Pendientes del
Producto y no son marcados como “Terminado” para que puedan ser
repriorizados y sean considerados para el desarrollo en el próximo Sprint.
Lista de Pendientes del Producto del Programa actualizado
• Los cambios en la Lista de Pendientes del Producto del Programa pueden ser el
resultado de cambios en cualquiera de las condiciones internas o externas. • Las
condiciones externas pueden incluir el cambio de situaciones de negocio,
tendencia de la tecnología, o requisitos de cumplimiento legal.
• Los factores internos podrían estar relacionados con las modificaciones en la
estrategia o las políticas de la organización, riesgos identificados y de otros
factores.
Entradas
Entrada
Entrada

Reuniones de Revisión Lista de Pendientes del Producto del Programa
• El Propietario del Producto puede tener reuniones múltiples y separadas con los
socios, el Scrum Master y el Equipo Scrum relevante para asegurar que él o ella
tenga suficientes información para hacer cambios en la Lista Priorizada de
Pendientes del Producto.
• La intención de las reuniones es asegurar que las Historias de Usuario y los
Criterios de Aceptación se entiendan y se escriban correctamente por el Propietario
del Producto de modo que reflejen los requisitos de los Interesados; que las
Historias de Usuario sean entendidos por todos los miembros de Equipo Scrum; y
que las Historias de Usuario de los usuarios de alta prioridad sean refinados para
que el Equipo Scrum pueda estimar correctamente y comprometerse con este tipo
de Historias de Usuario.
Técnicas de comunicación
• Scrum promueve la comunicación precisa y eficaz sobre todo a través de
colocación del Equipo Scrum.
Herramientas
Herramientas
Herramientas

Lista Priorizada de Pendientes del Producto actualizado
• Puede ser actualizado con nuevas Historias de Usuario, nuevas Solicitudes de
Cambio, nuevos Riesgos Identificados, Historias de Usuario actualizados, o la nueva
prorización de Historias de Usuario existentes.
Cronograma de Planificación de Liberaciones actualizado.
• Puede ser actualizado para reflejar el impacto de las Historias de Usuario nuevas
o modificadas en la Lista Priorizada de Pendientes del Producto.
Salidas
Salidas
Salidas

Proceso: 15. Convocar Scrum de Scrums
Scrum Master o Representantes Equipo Scrum
• Normalmente, un miembro de cada Equipo Scrum representará a su equipo en
la Reunión de Scrum de Scrums
• En la mayoría de los casos, este es el Scrum Master, pero a vece alguien más
puede representar al equipo.
Agenda de la Reunión
• El propósito de la reunión es comunicar el progreso entre múltiples equipos.
• El Jefe Scrum Master (o cualquier Scrum master que facilite la reunión) puede
anunciar una agenda antes de la reunión.
• Cualquier impedimento que enfrente un equipo que pueda afectar a otros
equipos, se debe indicar para ser tratado durante la reunión SoS.
• Además si un equipos de da cuenta de un problema de gran escala, un cambio o
riesgo que pueda afectar a otros equipos, esto debe ser comunicado en la reunión
SoS.
Entradas
Entrada
Entrada

Reuniones Scrum de Scrums
• Son reuniones preferentemente cortas (no time-boxed para permitir un mayor
intercambio de información entre equipos) donde los representantes de los
Equipos Scrum se reúnen para compartir el estado de los equipos respectivos.
• La Reunión SoS se llevará cabo en intervalos predefinidos o cuando sea
requerido por los Equipos Scrum.
Cuatro preguntas por equipo
• Cada representante del equipo Scrum proporcionará actualizaciones de su
equipo.
• ¿En qué ha estado trabajando mi equipo desde la última reunión?
• ¿Qué va a hacer mi equipo hasta la próxima reunión?
• ¿Con qué contaban otros equipos que mi equipo hiciera que no se ha hecho?
• ¿Qué piensa hacer nuestro equipo que pueda afectar a otros equipos?
Herramientas
Herramientas

Mejor Coordinación del Equipo
• La reunion SoS facilita la coordinación de trabajo entre varios Equipos Scrum.
• Esto es especialmente importante cuando hay tareas que impliquen
dependencias entre equipos.
• Mediante el uso de reunions SoS, las organizaciones tienen más Colaboración
que las personas que trabajan en equipos cerrados donde esencialmente se
preocupan por sus propias responsabilidades.
Problemas Resueltos
• Reuniones SoS es un foro donde todos los miembros del Equipo Scrum tienen la
oportunidad de debater de forma transaparente los problemas que influyen es
nsu proyecto.
• Esta discusión oportuna y la resolución de problemas en la reunion SoS mejora
en gran medida la coordinación entre los diferentes Equipos Scrum, y también
reduce la necesidad de crear un Nuevo trabajo y diseñ
Salidas
Salidas

Proceso: 16. Demostración y Validación del Sprint
Reuniones de Revisión del Sprint
• Los miembros del Equipo Principal de Scrum y los Interesados correspondientes
participan en esta reunión para aceptar los entregables en acuerdo con los
Criterios de Aceptación, y donde se rechazan las entregas inaceptables.
• Estas reuniones son convocadas al final de cada Sprint.
• El Equipo Scrum demuestra los logros del Sprint, incluyendo las nuevas
funcionalidades o productos creados.
• Esto proporciona una oportunidad para que el Propietario del Producto y los
Interesados inspeccionen lo que se ha completado hasta el momento, y para
determinar si algún cambio se debe hacer en el proyecto o procesos en Sprints
posteriores
Herramientas

Proceso: 16. Demostración y Validación del Sprint
Entregables Aceptados
• Los entregables que cumplen con los Criterios de Aceptación son aceptados por
el Propietario de Producto.
• El objetivo de un Sprint es crear entregables potencialmente listos para ser
entregados, o incrementos de productos que cumplan con los Criterios de
Aceptación definidos por el Cliente y el Propietario del Producto.
Entregables Rechazados
• Si los entregables no cumplen con los Criterios de Acpetación, tales entregables
son rechazados.
Salidas
Salidas

Proceso: 17. Retrospectiva del Sprint
Reuniones de Retrospectiva del Sprint
• Es un elemento importante del marco de Scrum llamado “inspeccionar-
adaptar” 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.
• Se recomienda, pero no se requiere que el Propietario de Producto asista.
• Un miembro del equipo documenta las charlas y los elementos para acciones
futuras.
• Es esencial tener esta reunión en un ambiente abierto y relajado para obtener la
participación de todos los miembros del equipo.
• Los objetivos principales de la reunión son identificar tres elementos específicos:
Las cosas que el equipo tiene que seguir haciendo: mejores prácticas
Las cosas que el equipo necesita empezar a hacer: mejoras en el proceso
Las cosas que el equipo necesita dejar de hacer: problemas de proceso y
embotellamiento
• Estas áreas se discuten y una lista de Acciones de Mejora Acordadas es creada.
Herramientas
Herramientas

Explorer – Shopper – Vacationer – Prisoner (ESVP)
• Este es un ejercicio que puede realizarse al inicio de la reunión para entender la
mentalidad de los participantes y establecer el tono de la reunión.
• Se les pide a los asistentes que indiquen de forma anónima el término que
mejor representa cómo se sienten con respecto a su participación en la reunión.
Explorer. Quiere participar y aprender todo lo que se discutió en la
retrospectiva.
Shopper. Quiere escuchar todo y elegir lo que desea de la retrospectiva.
Vacationer. Quiere relajarse y ser turista en la retrospectiva.
Prisoner. Quiere estar en otro lugar y asiste a la retrospectiva ya que se
requiere.
• El Scrum Master luego recopila las respuestas, prepara y comparte la
información con el grupo.
Herramientas

Reuniones Scrum de Scrums
• Son reuniones preferentemente cortas (no time-boxed para permitir un mayor
intercambio de información entre equipos) donde los representantes de los
Equipos Scrum se reúnen para compartir el estado de los equipos respectivos.
• La Reunión SoS se llevará cabo en intervalos predefinidos o cuando sea
requerido por los Equipos Scrum.
Cuatro preguntas por equipo
• Cada representante del equipo Scrum proporcionará actualizaciones de su
equipo.
• ¿En qué ha estado trabajando mi equipo desde la última reunión?
• ¿Qué va a hacer mi equipo hasta la próxima reunión?
• ¿Con qué contaban otros equipos que mi equipo hiciera que no se ha hecho?
• ¿Qué piensa hacer nuestro equipo que pueda afectar a otros equipos?
Herramientas
Herramientas

Speed Boat
• Es una técnica que se puede utilizar para llevar a cabo la reunión de
Retrospectiva.
• Los miembros del equipo hacen que son tripulantes en un speed boat. El barco
debe llegar a una isla, lo cual es simbólico de la visión del proyecto.
• Las notas adhesivas son utilizadas para registrar “los motores” y “anclas”. Los
motores les ayudan a llegar a la isla, mientras que los anclajes les impiden llegar. •
Este ejercicio es time-boxed a unos pocos minutos.
• Una vez que todos los elementos están documentados, la información se analiza
y prioriza mediante un proceso de votación. Los motores se reconocen y se
planifican las acciones de mitigación de los anclajes, dependiendo de la prioridad.
Métricas y técnicas de medición
• Velocidad de Equipo. # Puntos de Historia hecho en un determinado Sprint.
• Índice de éxito de Terminado. % de Puntos de Historia que han sido Terminados,
en relación a los que se han llevado a cabo.
Herramientas
Herramientas

Métricas y técnicas de medición
• Estimación de eficacia. # o % de discrepancia entre el tiempo previsto y el
tiempo verdadero que se ha utilizado en las tareas e Historias de Usuario.
• Clasificación de retroalimentación de repaso. La retroalimentación puede
ser solicitada por los Interesados, usando calificaciones cuantitativas o
cualitativas que proporcionan una medición del rendimiento del equipo.
• Calificación de la moral del equipo. El resultado de autoevaluaciones de la
moral del equipo.
• Retroalimentación de los compañeros. Retroalimentación de 360 grados se
puede utilizar para solicitar información y crítica constructiva sobre el
rendimiento del equipo.
• Progreso para la liberación. El valor del negocio proporcionado en cada
versión, así como el valor representado por el progreso actual hacía una
liberación
Herramientas

Acciones de Mejora Acordadas
• Es el primer resultado del proceso. Es la lista de elementos configurables que el
equipo ha llegado a hacer frente a los problemas y mejorar los procesos con el fin
de mejorar su desempeño en el futuro Sprint.
Elementos de Acción Acordados y Fechas
• Una vez que las Acciones de Mejora Acordadas se han elaborado y refinado, los
puntos de acción para aplicar las mejoras pueden ser considerados por el Equipo
Scrum.
• Cada elemento de acción tendrá una fecha de vencimiento definida para su
conclusión
Salidas
Salidas

Proceso: 18. Envío de Entregables
Plan Piloting
• Es una entrada opcional que se puede utilizar para trazar una implementación
piloto en detalle.
• El alcance y los objetivos del despliegue, despliegue objetivo base de usuarios,
un cronograma de implementación, planes de transición, preparación de usuario
necesaria, los criterios de evaluación para el despliegue, y otros elementos
relacionados con el despliegue se especifican en este plan y son compartidos con
los socios.
Entradas .
Entrada

Proceso: 19. Retrospectiva del Proyecto

Backlog del
producto
Backlog del
sprint
Incremento del
producto con
calidad productiva
Sprint de
2-4 semanas
Scrum diario

Gestión regular de las expectativas
del cliente
El cliente establece sus expectativas indicando el
valor que le aporta cada requisito del proyecto y
cuando espera que esté completado.
El cliente comprueba de manera regular si se van
cumpliendo sus expectativas, da feedback, ya desde
el inicio del proyecto puede tomar decisiones
informadas a partir de resultados objetivos y dirige
estos resultados del proyecto, iteración a iteración,
hacia su meta. Se ahorra esfuerzo y tiempo al evitar
hipótesis.

Resultados anticipados (“time to
market”)
• El cliente puede empezar a utilizar los resultados
más importantes del proyecto antes de que esté
finalizado por completo.
• Siguiendo la ley de Pareto (el 20% del esfuerzo
proporciona el 80% del valor), el cliente puede
empezar antes a recuperar su inversión (y/o
autofinanciarse) comenzando a utilizar un
producto al que sólo le faltan características poco
relevantes, puede sacar al mercado un producto
antes que su competidor, puede hacer frente a
urgencias o nuevas peticiones de clientes, etc.

Flexibilidad y adaptación
• De manera regular el cliente redirige el proyecto
en función de sus nuevas prioridades, de los
cambios en el mercado, de los requisitos
completados que le permiten entender mejor el
producto, de la velocidad real de desarrollo, etc.
• Al final de cada iteración el cliente puede
aprovechar la parte de producto completada
hasta ese momento para hacer pruebas de
concepto con usuarios o consumidores y tomar
decisiones en función del resultado obtenido.

Retorno de inversión (ROI)
• De manera regular, el cliente maximiza el ROI
del proyecto. Cuando el beneficio pendiente
de obtener es menor que el coste de
desarrollo, el cliente puede finalizar el
proyecto.

Mitigación de riesgos
• Desde la primera iteración el equipo tiene que
gestionar los problemas que pueden aparecer en una
entrega del proyecto. Al hacer patentes estos riesgos,
es posible iniciar su mitigación de manera anticipada.
"Si hay que equivocarse o fallar, mejor hacelo lo antes
posible". El feedback temprano permite ahorrar
esfuerzo y tiempo en errores técnicos.
• La cantidad de riesgo a que se enfrenta el equipo está
limitada a los requisitos que se puede desarrollar en
una iteración. La complejidad y riesgos del proyecto se
dividen de manera natural en iteraciones

Equipo motivado
• Las personas están más motivadas cuando
pueden usar su creatividad para resolver
problemas y cuando pueden decidir organizar
su trabajo.
• Las personas se sienten más satisfechas
cuando pueden mostrar los logros que
consiguen.

¿Qué beneficios y ventajas le va a proporcionar
el método SCRUM a mi negocio?

A) A NIVEL DE LA PLANTILLA:
• Se crean roles que fomentan el trabajo en equipo: el Product
Owner delimita aquello a construir en el próximo sprint, el equipo
de desarrollo se encarga de llevar a cabo el trabajo y de presentarlo
al cliente. A partir del feedback del cliente se decide cómo se
encaminara el siguiente sprint. Por último el Scrum Masters se
asegura que todo este proceso ocurre de una forma óptima en las
mejores condiciones.
• Incremento de la motivación de los trabajadores: los equipos de
trabajo se autogestionan sus tareas y además ven los frutos de su
trabajo rápidamente ya que en un breve periodo de tiempo pueden
enseñarle su “obra” al cliente.
• Fomenta la creatividad de la plantilla: breves espacios de tiempo
con necesidad de innovar hacen sacar lo mejor de uno mismo y de
un grupo de trabajo.

B) A NIVEL DE PROCESOS:
• Transparencia en el desarrollo de los procesos y mayor control de cada etapa: se
trabaja alrededor de un documento llamado sprint backlog en el cual se especifica
cómo el equipo de trabajo va a llevar a cabo las tareas durante el siguiente
sprint Cada tarea especificada en este documento se divide en horas y no es
asignada a un miembro en concreto sino que es trabajada de un modo conjunto y
multidisciplinar por de los diferentes miembros del equipo.
• Feedback continua y ritmo predictible de trabajo: se tiene un gran control sobre
el desarrollo de cada etapa, los errores pueden ser rectificados rápidamente sin
afectar prácticamente al timming (sin la implementación del método SCRUM esto
sería inviable). Por este motivo se mejora la calidad del producto/ servicio.
• Pone en sintonía al cliente con el proveedor (equipo de desarollo), estrechando
los lazos colaborativos cara a cara y creando productos y servicios adaptados
sistemáticamente a las necesidades del cliente (ahorro de tiempo). ¡De este modo
se cumple aquello que se promete!
• El mayor coste de su implementación no es el de una inversión económica sino
que viene determinado por los esfuerzos y la capacidad para organizar y gestionar
correctamente la adopción de esta metodología.

C) A NIVEL DE RESULTADOS
• Mayor productividad: incrementa la productividad fruto
del incremento de la motivación grupal y del control de
cada etapa contenido en un timeline (que es muy breve y
específico); conjuntamente propician una reducción de los
riesgos en todo el proceso.
• Permite una adaptabilidad a los cambios continuos del
mercado aportando así una ventaja competitiva: se
genera una gran capacidad de reacción frente a las
novedades empresariales.
• Maximiza el retorno de la inversión (ROI): esto se
consigue gracias a invertir el tiempo, dinero y esfuerzo a
aquello que realmente ofrece valor al negocio, la
priorización de las necesidades del cliente en cada
momento juegan un papel clave.

Scrum trainer freddy vargas clase 3

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Scrum trainer freddy vargas clase 3

Similar a Scrum trainer freddy vargas clase 3 (20)

Último

Último (20)

Scrum trainer freddy vargas clase 3