Curso Metodología SCRUM V1

Curso
SCRUM Master
Certificado
Instructor José Luis Díaz, MBA, SMC, PMP
[email protected]
SCRUM
Certificación SCRUM Master
1. Curso con 3. Examen en 4.

2. Plataforma
instructor línea Certificación
• En línea zoom • 100 preguntas

• 16 horas online.vmedu.com • Opción múltiple
• 4 sesiones de 4 • 2 horas
horas cada una • Vigencia 6 meses • Español
• Videos • 2 intentos
• Examenes
SCRUM
Certificaciones SCRUM
Opcional, pero preferido
SFCTM SDCTM Obligatorio
Curso introductorio en línea Para todos los miembros del
para todos los interesados en Equipo Scrum, participantes y
aprender sobre Scrum stakeholders
SMCTM SAMCTM SPOCTM

Para todos los Certificación general de Ágil Para todos los
Scrum Masters para profesionistas ágiles Product Owners
SSMCTM SSPOCTM
Scaled Scrum Master Scaled Scrum Product
Certified Owner Certified
ESMCTM
Expert Scrum Master
Certified
Todos los exámenes de certificación de SCRUMstudy son supervisados en línea. Los participantes necesitarán una
computadora y una cámara web para hacer el examen, mismo que será supervisado en vivo por VMEdu.
3 SCRUM
Framework de la Guía SBOK™
La Guía SBOK™ está ampliamente dividida en tres áreas: principios, procesos y aspectos
6
Principios
5
Aspectos
5 Fases
19 Procesos
4 SCRUM
© 2019 VMEdu.com. All rights reserved
Programa
1. Introducción. Ágil, SCRUM, Principios, Guía SBOK
2. Principios
1.Control del proceso empírico

2.Auto-organización
3.Colaboración
4.Priorización basada en valor
5.Time-boxing
6.Desarrollo iterativo
3. Aspectos de Scrum
1.Organización
2.Justificación del negocio
3.Calidad
4.Cambio
5.Riesgo
4. Fases y procesos de Scrum
1.Inicio
2.Planificación y estimación
3.Implementación
4.Revisión y retrospectiva
5.Lanzamiento
5 SCRUM
1. Introducción
SCRUM
¿Qué es un proyecto?
Un proyecto es un emprendimiento colaborativo para crear

nuevos productos o servicios, o para obtener resultados.
Los proyectos por lo general se ven afectados por limitaciones

de tiempo, costo, alcance, calidad, personal y la capacidad de
la organización.
SCRUM
¿Qué es Ágil?
“La agilidad es la habilidad de

crear y responder al cambio
a fin de obtener ganancias en un ambiente turbulento.
flexibilidad y
Es la capacidad de equilibrar la
adaptabilidad con la estabilidad”.

-Highsmith, 2002
SCRUM
¿Cuál es la necesidad de la agilidad?
Mercados y tecnologías que cambian rápidamente – Necesidad de estar a la

vanguardia
Reducción del “tiempo para comercializar” productos y aumento en la

demanda de innovación por parte de los clientes
Reducción de costos de pruebas y experimentación (simulación y

automatización)
El valor para el cliente se entrega en el punto de venta, no en el punto de

planificación
Necesidad de un método adaptativo de desarrollo en vez de métodos

tradicionales y predictivos
SCRUM
Manifiesto Ágil
Individuos e interacciones Sobre Procesos y herramientas
Software funcionando
Sobre Documentación extensiva
(resultados cuanto antes)
Negociación contractual
Colaboración con el cliente Sobre
(planes rígidos)
Respuesta ante el cambio Sobre Seguir un plan
SCRUM
12 Principios ágiles
1. Nuestra mayor prioridad es satisfacer al cliente 7. El software (trabajo, resultados) funcionando
mediante la entrega temprana y continua de es la medida principal de progreso.
software valioso. 8. Los procesos ágiles promueven el desarrollo
2. Aceptamos que los requisitos cambien, incluso en sostenible. Los patrocinadores,
etapas tardías del desarrollo. Los procesos Ágiles desarrolladores y usuarios deben ser capaces
aprovechan el cambio para proporcionar ventaja de mantener un ritmo constante de forma
competitiva al cliente. indefinida.
3. Entregamos software funcional frecuentemente, 9. La atención continua a la excelencia técnica y
entre dos semanas y dos meses, de preferencia al al buen diseño mejora la agilidad.
menor tiempo posible. 10. La simplicidad, o el arte de maximizar la
4. Los responsables de negocio y los desarrolladores cantidad de trabajo no realizado, es esencial.
deben trabajar juntos de forma cotidiana durante 11. Las mejores arquitecturas, requisitos y diseños
todo el proyecto. emergen de equipos autoorganizados.
5. Los proyectos se desarrollan en torno a individuos 12. A intervalos regulares el equipo reflexiona
motivados. Hay que darles el entorno y el apoyo sobre cómo ser más eficaz para después
que necesitan, y confiarles la ejecución del ajustar y perfeccionar su comportamiento
trabajo. según corresponda.
6. El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.
SCRUM
Framework de la Guía SBOK™
La Guía SBOK™ está ampliamente dividida en tres áreas: principios, procesos y aspectos
6
Principios
5
Aspectos
5 Fases
19 Procesos
14 SCRUM
6 Principios de Scrum
6
1
2
5
4 3
15 SCRUM
5 Aspectos de Scrum
Justificación
Organización Calidad Cambio Riesgo
del negocio
1 2 3 4 5
Los aspectos de Scrum deben ser abordados y administrados a lo largo de un proyecto Scrum.
Este tema se abordará después con mayor detalle. SCRUM

16
5 Fases y 19 procesos de Scrum
Tabla 1-1: Resumen de los procesos fundamentales de Scrum. Guía SBOK, página 16
Capítulo Fase Procesos fundamentales de Scrum
1. Crear la visión del proyecto
2. Identificar al Scrum Master y Stakeholder(s)
Este tema se abordará después con mayor detalle.
3. Formar Equipos Scrum

8 Inicio
4. Desarrollar épica(s)
5. Crear el Backlog Priorizado del Producto
6. Realizar la planificación de lanzamiento
1. Crear historias de usuario

2. Estimar historias de usuario
3. Comprometer historias de usuario
9 Planificación y estimación
4. Identificar tareas
5. Estimar tareas
6. Crear el Sprint Backlog
1. Crear entregables
10 Implementación 2. Realizar Daily Standup
3. Refinar el Backlog Priorizado del Producto
1. Demostrar y validar el sprint

11 Revisión y retrospectiva
2. Retrospectiva del sprint
1. Enviar entregables
12 Lanzamiento
2. Retrospectiva del proyecto
Los procesos de Scrum abordan las actividades específicas y el flujo de un proyecto de Scrum. En total hay diecinueve
procesos fundamentales de Scrum que aplican a todos los proyectos. Estos procesos se agrupan en cinco fases.
17 SCRUM
Flujo de Scrum
Reunión de Diariamente
planificación del
lanzamiento Crear
Cronograma de entregables
lanzamiento
Sprint
1 a 6 semanas
Caso de Declaración de Backlog Priorizado Sprint Entregables

negocio del la visión del del Producto Backlog aceptados
proyecto proyecto Reunión de planificación del Reunión de revisión del sprint
sprint Reunión de retrospectiva del sprint
Reunión de la visión del
proyecto
SCRUM
2. Principios de Scrum
SCRUM
Principios de Scrum
Deben cumplirse.
No están abiertos a la discusión

6 ni pueden modificarse.
1
2
5
4 3
20 SCRUM
Principios de Scrum
1. Control de proceso empírico
Transparencia
Decisones Inspección
basadas
en: Adaptación
21 SCRUM
Principios de Scrum
2. Auto-organización
Los empleados se auto-motivan y aceptan más responsabilidades.
Liderazgo servicial que hace énfasis en el logro de resultados enfocándose

en las necesidades del Equipo Scrum.
22 SCRUM
Principios de Scrum
3. Colaboración
Equipo Principal de Scrum interactúa con
los stakeholders (involucrados) para
crear y validar resultados.
Cooperación. El trabajo Colaboración. Aprovechar el
consiste en la suma del aporte de cada uno y
esfuerzo individual. producir algo más grande.
Dimensiones 1) Conocimiento: estar al tanto del trabajo de los demás.
centrales del 2) Articulación: dividir el trabajo los miembros del equipo y

trabajo después reintegrarlo cuando el trabajo esté hecho.
colaborativo 3) Apropiación: Usar la tecnología (plataformas y sistemas),

herramientas y procesos para contribuir a los resultados del
proyectos de manera colaborativa.
23 SCRUM
Principios de Scrum - Colaboración
Importante que los miembros del equipo estén co-ubicados
(del inglés co-location), para interacción formal e informal.
Beneficios
• Las preguntas se
contestan rápidamente.
• Los problemas se
solucionan en ese
momento.
• Existe menor fricción
entre las interacciones.
• La confianza se gana con
mucha más rapidez.
24 SCRUM
Co-ubicación
SCRUM
Principios de Scrum
4. Priorización basada en valor
Se prioriza lo que genera más valor primero.
Entregar un producto o servicio valioso para el

cliente en forma oportuna y continua.
26 SCRUM
Principio de Scrum
5. Time-boxing
Time-boxing -
o asignación
de un bloque
de tiempo
Fijación de una
cierta cantidad
de tiempo
para cada
proceso y
actividad..
27 SCRUM
Principios de Scrum
6. Desarrollo iterativo
El cliente tal vez no pueda definir
requisitos muy concretos o pudiera
no estar seguro sobre cómo
debería de ser el producto final.
El modelo iterativo es más flexible

para asegurar que cualquier
cambio que solicite el cliente se
pueda incluir.
Beneficio. Permite la
corrección al incorporar lo
aprendido de manera
iterativa.
28 SCRUM
3. Aspectos de Scrum
SCRUM
Aspectos de Scrum
Justificación
Organización Calidad Cambio Riesgo
del negocio
1 2 3 4 5
30 SCRUM
Aspectos de Scrum
1. Organización
Es muy importante entender los roles y responsabilidades en un proyectos
Scrum a fin de asegurar su implementación exitosa.
Los roles de Scrum se dividen en dos amplias categorías:
Roles centrales Roles no centrales

• Product Owner • Stakeholders
• Scrum Master • Clientes
• Equipo Scrum • Ususarios
• Patrocinador
• Scrum Guidance Body
• Vendedores
31 SCRUM
1. Organización –
3 Roles centrales = equipo principal
PRODUCT OWNER SCRUM MASTER EQUIPO SCRUM
Representa a los interesados El “líder servicial” del Equipo Responsable de desarrollar el

(stakeholders). Scrum. producto, servicio u otro
resultado.
Responsable de asegurar que el Como coach y motivador, modera
Equipo Scrum entregue valor. y facilita las interacciones del Integrado por un grupo de 6 a 10
equipo. personas para crear los
Escribe los requisitos del negocio entregables del proyecto.
(historias de usuario) con las Responsable de asegurar que el
equipo cuente con un ambiente Son generalistas/ especialistas.
Administra el Backlog Priorizado laboral productivo, protegiéndolo
del Producto. de influencias externas, Son independientes, auto-
eliminando obstáculos y motivados, se enfocan en el
Se le conoce como la “voz del asegurando que se cumplan los cliente y tienen un alto sentido de
cliente”. principios, aspectos y procesos de responsabilidad y colaboración.
Scrum.
Importante es la creación de
substitutos.
32 SCRUM
Liderazgo servicial - Características
Scrum sostiene que el Scrum Master debe ser un líder servicial con las siguientes
características:
1. Escucha
2. Empatía
3. Reparación
4. Conocimiento
5. Persuasión
6. Previsión
7. Gestión
8. Compromiso con el crecimiento de los demás
9. Desarrollo comunitario
SCRUM
Teorías populares de recursos humanos:
Modelo de dinámica de grupo de Tuckman
Figura 3-5: Etapas de Tuckman de desarrollo de grupos. SBOK, p. 57
SCRUM
Teorías populares de recursos humanos:
Modelo de dinámica de grupo de Tuckman
Las cuatro etapas del modelo son las siguientes:
1. Formación (Forming): Esto a menudo se experimenta como un escenario ameno, ya

que todo es nuevo y el equipo aún no ha encontrado ninguna dificultad con el
proyecto.
2. Enfrentamiento (Storming): Durante esta etapa, el equipo trata de cumplir con el

trabajo; sin embargo, puede encontrar conflictos de poder y, con frecuencia, existe
un caos o confusión entre los miembros del equipo.
3. Normalización (Norming): Esto es cuando el equipo empieza a madurar, resolver sus

diferencias internas, y encontrar soluciones para así trabajar juntos. Se considera un
período de ajuste.
4. Desempeño (Performing): Durante esta etapa, el equipo está unido y opera en su

nivel más alto en términos de rendimiento. Los miembros se han convertido en un
equipo eficiente de profesionales que son consistentemente productivos.
SCRUM
Aspectos de Scrum
2. Justificación del negocio
Entrega basada en valor (Value-driven Delivery).
• Entender lo que agrega valor a los clientes y

usuarios y dar prioridades en el Backlog 1. Evaluar y presentar
Priorizado del Producto. un caso de negocio
• Crear entregables basados en las prioridades 2. Justificación

determinadas por la producción de continua de valor
incrementos del producto potencialmente
entregables durante cada sprint. 3. Confirmar la
realización de
• Los clientes empiezan a ver el valor desde el beneficios
principio del proyecto.
36 SCRUM
Aspectos de Scrum
3. Calidad
Calidad: capacidad con la
que cuenta un producto
terminado o los
entregables para cumplir
con los criterios de
aceptación y lograr el
valor del negocio que
espera el cliente.
Mejora continua.
Durante los sprints, los

errores o defectos se
detectan durante las
pruebas de calidad
repetitivas y no cuando el
producto final o servicio
está casi terminado.
SCRUM
Aspectos de Scrum
4.Cambio
Scrum está diseñado para aceptar el

cambio.
Las organizaciones deben tratar de

maximizar los beneficios que se derivan
de los cambios y disminuir los impactos
negativos.
Ningún cambio se introduce hasta que se

termina el sprint, a menos que un cambio
se considere lo suficientemente
importante.
38 SCRUM
Cambio – Proceso de aprobación de cambios
Figura 6-1: Ejemplo del proceso de aprobación de cambios. SBOK, página 101
39 SCRUM
Cambio – Integración del cambio en Scrum
Figura 6-6: Integración del cambio en Scrum. SBOK, página 109

40 SCRUM
Aspectos de Scrum
5. Riesgo
El riesgo se define como un evento incierto o serie de eventos que
pueden afectar los objetivos de un proyecto y pueden contribuir a
su éxito o fracaso.
Riesgos positivos– Oportunidades
Reisgos negativos– Amenazas
Riesgos son las incertidumbres relacionadas a un proyecto.
Los problemas son certezas que se están suscitando en el proyecto.
Si no se atienden a tiempo los riesgos, estos podrían convertirse en

problemas.
41 SCRUM
Diferencia entre riesgos y problemas
Ejemplos de riesgos:
• Incluso después de una amplia capacitación, es posible que los

representantes de servicio al cliente no estén listos para tomar pedidos
el día oficial del lanzamiento.
• Es posible que una cuadrilla de pintores se retrase debido a las fuertes

lluvias, lo cual pudiera influir negativamente en el cronograma del
proyecto.
Ejemplos de problemas:
• No se autoriza el financiamiento.
• Los requisitos no están claros.
SCRUM
Procedimiento de gestión de riesgos
5.
1. Identifica 2. Evaluar 3. Priorizar 4. Mitigar
Comunicar
• Equipo de Probabilidad Backlog Respuestas son Constantemente

proyecto Priorizado del proactivas o a los
Proximidad Producto del reactivas satakeholders
• Continuamente riesgo ajustado
Impacto
• Daily Standup
Meeting
SCRUM
Proceso de priorización de riesgos
Figura 7-4: Proceso de priorización de riesgos. SBOK, página 128
44 SCRUM
4. Fases y procesos de Scrum
SCRUM
5 Fases y 19 procesos de Scrum
Capítulo Fase Procesos fundamentales de Scrum
1. Crear la visión del proyecto

2. Identificar al Scrum Master y Stakeholder(s)
3. Formar Equipos Scrum
8 Inicio
4. Desarrollar épica(s)
5. Crear el Backlog Priorizado del Producto
6. Realizar la planificación de lanzamiento
1. Crear historias de usuario

2. Estimar historias de usuario
3. Comprometer historias de usuario
9 Planificación y estimación
4. Identificar tareas
5. Estimar tareas
6. Crear el Sprint Backlog
1. Crear entregables
10 Implementación 2. Realizar Daily Standup
3. Refinar el Backlog Priorizado del Producto
1. Demostrar y validar el sprint

11 Revisión y retrospectiva
2. Retrospectiva del sprint
1. Enviar entregables
12 Lanzamiento
2. Retrospectiva del proyecto
Tabla 1-1: Resumen de los procesos fundamentales de Scrum. SBOK, p. 15
46 SCRUM
Flujo de Scrum
Reunión de Diariamente
planificación del
lanzamiento Crear
Cronograma de entregables
lanzamiento
Sprint
1 a 6 semanas
Caso de Declaración de Backlog Priorizado Sprint Entregables

negocio del la visión del del Producto Backlog aceptados
proyecto proyecto Reunión de planificación del Reunión de revisión del sprint
sprint Reunión de retrospectiva del sprint
Reunión de la visión del
proyecto
SCRUM
Fase de Scrum: Inicio
Figura 8-2: Resumen de la fase de inicio; SBOK, página 140

SCRUM
Inicio – Crear la visión del proyecto
Figura 8-3: Crear la visión del proyecto – Entradas, herramientas y salidas. SBOK, p. 141
49 SCRUM
Crear la visión del proyecto:
Entrada importante – Caso de negocio
Un caso de negocio, o Business Case, puede ser un documento bien estructurado

o simplemente una declaración verbal que expresa la razón para iniciar un
proyecto.
A menudo incluye información sustancial sobre los antecedentes del proyecto, los
objetivos del negocio y los resultados deseados, un reporte de análisis FODA y de
brecha, una lista de los riesgos identificados y las estimaciones de tiempo,
esfuerzo y costo.
El proyecto se inicia con la presentación del caso de negocio del proyecto. Un caso
de negocio se le presenta a los stakeholders y patrocinadores.
De esta manera, los stakeholders comprenden los beneficios de negocio

esperados de tal proyecto y los patrocinadores confirman que van a proporcionar
los recursos financieros para el proyecto.
SCRUM
Herramienta obligatoria – Reunión de visión del proyecto
Una reunión de visión del proyecto es una reunión con el Product Owner,
el patrocinador y otros stakeholders del proyecto.
Ayuda a identificar el contexto empresarial, los requerimientos de negocio

y las expectativas de los stakeholders a fin de desarrollar una declaración
de la visión del proyecto eficaz.
Scrum cree en la participación y colaboración cercana con todos los

representantes de las empresas para obtener su sentido de compromiso
con el proyecto y para ofrecer un valor más significativo.
SCRUM
Salida importante – Product Owner identificado
El Product Owner es la persona responsable de lograr el máximo valor

empresarial para el proyecto.
También está a cargo de la articulación de requerimientos por parte de

los clientes y de mantener la justificación del negocio para el proyecto.
El Product Owner representa la voz del cliente.
SCRUM
Salida importante – Declaración de la visión del proyecto
Una buena visión del proyecto explica las necesidades empresariales que
el proyecto busca cumplir en vez de cómo habrá cumplir con la necesidad.
La declaración de la visión del proyecto (Project Vision Statement) no

debe ser demasiado específica y debe dejar espacio a la flexibilidad.
Es posible que el conocimiento actual sobre el proyecto esté basado en

suposiciones cambien conforme avanza el proyecto, por lo que es
importante que la visión del proyecto sea lo suficientemente flexible
como para adaptarse a estos cambios.
La visión del proyecto debe centrarse en el problema y no en la solución.
SCRUM
Estudio de caso: VMfoods
• VMfoods es una cadena nacional de supermercados de 10 años de antigüedad

con cerca de 100 sucursales. Recientemente, los gerentes se percataron de
que sus clientes llevan un acelerado estilo de vida y no viajan largas distancias
para hacer sus compras de supermercado. Consideran también que debido a
que estas compras no son complicadas (y ya que VMfoods ofrece siempre
productos de alta calidad), la mejor forma de aumentar su cuota de mercado
sería entregando productos a domicilio.
• En este sentido, un representante se ha puesto en contacto con su equipo a

nombre de VMfoods para crear un sitio web donde los clientes puedan
preparar sus pedidos de entrega en línea y hacer los pagos por ese mismo
medio.
• Durante la reunión de visión del proyecto, un representante de la empresa le

da a usted la visión y los requerimientos genéricos.
SCRUM
Plantilla para la visión del proyecto
PARA - Usuario
QUIÉN - Persona
EL – Nombre del producto
QUE – Servicio proporcionado
A DIFERENCIA DE – La competencia
NUESTRO PRODUCTO –¿Qué hace el producto?
SCRUM
Caso de estudio de VMfoods – Visión del
proyecto
Por favor elabore una declaración de visión para la empresa VMfoods.
PARA
QUIEN
EL
QUE
A DIFERENCIA DE
NUESTRO PRODUCTO
SCRUM
VMfoods – Plantilla para la visión del
proyecto
PARA – Clientes del supermercado
QUIEN – Clientes llevan un acelerado estilo de vida y no viajan largas distancias

para hacer sus compras de supermercado.
EL – Servicio de entrega de productos de supermercado a domicilio
QUE – Entrega de productos de supermercado de alta calidad a tu domicilio
A DIFERENCIA DE – Food Mart, etc.
NUESTRO PRODUCTO – Permite ordenar fácilmente y garantiza la entrega en 24

horas.
SCRUM
Identificar al Scrum Master y stakeholder(s)
Figura 8-6: Identificar al Scrum Master y stakeholder(s)—Entradas, herramientas y salidas. SBOK, p. 148
SCRUM
Entrada importante – Product Owner
El Product Owner ayuda en la selección del Scrum Master.
El Scrum Master ayuda al Product Owner a lograr la visión del proyecto al

ser un líder facilitador y mentor del Equipo Scrum.
Es importante seleccionar a un Scrum Master que esté comprometido(a)

con garantizar que el Equipo Scrum cuente con un ambiente propicio para
la entrega exitosa del proyecto.
Es importante identificar a los stakeholders en el proyecto (tales como el

patrocinador, los usuarios finales, los proveedores, etc.) que tendrán la
necesidad del negocio o ayudarán a cumplirlo.
SCRUM
Herramienta importante – Criterios de selección
En algunos proyectos puede haber condiciones previas que estipulen a determinados

miembros del equipo y sus roles. Cuando hay flexibilidad en la selección del(los) Scrum
Master(s), se deben considerar los siguientes criterios de selección:
Habilidades para resolver problemas – Es uno de los principales criterios a considerar al

seleccionar al(los) Scrum Master(s). El(los) Scrum Master(s) debe(n) tener las habilidades
y la experiencia necesarias para ayudar a eliminar cualquier impedimento que enfrente el
Equipo Scrum.
Disponibilidad – El Scrum Master debe estar disponible para programar, supervisar y

organizar varias reuniones, incluyendo la reunión de planificación de del lanzamiento, el
Daily Standup y otras reuniones relacionadas al sprint.
Compromiso – El Scrum Master debe estar muy comprometido a fin de asegurar que el
Equipo Scrum cuente con un ambiente laboral conductivo para garantizar la entrega
exitosa de proyectos Scrum.
Estilo de liderazgo servicial – El Scrum Master debe ser un líder servicial.

SCRUM
Salida importante – Scrum Master identificado
Un Scrum Master es un facilitador y un líder servicial que se asegura de

que el Equipo Scrum cuente con un ambiente propicio para completar
con éxito el proyecto.
El Scrum Master guía, facilita y les enseña prácticas de Scrum a todos los
involucrados en el proyecto; elimina impedimentos que enfrenta el
equipo y se asegura de que se estén siguiendo los procesos de Scrum.
Es responsabilidad del Product Owner identificar al Scrum Master en un

proyecto Scrum.
SCRUM
Salida importante – Stakeholder(s) identificado(s)
Stakeholder(s) que es un término colectivo que incluye a clientes,

usuarios y patrocinadores que con frecuencia interactúan con el equipo
principal de Scrum e influyen en el proyecto durante todo el proceso de
desarrollo de productos.
Los beneficios colectivos que producto el proyecto son para los

stakeholders.
SCRUM
Inicio – Formar el Equipo Scrum
Figura 8-8: Formar el Equipo Scrum—Entradas, herramientas y salidas. SBOK, p. 154
SCRUM
Formar el Equipo Scrum: Entradas importantes
Declaración de la visión del proyecto
Product Owner
Scrum Master
Todos estos se han analizado en las diapositivas anteriores.
El Product Owner y el Scrum Master son importantes para la selección

de los miembros del equipo.
La declaración de la visión del proyecto es importante para identificar

algunas de las habilidades necesarias de los miembros del equipo.
SCRUM
Formar el Equipo Scrum:
Herramientas importantes – Criterios de selección del equipo
Los miembros del Equipo Scrum son generalistas/ especialistas, ya que cuentan
con conocimiento en diversos campos y son expertos en al menos uno.
Más allá de la experiencia en la materia, son las habilidades interpersonales de

cada miembro del equipo lo que determinará el éxito de los equipos auto-
organizados.
Los miembros ideales del Equipo Scrum son independientes, auto-motivados,

se enfocan en el cliente y tienen un alto sentido de responsabilidad y
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.
SCRUM
Formar el Equipo Scrum:
Salida importante – Equipo Scrum identificado
El Equipo Scrum, también conocido como equipo de desarrollo, es un grupo o equipo

de personas responsables de entender los requerimientos especificados por el
Product Owner, la estimación de historias de usuario y la creación definitiva de los
entregables del proyecto.
Los equipos Scrum son interfuncionales y auto-organizados.
El equipo decide la cantidad de trabajo al que se comprometerá en un sprint y

determina la mejor manera de realizar las tareas.
El equipo se compone de miembros interfuncionales que llevan a cabo todo el

trabajo necesario para la creación de entregables potencialmente enviables,
incluyendo el desarrollo, pruebas, garantía de calidad, etc.
La identificación del Equipo Scrum es responsabilidad del Product Owner, por lo

general en consulta con el Scrum Master.
SCRUM
Inicio – Desarrollar épica(s)
Figura 8-10: Desarrollar épica(s)—Entradas, herramientas y salidas. SBOK, p. 160

SCRUM
Inicio – Desarrollar épica(s)
Una “épica” es una historia de usuario amplia y sin refinar que

generalmente es demasiado amplia como para completarse en un solo
sprint.
El Equipo Principal de Scrum empieza a escribir épicas con base en la visión

del proyecto y con la información proporcionada por los stakeholders.
El Product Owner es responsable de crear estas épicas/historias de usuario.
En algunos casos, las épicas son desarrolladas por el Equipo Scrum

consultando con el Product Owner.
SCRUM
Desarrollar épica(s): Entradas importantes
Equipo Principal de Scrum
Ambos se analizaron en diapositivas anteriores.
SCRUM
Desarrollar épica(s):
Herramienta importante – Reuniones de grupo de usuarios
Las reuniones del grupo de usuarios incluyen a stakeholders relevantes

(principalmente usuarios o clientes del producto).
Estos brindan al Equipo Principal de Scrum información de primera mano sobre las
expectativas del usuario.
Esto ayuda a la formulación de los criterios de aceptación para el producto y

proporciona información valiosa para el desarrollo de épicas.
Las reuniones del grupo de usuarios son de vital importancia para evitar e trabajo
costoso que pudiera resultar de la falta de claridad sobre las expectativas y
exigencias.
Estas reuniones también promueven un sentido de compromiso con el proyecto,

así como un entendimiento común entre el equipo principal de Scrum y los
stakeholders relevantes.
SCRUM
Salida importante – Épica(s)
Las é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.
Las épicas son historias de usuario grandes sin refinar en el Backlog Priorizado
del Producto.
Una vez que estas épicas aparecen en el Backlog Priorizado del Producto para
completarse en el próximo sprint, se convierten en historias de usuario más
pequeñas.
Estas historias más pequeñas son generalmente funcionalidades simples,

cortas y fáciles de implementar, o bloques de tareas que deben completarse
en un sprint.
SCRUM
Formato de Historias de usuario/Épica(s)
Como <rol/persona>, debo poder <requisito> a fin de <beneficio>.
SCRUM
Salida importante – Prototipos de usuario
Los prototipos, conocidos en inglés como personas, son personajes ficticios

altamente detallados que representan a la mayoría de los usuarios y demás
stakeholders que pudieran no utilizar directamente el producto final.
Los prototipos se crean para identificar las necesidades de los usuarios.
La creación de prototipos específicos puede ayudar al equipo a entender

mejor a los usuarios y sus necesidades y metas.
Basado en un prototipo, el Product Owner puede priorizar de manera más

efectiva las funciones para crear el Backlog Priorizado del Producto.
SCRUM
Crear un prototipo
Esto implica la asignación de un nombre ficticio y de preferencia una foto

para el personaje, como una fotografía de stock.
El prototipo incluye atributos muy específicos como edad, género, nivel

académico, ambiente, intereses y metas.
También se puede incluir una cita que ilustre las necesidades del prototipo.
En la siguiente diapositiva se incluyen ejemplos de prototipos para un sitio de viajes.
SCRUM
Ejemplos de prototipos de cliente
“Me gustan los sitios web sencillos y

prácticos que me permitan hacer
rápidamente mi itinerario”.
Mateo, 25 años
Ejecutivo de negocios
Vanessa, 39 años
Viajera
“Mi mochila está siempre lista
para salir a explorar el mundo”
Vanessa tiene 39 años de edad y es residente de

San Francisco. Le apasionan los viajes y después Mateo es un consultor de negocios y viaja mucho
de haber tenido una exitosa carrera como alrededor del mundo. Planifica su itinerario durante
abogada, ha decidido disfrutar de dicha pasión. Le los viajes y no le gusta pasar mucho tiempo en sitios
gusta tener opciones disponibles al seleccionar web de viajes. Necesita acceso práctico a vuelos y
sus viajes por avión y servicios de alojamiento hospedaje en los lugares que visita frecuentemente.
para poder elegir el mejor a un precio accesible.
Se frustra con los sitios web lentos y
desordenados.
SCRUM
Inicio – Crear el Backlog Priorizado del Producto
Figura 8-12: Crear el Backlog Priorizado del Producto—Entradas, herramientas y salidas. SBOK, p. 168
SCRUM
Inicio – Crear el Backlog Priorizado del Producto
El Product Backlog es una lista de requisitos que, al convertirse en

funcionalidades de producto potencialmente enviable, materializará la
visión del proyecto.
Se prioriza a fin de que los elementos más valiosos (los que ofrecen el
máximo valor de negocio) tengan una mayor prioridad.
El Product Owner tiene la responsabilidad de presentar el backlog inicial.
El Backlog Priorizado del Producto generalmente incluye épicas e historias

de usuario, aunque en ocasiones también incluye información sobre
descubrimientos clave: errores reportados, requisitos funcionales y no
funcionales, etc.
SCRUM
Crear el Backlog Priorizado del Producto:
Entradas importantes
Épica(s)
Prototipos
Todos estos temas ya fueron analizados anteriormente.
SCRUM
Crear el Backlog Priorizado del Producto
Herramientas importantes:
Métodos de priorización de las historias de usuarios
Ejemplos de métodos de priorización
• Esquema de priorización MoSCoW
• Comparación por partes
• Método de los 100 puntos
SCRUM
Salida obligatoria: Backlog Priorizado del Producto
El Product Owner desarrolla un Backlog Priorizado del Producto que contiene

una lista priorizada de los requerimientos del negocio y de los proyectos
escritos en forma de épica(s), que son historias de usuario de alto nivel.
El Backlog Priorizado del Producto se basa en tres factores principales: valor,

riesgo o incertidumbre y dependencias.
También se le conoce como Backlog Priorizado del Producto del riesgo ajustado,
ya que incluye riesgos identificados y evaluados relacionados al proyecto.
También incluye cambios aprobados que pueden ser priorizados

adecuadamente en el Backlog Priorizado del Producto
SCRUM
Salida importante: Criterios de terminado
Los criterios de terminado son un conjunto de reglas que se aplican a todas las
historias de usuarios.
Es importante contar con una definición clara de terminado, ya que elimina la

ambigüedad de los requisitos y ayuda a que el equipo se apegue a las normas
obligatorias de calidad.
Esta clara definición se utiliza para crear los criterios de terminado, que son un
resultado del proceso de Crear el Backlog Priorizado del Producto.
Una historia de usuario se considera terminada cuando se demuestra al Product

Owner y es aprobada por este, quien juzga con base a los criterios de terminado
y a los criterios de aceptación de las historias de usuario.
SCRUM
Definición de “terminado”
Mientras que los criterios de aceptación son únicos para en las historias de
usuario individuales, los criterios de terminado son una serie de reglas
aplicables a todas las historias de usuario en un determinado sprint.
Al igual que con los criterios de aceptación, se deben cumplir todas las
condiciones de los criterios de terminado para que la historia de usuario se
considere terminada.
El Equipo Scrum debe utilizar una checklist (lista de verificación) de los

criterios de terminado generales para garantizar que una tarea está
terminada y de que el resultado cumpla con la con la definición de
terminado.
82 SCRUM
Criterios de terminado - Ejemplos
• Revisión por todos los miembros del equipo

• Hacer pruebas unitarias de las historias de usuario
• Hacer pruebas de garantías de calidad
• Completar toda la documentación relacionada a la historia
de usuario
• Todos los problemas han sido corregidos
• Demostración exitosa a los stakeholder y/o representantes
del negocio
83 SCRUM
Estudio de caso
Crear un prototipo en el primer Product Backlog
David; 28 años, profesionista en ventas
David es un profesionista en ventas que trabaja muchas horas en una tienda y

dispone de muy poco tiempo para hacer sus compras de supermercado. Prefiere
hacer el pedido en línea. Normalmente hace el mismo pedido y por lo tanto
prefiere la opción de repetir sus pedidos sin necesidad de especificar nuevamente
su domicilio y detalles de pago. Para David, la rapidez en lo que más le interesa
cuando se trata de hacer pedidos en línea.
SCRUM
Estudio de caso
Sue; 25 años, ejecutiva en logística
Sue trabaja para VMfoods y pronto estará a cargo de administrar la entrega a

tiempo de las compras de supermercado. Espera muchos pedidos en el sitio de
VMfoods; no le gusta estar cambiando de sistemas para administrar los
pedidos, ya que existe la posibilidad de pasar por alto detalles importantes.
Sue prefiere un sistema que le muestre un resumen de todos los pedidos y
estado actual con un solo clic.
SCRUM
Pregunta de estudio de caso
Desarrolle dos personajes (prototipos) para el estudio de

caso de VMfoods con base en las imágenes proporcionadas.
Si tiene preguntas adicionales sobre este tema, por favor escríbalas

en la venta de preguntas.
86 SCRUM
Estudio de caso
Crear épicas de un primer Product Backlog
Épica 1 – Como usuario (David), quiero tener la posibilidad de iniciar sesión en

mi cuenta para poder verificar mi historial.
Épica 2 – Como usuario (David), quiero tener la posibilidad de hacer compras

en línea para no tener que hacerlas en la tienda.
Épica 3 – Como usuario (David), quiero tener la posibilidad de buscar

productos fácilmente y contar con un carrito de compras para seleccionar los
artículos de compra a fin de no tener que buscarlos constantemente.
SCRUM
Pregunta – Estudio de caso
Elabore dos épicas adicionales de VMfoods.

88 SCRUM
Estudio de caso
Crear épicas de un primer Product Backlog
Épica - Como usuario (David), quiero la posibilidad de guardar los artículos en la opción
de “Guardar” del carrito de compras para que queden almacenados para futuras visitas.
Épica - Como usuario (Sue), quiero tener la posibilidad de ver cuántos pedidos están en
proceso para poder programar su entrega.
Épica - Como usuario (David), quiero tener la posibilidad de ver los productos más
vendidos en la página de inicio para no perder tiempo buscando esos productos.
Épica - Como usuario (Sue), quiero tener la posibilidad de clasificar los pedidos por fecha
de entrega para poder organizar las entregas debidamente.
Épica - Como usuario (David), quiero tener la posibilidad de separar las páginas en cada
categoría para facilitar la búsqueda de productos.
Épica - Como usuario (Sue), quiero tener la posibilidad de encontrar órdenes cuya entrega
es más tardada a fin de priorizar su entrega.
SCRUM
Problemas al crear un Product Backlog
Los miembros del equipo no están de acuerdo

con las prioridades del Product Owner.
¿Qué debería usted hacer como Scrum Master?

90 SCRUM
Problemas al crear un Product Backlog
Un elemento del Product Backlog no está bien definido.

¿Qué debería usted hacer como Scrum Master?

91 SCRUM
Inicio – Realizar la planificación del lanzamiento
Figura 8-14: Realizar la planificación del lanzamiento—Entrada, herramientas y salidas. SBOK, p. 175
SCRUM
Inicio – Realizar la planificación del lanzamiento
El Equipo Principal de Scrum trabaja en la creación de un cronograma de planificación

del lanzamiento para entregar los incrementos del producto a los stakeholders.
El cronograma de planificación del lanzamiento indica cuáles entregables deben ser

entregados al cliente, así como los intervalos planificados y las fechas de entrega.
El cronograma de planificación del lanzamiento se basa en varias entradas,

incluyendo las opiniones de los stakeholders, la declaración de la visión del proyecto,
el Backlog Priorizado del Producto, los requisitos del negocio y el calendario de días
festivos.
En este proceso también se establece la duración del sprint.
Cada sprint debe tener como resultado una funcionalidad potencialmente enviable;
sin embargo, la fecha en la que el entregable del sprint debe ser presentado al
stakeholder, se define en el cronograma de planificación del lanzamiento.
SCRUM
Realizar la planificación del lanzamiento
Stakeholder(s)
Priorizado del Producto
Criterios de terminado
SCRUM
Herramientas importantes: Sesiones de planificación del lanzamiento
Las sesiones de planificación del lanzamiento se llevan a cabo para desarrollar un

plan del lanzamiento.
Dicho plan define cuándo las distintas series de funcionalidades útiles serán
entregadas al cliente.
En Scrum, el objetivo principal de una sesión de planificación de lanzamiento es

hacer que el Equipo Scrum cuente con una visión general de los lanzamientos y
del calendario de entrega del producto que están desarrollando para que puedan
alinearse con las expectativas del Product Owner y los stakeholders relevantes
(principalmente el patrocinador o Project Sponsor).
Algunas organizaciones prefieren un despliegue continuo, donde se produce un

lanzamiento después de la creación de la funcionalidad útil especificada. Otras
organizaciones prefieren un despliegue por etapas, donde los lanzamientos se
hacen en intervalos predefinidos.
SCRUM
Herramientas importantes: Métodos de priorización del lanzamiento
Los métodos de priorización del lanzamiento se utilizan para desarrollar

un plan del lanzamiento.
Estos métodos son específicos a la industria y organización, y

generalmente son determinados por la alta gerencia de la organización.
SCRUM
Herramientas importantes: Cronograma de planificación del lanzamiento
Un cronograma de planificación del lanzamiento indica cuáles entregables serán

entregados al cliente, así como los intervalos planificados y fechas para los
lanzamientos.
Tal vez no exista un lanzamiento programado al final de cada iteración del sprint.
En ocasiones, un lanzamiento puede planificarse después de completar un grupo de

iteraciones del sprint.
Dependiendo de la estrategia de la organización, las sesiones de la planificación del

lanzamiento en los proyectos pueden estar guiadas por la funcionalidad donde el
objetivo es la entrega una vez que se ha desarrollado un conjunto predeterminado de
funcionalidades, o bien, la planificación puede estar impulsada por la fecha, donde el
lanzamiento se da en una fecha predefinida.
El entregable de debe lanzar cuando ofrezca suficiente valor empresarial para el cliente.
SCRUM
Salidas importantes: Duración del sprint
El Product Owner y el Equipo Scrum deciden la duración del sprint para el

proyecto.
Una vez determinada, la duración del sprint generalmente permanece igual

durante el proyecto.
A principios del proyecto se puede seguir dando la experimentación para

encontrar la mejor duración del sprint.
Si más adelante en el proyecto hay un cambio en la duración del sprint,

normalmente significa que se puede reducir debido a mejoras en el entorno del
proyecto.
Un sprint pudiera tener a un time-box de una a seis semanas.
SCRUM
Impacto de un cambio esperado en la duración del sprint
Si los requisitos del proyecto son generalmente estables y no se esperan

cambios a corto plazo, la duración del sprint puede ser más prolongada
(4 a 6 semanas).
Si los requisitos de un proyecto no están bien definidos, o si se esperan

cambios considerable a mediano plazo, la duración del sprint puede ser
relativamente corta (de 1 a 3 semanas).
Para lograr los máximos beneficios de un proyecto Scrum, se recomienda

mantener el sprint con un Time-box de 4 semanas o menos, a menos
que los requisitos del proyecto sean muy estables donde el sprint se
pueda extender hasta 6 semanas.
99 SCRUM
Impacto de un cambio esperado en la duración del sprint
Figura 6-7: Impacto del cambio esperado en la duración del sprint. SBOK, p. 111
100 SCRUM
Impacto de otros factores en la duración del sprint
Otros factores que también deben tomarse en cuenta son:
• El tiempo real para realizar su trabajo (si el proyecto o entorno corporativo

necesita un tiempo específico para realizar tareas de forma, eso podría
determinar la duración del sprint).
• La fecha prevista para su lanzamiento (la duración del sprint debe tener en
cuenta las fechas de lanzamiento para el producto o el servicio en general).
• Cualquier otro factor que determine el Product Owner o el Scrum Master que
deben tenerse en cuenta al determinar la duración del sprint
101 SCRUM
Fase de Scrum: Planificación y estimación
Figura 9-2: Resumen de la Planificación y Estimación (Esenciales). SBOK, p. 186
102 SCRUM
Planificación y estimación – Crear historias de
usuario
Figura 9-3: Crear historias de usuario—Entradas, herramientas y salidas. SBOK, p. 187
SCRUM
Crear historias de usuario: Entradas importantes
Backlog Priorizado del Producto
Prototipos
SCRUM
Crear historias de usuario: Herramientas importantes
Experiencia en la redacción de historias de usuario
El Product Owner —con base en su interacción con los stakeholders, en su

conocimiento del negocio, en la experiencia y en las aportaciones del equipo—,
desarrolla las historias de usuario que habrán de formar la Backlog Priorizado del
Producto inicial para el proyecto.
El Backlog Priorizado del Producto representa la suma total de lo que debe

completarse en el proyecto.
El objetivo de este ejercicio es crear historias de usuario elaboradas y refinadas que

pudieran ser estimadas y comprometidas por el Equipo Scrum.
En ocasiones, el Product Owner pudiera incluir a un analista empresarial para que

ayude en la redacción de historias de usuario.
Aunque el Product Owner tiene la principal responsabilidad de escribir las historias

de usuario y generalmente lleva a cabo esta actividad por sí mismo, se puede
también llevar a cabo un taller de redacción de historias de usuario si así se desea.
SCRUM
Crear historias de usuario: Salidas importantes
Historias de usuario
Las historias de usuario se apegan a una estructura específica predefinida y

son una forma simple de documentar los requerimientos y funcionalidades
que desea el usuario final.
Una historia de usuario incluye tres elementos sobre el requerimiento:

¿Quién? ¿Qué? y ¿Por qué?
El formato estándar predefinido da como resultado en una comunicación

mejorada entre los stakeholders, así como en mejores estimaciones por parte
del equipo.
El Backlog Priorizado del Producto es una lista dinámica que se actualiza

constantemente debido a la re-priorización de historias de usuarios nuevas,
actualizadas, refinadas y en ocasiones eliminadas.
SCRUM
Planificación y estimación – Crear historias de usuario
Como <rol/persona>, debo poder <requisito> a fin de <beneficio>.
• Como administrador de una base de datos, debo contar con la capacidad de revertir
una cantidad selecta de actualización de la base de datos a fin de que se restablezca
a la versión deseada.
• Como desarrollador web, debo poder rastrear los datos del usuario mediante su
información usuario a fin de poder personalizar ofertas de productos y servicios
para los visitantes.
• Como cliente, debo contar con la posibilidad de iniciar sesión como invitado para
poder ver las ofertas sin necesidad de registrarme cuando no disponga de tiempo.
SCRUM
Crear historias de usuario: Salidas importantes
Criterios de aceptación de historias de usuario
Cada historia de usuario cuenta con sus respectivos criterios de aceptación.
Las historias de usuario son subjetivas de tal forma que los criterios de aceptación
brindan la objetividad requerida para que las historias de usuario se consideren
terminadas o no terminadas durante la revisión del sprint.
Los criterios de aceptación brindan claridad al equipo respecto a los que se espera en
una historia de usuario; eliminan la ambigüedad de los requerimientos, ayudando a la
alineación de las expectativas.
El Product Owner define y comunica los criterios de aceptación al Equipo Scrum.
En las reuniones de revisión del sprint, los criterios de aceptación brindan el contexto
para que el Product Owner decida si la historia de usuario se ha completado
satisfactoriamente.
Es responsabilidad del Scrum Master asegurar que el Product Owner no cambie los
criterios de aceptación de una historia de usuario asignada a mitad de un sprint.
SCRUM
Redacción de criterios de aceptación
Los criterios de aceptación son únicos en cada historia de usuario y no son un

substituto de la lista de requerimientos.
Es importante que el Product Owner tome nota que las historias de usuario que
cumplan con la mayoría, aunque no con todos los criterios de aceptación, no pueden
aceptarse como terminadas.
Los proyectos Scrum operan en sprints con un time-box asignado, con Sprint Backlog
asignado para cada sprint.
Si se les dio crédito a historias de usuario incompletas como si estuvieran terminadas

—y si se llevaron al siguiente sprint—, el progreso de posteriores sprints pudiera
verse interrumpido.
Por lo tanto, el estado de “terminado” es a blanco y negro.
Una historia de usuario puede ser, ya sea “terminada” o “no terminada”.
109 SCRUM
Estudio de caso
Historias de usuario y criterios de aceptación
Épica 1 – Como usuario (David), quiero tener la posibilidad de iniciar sesión en mi

cuenta para tener toda la información importante almacenada para futuro uso.
Historia de usuario – Como usuario (David), me gustaría crear una cuenta para
poder iniciar sesión en mi cuenta.
Criterios de aceptación – La creación de una página de cuenta debe incluir la

creación de cuenta con un correo electrónico, así como con número telefónico.
Historia de usuario – Como desarrollador web, debo poder rastrear los datos del
usuario mediante su información usuario a fin de poder personalizar ofertas de
productos y servicios para los visitantes.
Criterios de aceptación – Cada vez que un usuario inicie sesión, la información debe
ser almacenada en el sistema a fin de poderla obtener si es necesario.
SCRUM
Estudio de caso
Épica 2 – Como usuario (David), quiero tener la posibilidad de hacer compras en

línea para no tener que hacerlas en la tienda.
Historia de usuario – Como cliente, quiero tener distintas modalidades de pago

para elegir la que más me convenga.
Criterios de aceptación – La pasarela de pago debe permitir el pago con tarjeta de

crédito (Visa, MasterCard y Amex), tarjetas de debido y PayPal.
Historia de usuario – Como cliente, quiero tener la posibilidad de ver todos los
artículos y el total de la cuenta en el carrito de compras para poder saber cuánto
debo pagar antes de llegar a la página de pago.
Criterios de aceptación – El carrito de compras debe incluir la suma del total de la

cuenta.
SCRUM
Estudio de caso
Escriba historias de usuario adicionales para las siguientes dos épicas:
Épica 1 – Como usuario (David), quiero tener la posibilidad de iniciar sesión en mi

cuenta para tener toda la información importante almacenada para futuro uso.
Historia de usuario –
Criterios de aceptación –
Épica 1 – Como usuario (David), quiero tener la posibilidad de hacer compras en

línea para no tener que hacerlas en la tienda.
SCRUM
Planificación y estimación
Estimar historias de usuario
Figura 9-5: Estimar historias de usuario—Entradas, herramientas y salidas. SBOK, p. 193
SCRUM
Estimar historias de usuario: Entradas importantes
Historias de usuario
SCRUM
Estimar historias de usuario:
Herramientas importantes – Métodos de estimación
Wideband Delphi
Planning Poker
Estimación por afinidad
SCRUM
Estimar historias de usuario – Planning Poker
SCRUM
Estimar historias de usuario:
Salidas importantes – Historias de usuario estimadas
Se puede utilizar el Relative Sizing o los puntos de historia para estimar el tamaño
general de una historia de usuario o característica.
Este método asigna un valor de punto de historia con base en una evaluación
general del tamaño de una historia de usuario tomando en cuenta el riego, la
cantidad de esfuerzo necesario y el nivel de complejidad.
Esta evaluación la llevará a cabo el Equipo Scrum y se asignará un valor de punto de

historia.
Una vez hecha la evaluación en una historia de usuario en el Backlog Priorizada del
Producto, el Equipo Scrum puede entonces evaluar otras historias de usuario
relativas a esta primera historia.
Debe destacarse que debido a que la calibración del punto de usuario por cada
equipo será diferente, el número de puntos de historia completados pudiera
utilizarse para hacer un comparativo.
SCRUM
Ejercicio de estimación
Ensalada de frutas
El instructor(a) tendrá el rol de Scrum Master y Product Owner. Usted es el Equipo
Scrum.
Caso:
El Product Owner ha comprador varias frutas que deben ser preparadas para servirse
como ensalada de fruta para los invitados.
Se le pide al equipo:
Estimar el esfuerzo relativo para preparar cada una de estas frutas en la ensalada
(utilizando el Planning Poker). En vez de mostrar las cartas, proporcione su estimación en
la ventana del chat.
SCRUM
Planificación y estimación
Comprometer historias de usuario
Figura 9-7: Comprometer tareas—Entradas, herramientas y salidas. SBOK, p. 198
SCRUM
Historias de usuario estimadas
Duración del sprint
SCRUM
Entradas importantes – Velocidad del sprint
La 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 se utilizan para la estimación,
normalmente en puntos de historia o tiempo ideal.
Se lleva un registro de la velocidad del sprint del equipo para cada sprint y se utiliza
como referencia para futuros sprints.
La velocidad del sprint anterior se convierte en el factor más importante para

determinar la cantidad del trabajo a la que se avocará el equipo en un subsecuente
sprint.
Cualquier cambio en la situación o en las condiciones a partir del último sprint, se

toma en cuenta para garantizar un cálculo preciso de la velocidad del sprint para el
siguiente.
SCRUM
Herramientas importantes – Reuniones de planificación de tareas
En las reuniones de planificación de tareas, el Equipo Scrum se reúne para planificar el

trabajo que se hará en el sprint.
El equipo revisa las historias de usuario asignadas que encabezan el Backlog Priorizado
del Producto.
El Product Owner se encuentra presente durante las reuniones en caso de ser necesaria
una aclaración relacionada a las historias de usuario o en las prioridades.
Para ayudar a garantizar que el equipo no se salga del tema, la reunión debe de tener
un time-box con una duración estándar limitada de dos horas por semana de duración
del sprint.
Esto ayuda a prevenir la tendencia de desviarse hacia discusiones que deberían de

realizarse en otras reuniones, tales como en las de planificación del lanzamiento o en
reuniones de revisión del sprint.
Como parte de esta reunión, todo el Equipo Scrum se comprometerá a entregar un

subconjunto de historias de usuario del Backlog Priorizado del Producto en el sprint.
SCRUM
Herramientas importantes – Técnicas de comunicación
Scrum promueve la comunicación precisa y eficaz primordialmente

mediante la co-ubicación de equipos Scrum.
Scrum favorece también las interacciones informales cara a cara en vez

de la comunicación formal por escrito.
Cuando un Equipo Scrum debe estar distribuido geográficamente, el

Scrum Master debe asegurar que existan técnicas eficaces de
comunicación para que los equipos se puedan auto organizar y trabajar
eficientemente.
SCRUM
Salidas importantes – Historias de usuario comprometidas
El Equipo Scrum se compromete a un subconjunto de historias de

usuario estimadas que consideran que se pueden completar en el
siguiente sprint con base en la velocidad.
Las historias de usuario comprometidas se seleccionarán siempre según

las prioridades definidas por el Product Owner.
SCRUM
Planificación y estimación – Identificar tareas
Figura 9-9: Identificar tareas—Entradas, herramientas y salidas. SBOK, p. 201
SCRUM
Identificar tareas: Entradas importantes
Historias de usuario comprometidas
SCRUM
Identificar tareas: Herramientas importantes
Reuniones de planificación del sprint
En las reuniones de planificación del sprint, el Equipo Scrum se reúne para

planear el trabajo a realizar en sprint.
El equipo revisa cada historia de usuario comprometida para el sprint e

identifica actividades accionables o las tareas necesarias para implementar
los entregables necesarios para cumplir totalmente y cumplir los criterios
de aceptación de usuarios de usuario.
El Product Owner se encuentra presente durante esta reunión en caso de

que se necesita una aclaración relacionada a las historias de usuario
comprometidas a fin de ayudar al equipo a tomar decisiones sobre diseño.
SCRUM
Identificar tareas: Salidas importantes
Lista de tareas
Es una lista integral que contiene todas las tareas a las que se ha
comprometido el Equipo Scrum en el actual sprint.
Contiene descripciones de cada tarea, así como las estimaciones obtenidas

durante el proceso de Identificar tareas.
La lista de tareas, o Task List, debe incluir cualquier prueba o actividad de

integración a fin de que el incremento del producto del sprint puede
integrarse con éxito en los entregables de previos sprints.
Aun cuando las tareas generalmente se basan en tareas, el nivel de

granularidad al que se segmentan las tareas lo decide el Equipo Scrum.
SCRUM
Planificación y estimación – Estimar tareas
Figura 9-11: Estimar tareas—Entradas, herramientas y salidas. SBOK, p. 205
SCRUM
Estimar tareas: Entradas importantes
Lista de tareas
SCRUM
Estimar tareas: Herramientas importantes
Criterios de estimación
Los criterios de estimación pueden expresarse de muchas formas. Dos

ejemplos comunes son los puntos de historia y el tiempo ideal.
Los valores de puntos de historia se utilizan para representar el esfuerzo

relativo o comparativo para completar tareas.
El tiempo ideal normalmente describe el número de horas que los

miembros de un Equipo Scrum trabajan exclusivamente en el desarrollo de
los entregables del proyecto sin incluir ningún tiempo dedicado a otras
actividades o a trabajo ajeno al proyecto.
Los criterios de estimación le facilitan al Equipo Scrum estimar el esfuerzo y

le permiten evaluar y atender las ineficiencias cuando es necesario.
SCRUM
Estimar tareas: Herramientas importantes
Métodos de estimación
Los mismos métodos de estimación utilizados para estimar las historias

de usuario se pueden aplicar también a las tareas.
SCRUM
Estimar tareas: Salidas importantes
Effort Estimated Task List
La llamada Effort Estimated Task List (lista de tareas del esfuerzo

estimado) es una lista de tareas asociadas con las historias de usuario
incluidas en un sprint.
El esfuerzo estimado se expresa en términos de los criterios de estimación

acordados por el equipo.
El Equipo Scrum utiliza la Effort Estimated Task List durante las reuniones
de planificación del sprint a fin de crear el Sprint Backlog y el Sprint
Burndown Chart.
Se utiliza también para determinar cuándo el equipo necesita reducir su

compromiso o asumir historias de usuario adicionales durante la
planificación del sprint.
SCRUM
Planificación y estimación – Crear el Sprint
Backlog
Figura 9-13: Crear el Sprint Backlog—Entradas, herramientas y salidas. SBOK, p. 209
SCRUM
Crear el Sprint Backlog: Entradas importantes
Effort Estimated Task List
Duración del sprint
SCRUM
Crear el Sprint Backlog : Herramientas importantes
Reuniones de planificación del sprint
Durante las reuniones de planificación del sprint, el Equipo Scrum se

compromete las historias de usuario para un sprint e identifica y estima las
tareas.
Cada miembro del Equipo Scrum también utiliza la Effort Estimated Task
List para seleccionar las tareas en las que planean trabajar en el sprint con
base en sus habilidades y experiencia.
El Equipo Scrum elabora también el Sprint Backlog y el Sprint Burndown

Chart utilizando las historias de usuario y la lista antes mencionada
durante las reuniones de planificación del sprint.
SCRUM
Crear el Sprint Backlog : Salidas importantes
Sprint Backlog
La lista de tareas que llevará a cabo el Equipo Scrum en el siguiente sprint se
denomina Sprint Backlog.
Es común que el Sprint Backlog esté representado en un Scrumboard o tablero de

tareas, el cual proporciona una constante representación visual del estado de las
historias de usuario en el backlog.
En el Sprint Backlog también se incluye cualquier riesgo asociado a las varias

tareas. Cualquier actividad de mitigación de riesgos para atender los riesgos
identificados también se incluirían como tareas en el Sprint Backlog.
Una vez que el Equipo Scrum finaliza y se compromete al Sprint Backlog no se

deben agregar nuevas historias de usuario; sin embargo, las tareas que pudieron
haberse pasado por alto o ignoradas de las historias de usuario comprometidas
pudieran ser agregadas.
Si durante un sprint surgen nuevos requerimientos, estos serán agregados al

Backlog Priorizado del Producto e incluidos en un futuro sprint.
SCRUM
Crear el Sprint Backlog : Salidas importantes
Sprint Backlog
EQUIPO DEL PROYECTO
SCRUM
Scrumboard - Inicio de un sprint
SCRUM
Crear el Sprint Backlog : Salidas obligatorias
Sprint Burndown Chart
El Sprint Burndown Chart es una gráfica que muestra la cantidad de trabajo

pendiente en el actual sprint.
El Sprint Burndown Chart inicial se acompaña de un Planned Burndown.
El Sprint Burndown Chart debe actualizarse al final de cada día conforme se

concluye el trabajo.
Si el Sprint Burndown Chart muestra que el Equipo Scrum no va por el rumbo

correcto en la conclusión a tiempo del sprint, el Scrum Master debe identificar
cualquier obstáculo o impedimento de una conclusión satisfactoria e intentar
eliminarlos.
Una gráfica relacionada es el Sprint Burnup Chart. A diferencia del Sprint

Burndown Chart —que muestra la cantidad de trabajo pendiente—, el Sprint
Burnup Chart sprint muestra el trabajo concluido como parte del sprint.
SCRUM
Crear el Sprint Backlog : Salidas obligatorias
Puntos de historia
Días
141 SCRUM
Estudio de caso – Sprint #1 Reunión de planificación
Backlog Priorizado del Producto Velocidad: 21

Total
1:N Estimació del
Épica / Descripción de la historia de usuario Prio Prio n Sprint # sprint
Protocolo de seguridad Debe 1 5 1 5
Crear un perfil único de usuario con información de pago Debe 2 8 1 13
Buscar en todo el catálogo Debe 3 5 1 18
Buscar usando filtros (por ej. orgánico, hipoalergénico, etc.). Debe 4 3 1 21

Carrito de compra (agregar/eliminar/cambiar) Debe 5 8 2 8
El sitio debe contar con la funcionalidad de pago seguro Debe 6 8 2 16
Capacidad para programar entregas individuales Debe 7 13 ?? ??
Opciones de pago (distintos tipos de tarjetas de crédito, PayPal, etc.) Debería 8 5 ?? ??
Entregas recurrentes/Fechas de entrega automática Debería 9 5 ?? ??
SCRUM
Estudio de caso – Sprint #1 Reunión de
planificación
Sprint en curso 1 Velocidad: 21
N.º Épica/Descripción de la historia de usuario Prio

1 Capacidad de compra en línea Debe
2 El sitio de compras en línea de VMfood debe contar con la funcionalidad de inicio de sesión en forma segura Debe
3 Búsqueda fácil de productos y carrito de compras para seleccionar los artículos de compra Debe
4 Permitir a los usuarios seleccionar el tiempo de entrega Debe
5 Proporcionar filtros en las compras de supermercado (por ej., orgánico, etc.). Debe
6 Entrega en 24 horas Puede
7 Comprar por tipo de producto Puede
8 Aplicación móvil Podría
SCRUM
planificación
Tareas para: “Crear perfil de usuario con información de pago”
Historia de usuario Lista de tareas
Diseñar página web
Revisar el diseño
Como cliente, quiero
tener acceso a un Crear un wireframe de la página web
perfil único con
información de pago a Demostración del wireframe
fin de ahorrar tiempo
Obtener la aprobación legal de la
cuando haga pedidos
página
varias veces.
Actualizar el manual de usuario
Probar la funcionalidad
SCRUM
planificación
Historias de usuario Por hacer En proceso Terminado
Como cliente, quiero hacer
compras por medio de un
protocolo seguro para que mi Tarea #1 Tarea #2 Tarea #3 Tarea #4
información personal no está
bajo riesgo.
Obtener la
Como cliente, quiero tener Diseñar página aprobación
Revisar el diseño
acceso a un perfil único con web legal de la
información de pago a fin de página
Probar la
ahorrar tiempo cuando haga funcionalidad
Actualizar el
pedidos varias veces. Crear wireframe Demostración
manual de
de la página web del wireframe
usuario
Como cliente, quiero ver todo

el catálogo para conocer bien
todos los productos Tarea #1 Tarea #2 Tarea #3
disponibles.
Como cliente, quiero ver todo

el catálogo para conocer bien
todos los productos Tarea #1 Tarea #2 Tarea #3 Tarea #4
disponibles.
SCRUM
planificación
Puntos de historia
(Planificado)
Días
SCRUM
planificación
Total
1:N Estimació del

La historia de usuario 7 no se ajusta. ¿Qué hacemos?

SCRUM
planificación
Total
1:N Estimació del

Habilidad de programar un tiempo de entrega Debe 7a 5 2 21
Habilidad de cancelar un tiempo de entrega Debe 7b 5 >=3 ??
Habilidad de cambiar un tiempo de entrega Debe 7c 5 >=3 ??
SCRUM
planificación
Contenido del sprint 2 Velocidad: 21
1:N Estimació Sprint

Épica/Descripción de historia de usuario Prio Prio n Sprint # total
El sidio debe tener una funcionalidad de pago seguro Debe 6 8 2 16
Habilidad de programar un tiempo de entrega Debe 7a 5 2 21
SCRUM
Fase de Scrum - Implementación
Figura 10-2: Resumen de la implementación (Esenciales). SBOK, p. 218
150 SCRUM
Fase de Scrum - Implementación
La fase de Implementación incluye la ejecución de tareas y actividades

para crear el producto, servicio o resultado deseado de un proyecto.
Estas actividades incluyen la creación de varios entregables, los Daily

Standups y el refinamiento (revisar, ajustar y actualizar constantemente)
el Backlog Priorizado del Producto en intervalos frecuentes.
SCRUM
Implementación – Crear entregables
Figura 10-3: Crear entregables—Entradas, herramientas y salidas. SBOK, p. 219
152 SCRUM
Implementación – Crear entregables
Es el proceso donde se hace el principal desarrollo.
El Equipo Scrum es responsable de crear los entregables del sprint.
Los stakeholders, el Scrum Master y el Product Owner detallan las

necesidades que deben ser desarrolladas y no cómo desarrollar los
entregables.
El Equipo Scrum anota los impedimentos en el Impediment Log.
SCRUM
Implementación – Cambios a un sprint
Solo hay una excepción a la regla de no modificar el alcance de un

sprint una vez que ha comenzado.
Si el Equipo Scrum determina que se ha sobrestimado en gran medida

el esfuerzo durante el sprint y no tiene capacidad para poner en
práctica historias de usuario adicionales, el equipo puede preguntarle
al Product Owner cuáles historias de usuario deben incorporarse al
sprint actual.
Un beneficio adicional es que el equipo no tiene que preocuparse por

la gestión de los cambios una vez que empieza a trabajar en un sprint.
154 SCRUM
Crear entregables – Entradas importantes
Equipo Principal del Scrum
Sprint Backlog
Scrumboard
Impediment Log
SCRUM
Crear entregables: Entradas importantes
Scrumboard
En Scrum, la transparencia proviene de las herramientas visiblemente abiertas
tales como el Scrumboard, donde se muestra el avance del equipo.
El equipo utiliza un Scrumboard para planificar y dar seguimiento al progreso

durante cada sprint.
El tablero contiene cuatro columnas para indicar el progreso de las tareas

estimadas para el sprint: una columna “por hacer” para las tareas que aún no se
inician; una columna “en progreso” para las tareas que ya iniciaron, pero no se
han concluido; una columna “en prueba” para las tareas concluidas pero que
están en proceso de evaluación y una columna de “terminado” para las tareas
que se han concluido y evaluado satisfactoriamente.
Al principio de cada sprint, todas las tareas se colocan en la columna “por hacer”
y avanzan según su progreso.
SCRUM
Scrumboard
Figura 10-5: Scrumboard. SBOK, p. 220
157 SCRUM
Impediment Log
Un impedimento es cualquier obstáculo o barrera que reduce la

productividad del Equipo Scrum. Los impedimentos deben
identificarse, resolverse y eliminarse si el equipo sigue trabajando
eficazmente.
Los impedimentos pueden ser internos en un equipo, tales como un

flujo de trabajo ineficiente o la falta de comunicación; o bien, pueden
ser externos tales como problemas con licencias de software,
cumplimiento de requisitos legales o gubernamentales, etc.
El Scrum Master debe registrar formalmente los impedimentos en un

Impediment Log
SCRUM
Experiencia del equipo
Hace referencia a la experiencia colectiva de los miembros del Equipo

Scrum para entender las historias de usuario y las tareas en el Sprint
Backlog a fin de crear los entregables finales.
Los miembros del Equipo Scrum cuentan con la autoridad y la

responsabilidad para determinar las mejores formas de convertir los
elementos del Backlog Priorizado del Producto en productos finales, sin
solicitar la participación de ningún stakeholder fuera del equipo.
De ser necesario, el Scrum Guidance Body cuenta con experiencia

disponible.
SCRUM
Crear entregables: Salidas importantes
Entregables del sprint
Al final de cada sprint se completa un incremento de producto o

entregable.
El entregable debe incluir todas las características y funcionalidades

definidas en las historias de usuario que se incluyen en el sprint y
deben haber sido evaluadas satisfactoriamente.
SCRUM
Crear entregables: Salidas importantes
Scrumboard actualizado
El Scrumboard se actualiza con regularidad a medida que el equipo

completa las tareas.
Sin embargo, al final del sprint, el Scrumboard se reinicia o se borra y se

crea un nuevo para el siguiente sprint.
SCRUM
Crear entregables: El uso del Scrumboard
A continuación se muestra un Scrumboard al final del sprint.
¿Fue un sprint bueno, malo o regular? ¿Qué opina?
Escriba su respuesta en la ventana de preguntas.
SCRUM
Crear entregables: El uso del Scrumboard
A continuación se muestra un Scrumboard al final del sprint.
¿Es mejor, peor o igual? ¿Por qué?
Escriba su respuesta en la ventana de preguntas.
SCRUM
Implementación – Realizar el Daily Standup
Figura 10-6: Realizar el Daily Standup—Entradas, herramientas y salidas. SBOK, p. 225
164 SCRUM
Implementación – Realizar el Daily Standup
Diariamente se lleva a cabo una reunión altamente focalizada y con

límite de tiempo (Time-box) denominada Daily Standup.
Es un foro donde el Equipo Scrum se pone al día sobre su avance y

cualquier impedimento que estén enfrentando.
SCRUM
Realizar el Daily Standup: Entradas importantes
Equipo Scrum
Scrum Master
Impediment Log
SCRUM
Realizar el Daily Standup
Herramientas importantes - Daily Standup
El Daily Standup es una breve reunión diaria con un time-box de 15

minutos.
Los miembros del equipo se reúnen para dar un reporte sobre su

progreso en el sprint y planificar las actividades del día.
En la reunión cada miembro del Equipo Scrum da respuesta a las tres

preguntas diarias.
Se recomiendan los debates entre el Scrum Master y el equipo o entre

los miembros del Equipo Scrum, aunque tales discusiones suceden
después de la reunión a fin de garantizar que el Daily Standup sea breve.
SCRUM
Herramientas importantes – Tres preguntas diarias
Las tres preguntas diarias se utilizan en los Daily Standups, organizados por el Scrum
Master, donde cada miembro del Equipo Scrum brinda información en forma de
respuesta a tres preguntas específicas:
1. ¿Qué he hecho desde la última reunión?

2. ¿Qué tengo planeado hacer antes de la siguiente reunión?
3. ¿Qué impedimentos u obstáculos (si los hubiera) estoy enfrentando en la
actualidad?
Es muy recomendable que, de ser posible, los miembros del equipo den respuesta a
las dos primeras preguntas en forma cuantificable en vez de dar largas respuestas
cualitativas.
Los miembros del equipo pueden organizar reuniones adicionales después del Daily
Standup a fin de abordar temas que requieran de mayor discusión.
SCRUM
Salidas importantes – Sprint Burndown Chart actualizado
El Sprint Burndown Chart es una gráfica que muestra la cantidad de

trabajo pendiente en el actual sprint.
El Sprint Burndown Chart inicial se acompaña de un Planned Burndown.

El Sprint Burndown Chart debe actualizarse al final de cada día conforme
se concluye el trabajo.
SCRUM
120
112
100
Puntos de historia
84
80
60
56 Planificado
Planned
40
28
20
0 0
1 2 3 4 5
Días
SCRUM
Puntos de historia
Planificado
Real
Días
SCRUM
120
112
100
Puntos de historia
84
80
60 Planificado
Planned
56
Real
40
28
20
0 0
1 2 3 4 5
Días
SCRUM
120
112
100
Puntos de historia
84
80
60 Planificado
Planned
56
Real
40
28
20
0 0
1 2 3 4 5
Días
SCRUM
120
112
100
Puntos de historia
84
80
60 Planificado
Planned
56
Real
40
28
20
0 0
1 2 3 4 5
Días
SCRUM
Salidas importantes – Impediment Log actualizado
Este tema ya fue analizado anteriormente.
SCRUM
Implementación
Refinamiento del Backlog Priorizado del Producto
Figura 10-8: Refinar el Backlog Priorizado del Producto—Entradas, herramientas y salidas. SBOK, p. 230
176 SCRUM
Implementación
El Product Owner es responsable de refinar el Backlog Priorizado del

Producto.
El refinamiento implica agregar o modificar los elementos del Backlog

Priorizado del Producto a fin de cumplir los requisitos cambiados e incluir
historias de usuario más detalladas en el siguiente sprint.
El Backlog Priorizado del Producto puede ser actualizado con nuevas

historias de usuario, nuevas solicitudes de cambio, nuevos riesgos
identificados, historias de usuario actualizadas o repriorización de historias
de usuario existentes.
Se puede llevar a cabo una reunión de revisión del Backlog Priorizado del
Producto.
SCRUM
Backlog Priorizado del Producto
SCRUM
Herramientas importantes
Reuniones de revisión del Backlog Priorizado del Producto
El Product Owner puede tener varias reuniones por separado con los stakeholders
relevantes, con el Scrum Master y con el Equipo Scrum a fin de asegurarse de
contar con la información suficiente para actualizar el Backlog Priorizado del
Producto en el proceso de su refinamiento.
La intención de las reuniones de revisión del Backlog Priorizado del Producto es

asegurarse de que se entiendan las historias de usuario y los criterios de
aceptación y de que el Product Owner la escriba adecuadamente reflejando los
requerimientos y prioridades actuales del stakeholder (cliente).
Las reuniones de revisión del Backlog Priorizado del Producto garantizan también
que se eliminen historias de usuario irrelevantes y que se incorporen las
solicitudes de cambio aprobadas o los riesgos identificados en el Backlog
Priorizado del Producto.
SCRUM
Salidas importantes
Backlog Priorizado del Producto actualizado
El Backlog Priorizado del Producto se puede actualizar con nuevas

historias de usuario, nuevas solicitudes de cambio, nuevos riesgos
identificados o historias de usuario actualizadas o bien, la repriorización
de las historias de usuario ya existentes.
Como requisito mínimo para el refinamiento, al inicio de cada sprint se

deben refinar suficientes elementos de mayor prioridad en el backlog a
fin de que el equipo pueda comprometerse a desarrollarlos y crear los
entregables respectivos en el siguiente sprint.
SCRUM
Fase de Scrum – Revisión y retrospectiva
Figura 11-2: Resumen de la Revisión y retrospectiva (esenciales). SBOK, p. 239
181 SCRUM
Fase de Scrum – Revisión y retrospectiva
En la fase de revisión y retrospectiva incluye se revisan los

entregables y se establecen formas de mejorar las prácticas y
métodos utilizados en el trabajo del proyecto.
SCRUM
Revisión y retrospectiva
Demostrar y validar el sprint
Figura 11-3: Demostrar y validar el sprint—Entradas, herramientas y salidas. SBOK, p. 239
183 SCRUM
Revisión y retrospectiva
El Equipo Scrum demuestra los entregables del sprint al Product Owner,

quien verifica si cumplen los criterios de aceptación.
Esto se hace como parte de la Reunión de revisión del sprint al final de cada
sprint, donde se ofrece al Product Owner y a los stakeholders la oportunidad
de inspeccionar lo que se ha finalizado hasta el momento.
Ayuda a establecer si de deben hacer cambios en el proyecto o en los

procesos de los siguientes sprints.
El resultado es la aceptación o el rechazo de los elementos del backlog por

parte del Product Owner. Los elementos no aceptados permanecen en el
Backlog Priorizado del Producto.
SCRUM
Demostrar y validar el sprint: Entradas
importantes
Entregables del sprint
Sprint Backlog
Criterios de aceptación de historias de usuario
SCRUM
Herramientas importantes – Reunión de revisión del sprint
Los miembros del equipo principal de Scrum y los stakeholders relevantes

participan en las reuniones de revisión del sprint para aceptar los entregables
que cumplan con los criterios de aceptación de las historias de usuario y
rechazar los entregables no aceptables.
Tales reuniones se convocan al final de cada sprint.
El Equipo Scrum demuestra los logros del sprint, incluyendo las nuevas
funcionalidades o los productos elaborados.
Esto brinda una oportunidad para que el Product Owner y el(los) stakeholder(s)
inspeccionen lo que se ha completado hasta el momento y determinen si deban
realizarse cambios en el proyecto o en los procesos en sprints posteriores.
SCRUM
Aceptación o rechazo de los elementos
del Backlog Priorizado del Producto
Aunque se recoge la opinión de todos los usuarios,

únicamente el Product Owner tiene la autoridad para
aceptar o rechazar como terminada una historia de usuario
en particular, según los criterios de aceptación que fueron
acordados.
Es responsabilidad del Scrum Master asegurase de que los

criterios de aceptación de una historia de usuario no sean
modificados por el Product Owner a mitad de un sprint.
Las historias de usuario parcialmente completadas son

rechazadas como “no terminadas” y se devuelven al Backlog
Priorizado del Producto.
187 SCRUM
Salidas importantes – Entregables aceptados
Los entregables que cumplen con los criterios de aceptación de las

historias de usuario son aceptados por el Product Owner.
Estos se consideran entregables aceptados que pudieran ser

entregados al cliente y así se desea.
Se mantiene una lista de entregables aceptados y se actualiza después

de cada reunión de revisión del sprint.
SCRUM
Salidas importantes – Entregables rechazados
Si los entregables no cumplen con los criterios de aceptación, tales

entregables se rechazan.
Las historias de usuario asociados a tales entregables rechazados se

agregan al Backlog Priorizado del Producto para que tales
entregables puedan ser considerados como parte de un sprint
posterior.
SCRUM
Flujo de incremento del producto
Figura 5-1: Diagrama de flujo del incremento del proyecto. SBOK, p. 89
190 SCRUM
Revisión y retrospectiva – Retrospectiva del
sprint
Figura 11-5: Retrospectiva del sprint—Entradas, herramientas y salidas. SBOK, p. 244
191 SCRUM
Revisión y retrospectiva – Retrospectiva del
Después de la Reunión de revisión delsprint
sprint, el Equipo Scrum lleva a cabo una
reunión de retrospectiva del sprint.
La finalidad es examinar el sprint para identificar posibles mejoras en el proceso.
A la reunión de retrospectiva del sprint asiste el Scrum Master y los miembros

del Equipo Scrum. El Product Owner puede estar presente, pero no es
obligatorio.
Los miembros del equipo pueden presentar cualquier problema que enfrentaron
durante el sprint y discutir cómo pueden atenderlos.
Los miembros del equipo analizan lo que salió bien y lo que salió mal en el
sprint. El equipo también sugiere mejoras a la definición de terminado con base
en su experiencia.
Puede haber un acuerdo de mejoras accionables o actualizaciones a las

recomendaciones al Scrum Guidance Body.
SCRUM
Retrospectiva del sprint: Entradas importantes
Scrum Master
Equipo Scrum
Salidas del proceso de Demostrar y validar el sprint
SCRUM
Retrospectiva del sprint: Herramientas importantes
Reunión de retrospectiva del sprint
La reunión de retrospectiva del sprint es un elemento importante del

framework de “inspección-adaptación” de Scrum y es el último paso en un
sprint.
Todos los miembros del Equipo Scrum asisten a la reunión, misma que
organiza y modera el Scrum Master. Se recomienda que asista el Product
Owner, aunque no es obligatorio.
Las discusiones en la reunión de retrospectiva del sprint abarcan tanto lo

que salió mal como lo que salió bien.
SCRUM
Retrospectiva del sprint: Herramientas importantes
Reunión de retrospectiva del sprint
Los objetivos primordiales de la reunión son identificar tres elementos
específicos:
1. Las cosas que el equipo necesita seguir haciendo: mejores prácticas
2. Las cosas que el equipo necesita empezar a hacer: mejoras en el

proceso
3. Las cosas que el equipo necesita dejar de hacer: problemas de

proceso y embotellamiento
Estas áreas se analizan y se crea una lista de mejoras accionables

aceptadas (Agreed Actionable Improvements).
SCRUM
Retrospectiva del sprint: Salida importante
Agreed Actionable Improvements
Los llamados Agreed Actionable Improvements son el principal resultado

del proceso de Retrospectiva del sprint. Forman parte de la lista de
actionable items (elementos accionables) que ha elaborado el equipo
para hacer frente a los problemas y mejorar los procesos a fin de
mejorar también su desempeño en futuros sprints.
SCRUM
Línea de tiempo de un proyecto de Scrum
SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 ... SPRINT X
Planificación Planificación Planificación Planificación Planificación

del sprint del sprint del sprint del sprint del sprint
Revisión y Revisión y Revisión y Revisión y Revisión y
retrospectiva retrospectiva retrospectiva retrospectiva retrospectiva
SCRUM
Ejemplo del un ciclo de Scrum de 2 semanas
DOMINGO LUNES MARTES MIÉRCOLES JUEVES VIERNES SÁBADO
1 SPRINT 1 2 3 4 5 6 7
PLANIFICACIÓN DEL 2º día de trabajo del 3er día de trabajo 4º día de trabajo del 5º día de trabajo del
SPRINT: 4 horas sprint del sprint sprint sprint
Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m
1er día de trabajo del
sprint
Daily Standup 15m
8 9 10 11 12 13 14
6º día de trabajo del 7º día de trabajo del 8º día de trabajo del 9º día de trabajo del SPRINT 1 REV 2HR
sprint sprint sprint sprint SPRINT RETRO 2HR
15 SPRINT 2 16 17 18 19 20 21
PLANIFICACIÓN DEL
SPRINT: 4 horas 2º día de trabajo del 3er día de trabajo 4º día de trabajo del 5º día de trabajo del
sprint del sprint sprint sprint
1er día de trabajo del Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m
sprint
Daily Standup 15m
22 23 24 25 26 27 28
6º día de trabajo del 7º día de trabajo del 8º día de trabajo del 9º día de trabajo del SPRINT 2 REV 2HR
SCRUM
Ejemplo del un ciclo de Scrum de 2 semanas
1 SPRINT 1 2 3 4 5 6 7
PLANIFICACIÓN DEL 2º día de trabajo del 3er día de trabajo 4º día de trabajo del 5º día de trabajo del
SPRINT: 4 horas sprint del sprint sprint sprint
1er día de trabajo del
sprint
8
Daily Standup 15m
9
6º día de trabajo del
Sprint 1
10
11
12
13 14
SPRINT 1 REV 2HR
15 SPRINT 2 16 17 18 19 20 21
PLANIFICACIÓN DEL
SPRINT: 4 horas 2º día de trabajo del 3er día de trabajo 4º día de trabajo del 5º día de trabajo del
sprint del sprint sprint sprint
1er día de trabajo del Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m
sprint
22
Daily Standup 15m
23 Sprint 2
24 25
26
27 28
6º día de trabajo del 7º día de trabajo del SPRINT 2 REV 2HR
SCRUM
Sample Scrum Cycle 4 Weeks (1 month)
1 SPRINT 1 REUNIÓN DE
2 3 4 5 6 7
PLANIFICACIÓN: 1er día de trabajo 2º día de trabajo 3er día de trabajo 4º día de trabajo
8 HORAS del sprint del sprint del sprint del sprint
(Planificación de Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m
tareas y Estimación de
tareas)
8 9 10 11 12 13 14
5º día de trabajo 6º día de trabajo 7º día de trabajo 8º día de trabajo 9º día de trabajo
Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m
15 16 17 18 19 20 21
22 23 24 25 26 REVISIÓN DEL 27 28
SPRINT 1:
15º día de trabajo 16º día de trabajo 17º día de trabajo 18º día de trabajo
4 HORAS
del sprint del sprint del sprint del sprint
Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m RETRO DEL SPRINT 1:
4 HORAS
SCRUM
Sample Scrum Cycle 4 Weeks (1 month)
1 SPRINT 1 REUNIÓN DE
2 3 4 5 6 7
PLANIFICACIÓN: 1er día de trabajo 2º día de trabajo 3er día de trabajo 4º día de trabajo
8 HORAS del sprint del sprint del sprint del sprint
(Planificación de Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m
tareas y Estimación de
tareas)
8 9 10 11 12 13 14
Sprint 1
15 16 17 18 19 20 21
22 23 24 25 26 REVISIÓN DEL 27 28
SPRINT 1:
15º día de trabajo 16º día de trabajo 17º día de trabajo 18º día de trabajo
4 HORAS
del sprint del sprint del sprint del sprint
Daily Standup 15m Daily Standup 15m Daily Standup 15m Daily Standup 15m RETRO DEL SPRINT 1:
4 HORAS
SCRUM
Fase de Scrum – Lanzamiento
Figura 12-2: Resumen del lanzamiento (Esenciales). SBOK, p. 253
202 SCRUM
Fase de Scrum – Lanzamiento
La fase de Lanzamiento se enfoca en presentar al cliente los

entregables aceptados e identificar, documentar e internalizar las
lecciones aprendidas durante el proyecto.
SCRUM
Lanzamiento – Enviar entregables
Figura 12-3: Enviar entregables—Entradas, herramientas y salidas. SBOK, p. 253
204 SCRUM
Lanzamiento – Enviar entregables
Después de que el Product Owner valida los entregables del sprint, los
entregables aceptados quedan listos para enviarse a los stakeholders.
No todos los sprints terminan con un lanzamiento.
La decisión sobre cuándo presentar los incrementos del producto

potencialmente enviables a los stakeholders se hace en el proceso de
Realizar la planificación del lanzamiento.
El cronograma de planificación del lanzamiento documenta cuando y

cuáles entregables serán presentados.
SCRUM
Enviar entregables: Entradas importantes
Product Owner
Stakeholder(s)
Entregables aceptados
SCRUM
Enviar entregables: Herramientas importantes
Métodos de desplazamiento organizacional
Los mecanismos de desplazamiento de cada organización tienden a ser diferentes

basados en su respectiva industria, en los usuarios meta y el posicionamiento.
Dependiendo del producto a entregarse, el desplazamiento puede ser remoto o

puede incluir el envío físico o la transición de un artículo.
Debido a que la implementación tiende a implicar un alto nivel de riesgo, las

organizaciones suelen tener mecanismos de implementación bien definidos y
establecidos, con procesos detallados para garantizar el cumplimiento de todas las
normas aplicables y medidas de garantía de calidad.
Estas podrían incluir aprobaciones finales de los representantes específicos de

gestión, mecanismos de aprobación de usuario y directrices para la funcionalidad
mínima de un lanzamiento.
SCRUM
Enviar entregables: Salidas importantes
Acuerdo de entregables funcionales
Los entregables que cumplen con los criterios de aceptación, reciben el

cierre formal del negocio y la aprobación formal por parte del cliente o del
patrocinador.
Obtener la aceptación formal del cliente es fundamental para el

reconocimiento de los ingresos. La responsabilidad de obtener dicha
aceptación se define en las políticas de la empresa y no es necesariamente
la responsabilidad del Product Owner.
SCRUM
Entregables funcionales
Esta salida es el entregable final enviable (del inglés: shippable deliverable)

para el cual fue sancionado el proyecto.
A medida que se crean nuevos incrementos de los productos, estos se

integran continuamente a los incrementos anteriores, por lo que hay un
producto potencialmente entregable disponible en todo momento a lo
largo del proyecto.
SCRUM
Lanzamientos del producto
Los lanzamientos de productos deben incluir lo siguiente:
• Contenido del lanzamiento: Esto consiste en información esencial sobre

los entregables que pudiera ayudar al equipo de atención al cliente.
• Notas de lanzamiento: Las notas de lanzamiento deben incluir criterios

de envío externos de cara al mercado para los productos que serán
entregados.
SCRUM
Lanzamiento – Retrospectiva del proyecto
Figura 12-5: Retrospectiva del proyecto—Entrada, herramientas y salidas. SBOK, p. 258
211 SCRUM
Lanzamiento – Retrospectiva del proyecto
El último proceso en el flujo de Scrum es la retrospectiva del proyecto

(similar al proceso de retrospectiva del sprint).
El Equipo Principal de Scrum o los equipos se reúnen para revisar, analizar

e identificar lo que salió bien y lo que salió mal en el ciclo de vida del
proyecto.
La reunión de retrospectiva del proyecto se hace con la finalidad de

identificar las mejores prácticas, mejoras accionables y recomendaciones
para el Scrum Guidance Body.
Las sugerencias, opiniones y el conocimiento obtenido de la reunión de

retrospectiva del proyecto se documentan para su futura consulta.
SCRUM
Retrospectiva del proyecto – Salidas
importantes
Este tema ya fue analizado anteriormente.
SCRUM
Retrospectiva del proyecto Herramientas importantes
Reunión de retrospectiva del proyecto
La reunión de retrospectiva del proyecto es una reunión para determinar las formas
en las que la colaboración y eficacia del equipo puede mejorarse en futuros
proyectos.
También se analizan las oportunidades positivas, negativas y potenciales para

mejorar.
Esta reunión no tiene un time-box asignado y se puede llevar a cabo en forma

presencial o en formato virtual.
Entre los asistentes se encuentran: el equipo del proyecto, el Chief Scrum Master, el
Chief Product Owner y el (los) stakeholder(s).
Durante la reunión, se documentan las lecciones aprendidas y los participantes
buscan oportunidades para mejorar los procesos y atender las ineficiencias.
SCRUM
Retrospectiva del proyecto: Salidas importantes
Agreed Actionable Improvements
Assigned Action Items y Fechas límite
SCRUM

Curso Metodología SCRUM V1

Cargado por

Copyright:

Formatos disponibles

Curso Metodología SCRUM V1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Curso Metodología SCRUM V1

Cargado por

Copyright:

Formatos disponibles

Curso

1. Curso con 3. Examen en 4.

• En línea zoom • 100 preguntas

SMCTM SAMCTM SPOCTM

1.Control del proceso empírico

4. Fases y procesos de Scrum

Un proyecto es un emprendimiento colaborativo para crear

Los proyectos por lo general se ven afectados por limitaciones

“La agilidad es la habilidad de

adaptabilidad con la estabilidad”.

Mercados y tecnologías que cambian rápidamente – Necesidad de estar a la

Reducción del “tiempo para comercializar” productos y aumento en la

Reducción de costos de pruebas y experimentación (simulación y

El valor para el cliente se entrega en el punto de venta, no en el punto de

Necesidad de un método adaptativo de desarrollo en vez de métodos

Individuos e interacciones Sobre Procesos y herramientas

Respuesta ante el cambio Sobre Seguir un plan

Este tema se abordará después con mayor detalle. SCRUM

3. Formar Equipos Scrum

1. Crear historias de usuario

1. Demostrar y validar el sprint

Caso de Declaración de Backlog Priorizado Sprint Entregables

No están abiertos a la discusión

Los empleados se auto-motivan y aceptan más responsabilidades.

Liderazgo servicial que hace énfasis en el logro de resultados enfocándose

Dimensiones 1) Conocimiento: estar al tanto del trabajo de los demás.

centrales del 2) Articulación: dividir el trabajo los miembros del equipo y

colaborativo 3) Apropiación: Usar la tecnología (plataformas y sistemas),

Se prioriza lo que genera más valor primero.

Entregar un producto o servicio valioso para el

El modelo iterativo es más flexible

Los roles de Scrum se dividen en dos amplias categorías:

Roles centrales Roles no centrales

Representa a los interesados El “líder servicial” del Equipo Responsable de desarrollar el

Figura 3-5: Etapas de Tuckman de desarrollo de grupos. SBOK, p. 57

1. Formación (Forming): Esto a menudo se experimenta como un escenario ameno, ya

2. Enfrentamiento (Storming): Durante esta etapa, el equipo trata de cumplir con el

3. Normalización (Norming): Esto es cuando el equipo empieza a madurar, resolver sus

4. Desempeño (Performing): Durante esta etapa, el equipo está unido y opera en su

• Entender lo que agrega valor a los clientes y

• Crear entregables basados en las prioridades 2. Justificación

Durante los sprints, los

Scrum está diseñado para aceptar el

Las organizaciones deben tratar de

Ningún cambio se introduce hasta que se

Figura 6-6: Integración del cambio en Scrum. SBOK, página 109

Riesgos positivos– Oportunidades

Reisgos negativos– Amenazas

Riesgos son las incertidumbres relacionadas a un proyecto.

Los problemas son certezas que se están suscitando en el proyecto.

Si no se atienden a tiempo los riesgos, estos podrían convertirse en

• Incluso después de una amplia capacitación, es posible que los

• Es posible que una cuadrilla de pintores se retrase debido a las fuertes

• Equipo de Probabilidad Backlog Respuestas son Constantemente

Figura 7-4: Proceso de priorización de riesgos. SBOK, página 128

Capítulo Fase Procesos fundamentales de Scrum

1. Crear la visión del proyecto

1. Crear historias de usuario

1. Demostrar y validar el sprint

Tabla 1-1: Resumen de los procesos fundamentales de Scrum. SBOK, p. 15