SPOC Cuaderno de Trabajo Resuelto

© 2014 SCRUMstudy.com v4.
1
Tabla de Contenidos
INTRODUCCIÓN ................................................................................................................ 3
VISIÓN GENERAL AGILE..................................................................................................... 5
¿Qué es Agile?.......................................................................................................................... 5
¿Por qué utilizar Agil? ............................................................................................................... 5
The Agile Manifesto ................................................................................................................. 6
Principios de Agile Manifesto ................................................................................................... 7
Declaración de Interdependencia ............................................................................................. 9
Gestión de Proyectos Tradicional versus Agil ........................................................................... 11
Preguntas - Capítulo Visión de Agile ........................................................................................ 16
VISIÓN GENERAL DE SCRUM ........................................................................................... 18
Planificando en Scrum ............................................................................................................ 18
Marco de Trabajo Scrum......................................................................................................... 19
Roles de Scrum....................................................................................................................... 22
Flujo Scrum ............................................................................................................................ 26
Preguntas - Capítulo Visión Scrum .......................................................................................... 27
FASE: INICIAR ................................................................................................................. 28
Proceso 1: Crear la Visión del Proyecto (Create Project Vision) ................................................ 28
Proceso 2: Identificar al Scrum Master y a los Interesados Identify Scrum Master and
Stakeholder(s) ........................................................................................................................ 29
Proceso 3: Formar el Equipo Scrum (Form Scrum Team) .......................................................... 31
Proceso 4: Desarrollo de Epic(s) (Develop Epic(s)) .................................................................... 32
Proceso 5: Crear la Lista de Requerimientos Pendientes del Producto (Create Prioritized Product
Backlog) ................................................................................................................................. 34
Proceso 6: Realizar la Planificación de las Versiones (Conduct Release Planning) ...................... 36
Preguntas - Capítulo Fase: Iniciar ............................................................................................ 39
FASE: PLANEAR Y ESTIMAR ............................................................................................. 41
Proceso 1: Crear Historias de Usuarios (Create User Stories) .................................................... 41
Proceso 2: Aprobar, Estimar y Comprometerse con las Historias de Usuarios (Approve, Estimate,
and Commit User Stories) ....................................................................................................... 44
Proceso 3: Crear Tareas (Create Tasks) .................................................................................... 45
Proceso 4: Estimar las Tareas (Estimate Tasks) ........................................................................ 47
Proceso 5: Crear la Lista de Pendientes del Sprint (Create Sprint Backlog) ................................ 48
Preguntas - Capítulo Fase: Planear y Estimar ........................................................................... 51
FASE: IMPLEMENTAR ...................................................................................................... 53
Proceso 1: Crear Entregables (Create Deliverables).................................................................. 53
Proceso 2: Realizar la Reunión Diaria (Conduct Daily Standup)................................................. 54
Proceso 3: Mantenimiento de los Pendientes Priorizados del Producto (Groom Prioritized
Product Backlog) .................................................................................................................... 55
Preguntas - Capítulo Fase: Implementar .................................................................................. 59
FASE: REVISAR Y RETROSPECTIVA ................................................................................... 60
Proceso 1: Convocar Scrum de Scrums (Convene Scrum of Scrums) .......................................... 60
© 2014 SCRUMstudy.com 1
Proceso 2: Demostrar y Validar el Sprint (Demostrate and Validate Sprint) .............................. 61
Proceso 3: Retrospectiva del Sprint (Retrospect Sprint) ........................................................... 62
Preguntas - Capítulo Fase: revisar y retrospectiva.................................................................... 64
FASE: LANZAMIENTO ...................................................................................................... 65
Proceso 1: Enviar los Entregables (Ship Deliverables)............................................................... 65
Proceso 2: Retrospectiva del Proyecto (Retrospect Project) .................................................... 67
Preguntas - Capítulo Fase: lanzamiento................................................................................... 68
IMPLEMENTACIÓN DE SCRUM ........................................................................................ 69
Escalabilidad de Scrum ........................................................................................................... 69
Scrum en Programas y Portafolios. ......................................................................................... 69
Transición a Scrum ................................................................................................................. 71
Preguntas - Capítulo Implementando Scrum ........................................................................... 73
IMPORTANCIA DEL VALOR .............................................................................................. 74
INTRODUCCIÓN
Reglas Básicas del Taller
 Está es una clase que dura cinco días y cada día tendrá 3 horas de clase.
 Los participantes deberán estar en el aula de clases a tiempo y regresar puntualmente luego
de los descansos de 15 minutos.
 Los teléfonos celulares deberán estar apagados o estar en modo de silencio.
 Se espera una completa participación por parte de los participantes. Únase a las actividades y
ejercicios de acuerdo a las indicaciones del docente. Advertencia – ¡de hecho podría divertirse
en este taller!
 Los materiales y recursos de estudio que utilizarán los participantes tienen derechos de autor
y son propiedad absoluta de SCRUMstudy y PM Certifica. No deberán ser fotocopiados,
distribuidos o compartidos y deberán ser utilizados únicamente por los participantes que se
hayan inscrito en el aula de capacitación del Taller de Preparación para la Certificación SMC.
Objetivos del Curso

 Proveer el entendimiento de la filosofía y principios Scrum.
 Proveer conocimiento práctico de Scrum desde la perspectiva del Product Owner, incluyendo
los roles, reuniones y artefactos.
 Preparar a los participantes para sentirse cómodos asumiendo el rol del Product Owner en sus
organizaciones, así como también manejando conflictos y obstáculos comunes.
 Preparar a los participantes para rendir el examen de Scrum Product Owner Certified
(SPOC™) de forma exitosa.
Resultados del Curso

 Los estudiantes reconocerán, definirán y trabajarán con facilidad los conceptos, ventajas y
retos del Marco de Trabajo de Scrum.
 Los participantes estarán preparados para manejar los temas relacionados al negocio y para
gestionar el compromiso de los interesados.
 Los estudiantes serán capacitados para desempeñar el rol de Product Owner en sus
organizaciones y ayudarán a adoptar el Marco de Trabajo Scrum en estas. Este conocimiento
incluye el entendimiento funcional de los otros roles de Scrum.
 Los participantes participarán en dinámicas en las cuales llevarán a cabo un proyecto Scrum.
 Los participantes contarán con las herramientas apropiadas para anticiparse a los problemas
relacionados a la implementación práctica de Scrum.
 Se proporcionará a los participantes acceso a un examen en línea.
Metodología del Curso

 La metodología asegura una alta retención de los conceptos y teorías.
 Se motiva a los participantes a poner en práctica los conceptos más que a solamente
escucharlos – esto provee una mejor internalización y retención.
 Se llevarán a cabo dinámicas prácticas y se discutirán los problemas comunes de la
implementación de Scrum a través de diversos ejercicios.
 Los participantes ponen en práctica un caso de estudio para simular el desarrollo del producto
utilizando el Marco de Trabajo Scrum.
Acerca de SCRUMstudy
SCRUMstudy es la entidad de certificación global para las certificaciones Scrum y Agile. Una
gran cantidad de información acerca de SCRUMstudy y sus programas de certificación y
membresía está disponible en SCRUMstudy.com. En la parte inferior se proporciona un
resumen de las certificaciones que otorga SCRUMstudy.
ESMCTM SCTTM
Expert Level Expert Scrum SCRUMstudy
Master Certified Certified Trainer
SMCTM SPOCTM
AECTM
Intermediate Level Scrum Master Scrum Product
Agile Expert
Certified Owner Certified
Certified
SDCTM
Foundation Level
Scrum Developer Certified
Membresía Básica - Gratuita
Esta membresía provee acceso a las principales páginas de información, foros de discusión general y
blogs limitados y recursos en línea. Los candidatos a la certificación deben tener por lo menos una
Membresía Básica para poder dar cualquier examen de certificación de SCRUMstudy.
Membresía Avanzada – Cuota Anual

La Membresía Avanzada provee acceso a foros de discusión y recursos en línea adicionales, además
de descuentos en el precio del examen. Esta membresía es opcional.
Acerca del Examen de Certificación SPOCTM Certification Exam

Formato del Examen
 Elección Múltiple
 140 preguntas por examen
 Un punto otorgado por cada respuesta correcta
 No hay puntos negativos por respuestas erróneas
 180 minutos de duración
 Examen en línea supervisado
 Tasa de Aprobación Actual: 93%
VISIÓN GENERAL AGILE
¿QUÉ ES AGILE?
Jim Highsmith, un gurú conocido de Ágil, quien ha escrito varios libros sobre Agile y los métodos
adaptativos, define Ágil de la siguiente forma:
“La agilidad es la capacidad tanto de crear como de responder a los cambios con el objetivo de
obtener beneficios en un entorno empresarial turbulento. La agilidad es la habilidad para
equilibrar la flexibilidad y la estabilidad”. – Highsmith, 2002
¿POR QUÉ UTILIZAR AGIL?
Con el paso del tiempo, el proceso de desarrollo de software ha sufrido cambios dramáticos.
El desarrollo del software es cada vez más dinámico debido a que los entornos de negocio
cambian rápidamente y las tecnologías están en constante evolución. Además, el mercado global
enfrenta un incremento de presión debido a las demandas de desarrollo rápido de productos, a
las modificaciones y adiciones frecuentes a los requerimientos de productos; y a la alta expectativa
de que los equipos de desarrollo sean altamente flexibles y tengan conocimiento de funciones
cruzadas. En respuesta a esto, las técnicas de desarrollo Agiles de productos se han desarrollado
con el tiempo para atender a las necesidades de la industria.
El mercado de celulares smartphone es un ejemplo de cómo y por qué Ágil es necesario para
mantenerse al día con las tendencias actuales del mercado:
La rápida evolución del mercado y de la tecnología; exige estar a la vanguardia.
La disminución del "time to market" de los productos y el incremento de la

innovación desde el cliente final; requiere desarrollar de forma incremental con
retroalimentación.
Reducción de los costos de pruebas (simulaciones y automatización).
El valor del cliente es entregado en el punto de venta, no en la planificación.
La necesidad de un método de desarrollo adaptativo más que de uno tradicional,

métodos predictivos.
THE AGILE MANIFESTO
El Manifiesto del Desarrollo Ágil, o el Manifiesto Ágil, como es más conocido, es la creación de un
grupo de diecisiete expertos en software que incluye a Kent Beck, Jim Highsmith, Ken Schwaber,
Alistair Cockburn, y Robert C. Martin, quienes definieron la visión y principios de está metodología
de desarrollo.
Estamos descubriendo mejores formas de desarrollar
software haciéndolo y ayudando a que otros lo hagan.
A través de este trabajo hemos llegado a valorar:
Los individuos y las Interacciones Procesos y Herramientas

Software Funcionando Documentación Extensiva
Colaboración con el Cliente Negociación Contractual
Respuestas ante el cambio Seguir un Plan
Es decir, mientras que hay valor en los elementos de

la derecha, valoramos más los elementos de la izquierda.
El permiso para copiar fue proporcionado por los autores mencionados mediante aviso en http://agilemanifesto.org/.
El manifiesto claramente establece que mayor valor tienen los puntos de la izquierda en
comparación con los de la derecha, lo que implica un cambio significativo al método tradicional de
cascada de desarrollo de software.
1. Individuos e interacciones sobre procesos y herramientas
Aunque los procesos y herramientas ayudan a completar con éxito un proyecto o producto, las
personas que se comprometen, participan e implementan un proyecto determinan el grado de
eficacia de los procesos y herramientas utilizadas.
2. Software funcionando sobre la documentación extensiva

Mientras que la documentación es necesaria y útil para cualquier proyecto, Ágil se enfoca en los
entregables. El objetivo principal de un proyecto Ágil es entregar valor real en forma de trabajo de
software de alta calidad (u otro producto o servicio). Esto no solo mejora el Retorno sobre la
Inversión (ROI), sino también permite que el cliente proporcione retroalimentación oportuna.
3. Colaboración con el Cliente sobre la negociación contractual

Tradicionalmente, los clientes han sido jugadores externos que participan sólo al principio y al final
del ciclo de vida del proyecto, y las relaciones con ellos se basa en términos y condiciones de los
contratos. Sin embargo, Ágil cree en un enfoque de valor compartido en la que los clientes son
colaboradores. Un proyecto sólo puede completarse con éxito cuando hay una visión compartida
del producto.
4. Responder ante el cambio en vez de seguir un plan

Ser ágil significa aceptar el cambio y convertirlo en una ventaja competitiva. Debido a la situación
actual del mercado que se caracteriza por frecuentes cambios en las necesidades del cliente,
tecnología en constante evolución y constante fluctuación de patrones comerciales, es más
importante ser flexible que seguir un plan estático.
PRINCIPIOS DE AGILE MANIFESTO
El Manifiesto Ágil no sólo proclama los cuatro valores de la filosofía Ágil, también resalta los
principios esenciales que forman el marco ideológico y estructural de cada metodología de
desarrollo basado en el enfoque Ágil de desarrollo de software.
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al
cliente.
3. Entregamos software funcional de manera frecuente, entre dos semanas y dos

meses, con preferencia el periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma

cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que brindarles

el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo

y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal del avance del proyecto.
8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante
de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-

organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para que
como consecuencia procedan a ajustar y perfeccionar su comportamiento.
PRINCIPIO CONSECUENCIAS
1. Nuestra mayor prioridad es satisfacer al  Satisfacción al cliente (no a la oficina de gestión de

cliente mediante la entrega temprana y proyectos).
continua de software con valor.  Entrega temprana y continua (obteniendo
retroalimentación temprana para solucionar los
problemas).
 Software que entrega valor (se enfoca en el valor y
en el producto final, no en la documentación).
2. Aceptamos que los requisitos cambien,  Aceptación del cambio; que sucederá de todos
incluso en etapas tardías del desarrollo. modos.
Los procesos Ágiles aprovechan el  Esfuerzo por proporcionar información más
cambio para proporcionar ventaja reciente, funcionalidad de alto valor (ventaja
competitiva al cliente. competitiva).
 Mayor tiempo que puede ser invertido en el
producto final, aceptando el cambio en lugar de
luchar contra él.
3. Entregamos software funcional de  Entrega frecuente.

manera frecuente, entre dos semanas y  Retroalimentación temprana y frecuente.
dos meses, con preferencia el periodo  Detección si se puede proceder o si se necesita
de tiempo más corto posible. cambiar las cosas.
 Mantiene clientes comprometidos.
4. Los responsables de negocio y los  Los desarrolladores aprenden sobre el negocio y lo
desarrolladores trabajamos juntos de entienden.
forma cotidiana durante todo el proyecto.  Los representantes del negocio logran un mejor
entendimiento de lo que es difícil/costoso
desarrollar y lo que es fácil/barato.
 El equipo se esfuerza por tener reuniones diarias-
mayor frecuencia, mejor.
 Mantiene a la gente del negocio comprometida.
5. Los proyectos se desarrollan en torno a  La diferencia de “tener el mejor equipo” frente a

individuos motivados. Hay que “tener los mejores procesos y herramientas” es de
brindarles el entorno y el apoyo que 10 a 1.
necesitan, y confiarles la ejecución del  Los equipos empoderados confían en su
trabajo. experiencia y su trabajo en equipo.
 Dan apoyo cuando es necesario.
 Gente motivada.
6. El método más eficiente y efectivo de  Las emociones y el lenguaje corporal se consideran
comunicar información al equipo de como elementos importantes del proceso de la
desarrollo y entre sus miembros es la comunicación.
conversación cara a cara.  La realidad mostrará que la comunicación cara a
cada no siempre se puede dar, en estos casos, se
utilizará medios similares como video conferencia.
7. El software funcionando es la medida  Hacer software que funcione es el enfoque

principal del avance del proyecto. principal. La documentación se convierte en la
segunda prioridad, en un rol de soporte.
 La medida del software esta relacionado a lo
“terminado”.
8. Los procesos ágiles promueven el  Mientras las metodologías ágiles están orientadas
desarrollo sostenible. Los a la flexibilidad y a generar valor en un corto plazo,
patrocinadores, desarrolladores y también se esfuerzan por maximizar el valor del
usuarios debemos ser capaces de tiempo.
mantener un ritmo constante de forma  No se agotarán las personas valiosas.
indefinida.
PRINCIPIO CONSECUENCIAS
9. La atención continua a la excelencia  En el mundo del software, una vez que este está
técnica y al buen diseño mejora la muy interrelacionado, este se convierte resistente
agilidad. al cambio.
 Conservan el software para que se pueda
mantener fácilmente.
 Dedicación de un poco de esfuerzo para
mantener el software flexible (refactorización). Si
el producto llega a ser inflexible y resistente al
cambio, entonces no será posible direccionar los
requisitos cambiantes de forma rápida.
10. La simplicidad, o el arte de maximizar la  En el mundo del software, el 60% de las
cantidad de trabajo no realizado, es funcionalidades implementadas son difícilmente
esencial. (o nunca) utilizadas.
 Se evita el código muerto que desperdicia
esfuerzo y causa problemas.
 Utilización del método más sencillo posible
primero.
11. Las mejores arquitecturas, requisitos y  Para obtener lo mejor de las personas, se deja
diseños emergen de equipos auto- que ellos se auto-organicen, lo que incluye sus
organizados. asignaciones.
 Aumenta el compromiso y orgullo por su trabajo.
 El equipo conoce mejor lo que funciona o lo que
no.
12. A intervalos regulares el equipo reflexiona  Las lecciones aprendidas se trabajan a lo largo
sobre cómo ser más efectivo para que del proyecto, no sólo al final.
como consecuencia procedan a ajustar y  Dado que el cambio es aceptado y es posible que
perfeccionar su comportamiento. se dé durante el proyecto, no se espera hasta que
el proyecto termine para las lecciones aprendidas.
 El equipo definirá los cambios necesarios y los
pone en práctica.
 Al hacerlo, pueden beneficiarse inmediatamente
de las mejoras al proyecto en curso.
DECLARACIÓN DE INTERDEPENDENCIA
Escrita en 2005 como complemento al Manifiesto Ágil, la “Declaración de Interdependencia” es la

piedra angular de las prácticas ágiles. Liderada por Alistair Cockburn, un grupo de directores de
proyecto escribieron esta declaración. El manifiesto identifica el “qué”, y la Declaración de
Interdependencia (DOI) explica el “por qué”.
Declaración de Interdependencia
Los enfoques ágiles y adaptables vinculan personas, proyectos y valor.
Somos una comunidad de líderes de proyecto altamente exitosos en la entrega de resultados.

Para alcanzarlos:
 Incrementamos el retorno de inversión, haciendo del flujo continuo de valor nuestro

enfoque.
 Entregamos resultados fiables mediante la participación de los clientes en las

interacciones frecuentes y la propiedad compartida.
 Esperamos la incertidumbre y la gestionamos a través de iteraciones, anticipación y

adaptación.
 Liberamos la creatividad y la innovación al reconocer que las personas son la fuente

más grande de aporte de valor, y creamos un entorno en el que pueden hacer la diferencia.
 Impulsamos el rendimiento mediante la rendición de cuentas del grupo para resultados

y la responsabilidad compartida para la eficacia del equipo.
 Mejoramos la eficacia y la confiabilidad a través de estrategias, procesos y prácticas

específicas a la situación.
El DOI es un documento importante para todos los involucrados en un proyecto de desarrollo.

Es aún más importante para el Product Owner porque este proporciona reglas para este rol. La
tarea del Product Owner es:
 Garantizar un mayor retorno de la inversión (ROI) centrándose en el valor y su flujo

continuo. El Product Owner es el interesado clave y posee la visión clara del proyecto.
Debido a que el Product Owner bosqueja el Product Backlog, el o ella puede asegurar que
el modelo de desarrollo iterativo e incremental se enfoque principalmente en la entrega
continua de funcionalidades del negocio que den valor, y a su vez mejore el retorno de la
inversión.
 Obtener resultados fiables mediante la maximización del involucramiento del cliente. El

Product Owner compromete a los clientes en interacciones frecuentes e inculca un sentido
de propiedad compartida. Ágil es una metodología orientada a las personas porque
promueve la participación directa y activa de los clientes.
El Product Owner representa al cliente- el o ella es la Voz del Cliente, o VOC- y es el
puente entre los interesados y el Equipo Scrum. El Product Owner da la perspectiva del
cliente, decide la Visión del Producto, prioriza los elementos del Product Backlog, y
proporciona criterios de aceptación para estos elementos.
 Esperar que la incertidumbre y los riesgos disminuyan al dividir el trabajo en pequeñas

iteraciones, impulsados por el valor basándose en los principios de la anticipación y la
adaptación. La incertidumbre y los riesgos son inevitables en cualquier actividad de
desarrollo; no deben ser ignorados o pospuestos; por el contrario deben ser identificados
y gestionados. El Product Owner juega un rol importante en este tema, porque es
responsable de evaluar la viabilidad y garantizar la entrega del producto.
 Liberar la creación y la innovación mediante el reconocimiento que el software y el
desarrollo de productos es una actividad humana, y las personas son la fuente última de
valor. Un ambiente agradable para las personas permite que estas se diferencien a través
de la creatividad y la innovación.
 Impulsar el rendimiento mediante la activación de la rendición de cuentas grupal para

obtener los resultados a través de la responsabilidad compartida en la eficacia del equipo.
Cada actividad de desarrollo es una actividad dinámica, y todo el equipo tiene que ser
responsable de su propio rendimiento. El Product Owner necesita ponerse a disposición
de inmediato del equipo Scrum durante todo el proyecto para su retroalimentación y
aclaraciones. Es su responsabilidad garantizar que la Visión del Producto y las
funcionalidades prioritarias se entiendan claramente para fomentar un alto rendimiento.
 Mejorar la eficacia y la confiabilidad a través de la implementación de estrategias

específicas para cada situación, procesos y prácticas. El Product Owner asegura que las
estrategias sean adecuadas para cada situación. Los procesos y las prácticas son los
factores clave de cualquier actividad de desarrollo.
Dado que los proyectos reales son complejos y están colmados de problemas, el Product
Owner tiene que asegurar que los procesos estén alineados con la Visión del Proyecto.
GESTIÓN DE PROYECTOS TRADICIONAL VERSUS AGIL
Las metodologías ágiles requieren un cambio de mentalidad respecto a los métodos tradicionales.
Mientras que los métodos de cascada se centran en el alcance y esta es utilizada para determinar
los costos y el cronograma, el marco de trabajo ágil se enfoca en el valor del negocio y este se
utiliza para determinar la calidad y las limitaciones de desarrollo.
Mientras que el modelo de cascada es adecuado para ambientes ordenados y/o predecibles, los
métodos ágiles son más exitosos en entornos caóticos porque son métodos “chaordic”
[chaos+order].
Mientras que los modelos de cascada creen en un modelo de agente racional, los métodos ágiles
se inclinan a basarse en enfoques de valor compartido. El método de cascada utiliza estructuras
de comando control, mientras que los métodos ágiles utiliza estructuras más planas, colaborativas
basadas en ciclos de inspección-adaptación.
Una comparación entre los métodos ágiles y tradicionales:
Gestión de Proyectos
Enfoque Agile
Tradicional: Cascada
El énfasis está en Personas Procesos

Dominio No predecible/exploratorio Predecible
Documentación Sólo mínima según se requiera Exhaustivo
Aseguramiento de Calidad Centrada en el Cliente Centrada en el Proceso

Estilo de Procesos Iterativo Lineal
Organización Auto-organizada Gestionada
Planificación por Adelantado Baja Alta
Perspectiva hacia el cambio Adaptabilidad Sostenibilidad

Priorización de los Según el valor del negocio y
Fija según el plan de proyecto
Requisitos regularmente actualizada
Estilo de Gestión Descentralizado Autocrático
Liderazgo Colaborativo, Líder Servicial Comando y control
Medición del Rendimiento Valor del negocio Plan de Conformidad

Retorno sobre la Inversión Al comienzo y a lo largo del
Al final del proyecto
(ROI) proyecto
La figura de abajo muestra la diferencia entre el Método de Gestión Tradicional y el Ágil

representado por un proyecto Scrum.
Lanzamiento
Scrum vs Método Tradicional
Como se ilustra en el diagrama anterior, los proyectos Scrum se completan de forma iterativa de
tal forma que las funcionalidades son liberadas al final de cada iteración- llamada Sprint en Scrum.
De preferencia, aquellas que tiene alto valor al negocio se completan primero. Varios equipos
multifuncionales trabajan en paralelo a través de los Sprints para ofrecer soluciones
potencialmente comercializables al final de cada Sprint. El número de funcionalidades no
terminadas – mostradas con una línea discontinua – decrece de manera constante a través del
proyecto Scrum. En el método tradicional, la cantidad de funcionalidades no terminadas sigue
siendo alta hasta el final y muy cerca del final del proyecto.
Debido a que cada Sprint da como resultado un incremento de producto (que es parte del producto
final), existe un objetivo medible que el equipo tiene que cumplir, por lo que se asegura el avance
y así el proyecto podrá terminar a tiempo. Los métodos tradicionales no ofrecen dichos controles
y, por lo tanto, pueden dar lugar a situaciones en las que el equipo podría relajarse y terminar con
mucho trabajo al final.
Debido a que el cliente interactúa regularmente con el Equipo Scrum, el trabajo completado es
revisado regularmente; por lo tanto, se garantiza que el progreso satisface con las
especificaciones del cliente. En la gestión tradicional, no hay tal interacción porque el trabajo se
lleva a cabo en silos y no hay funcionalidad que se pueda mostrar hasta el final del proyecto.
En proyectos complejos, en los que el cliente no tiene claro cuál será el producto final, por lo que,
las funcionalidades del producto cambian, el modelo iterativo es más flexible para asegurar que
estos se puedan incorporar durante el desarrollo. La gestión de proyectos tradicional lucha para
dar cabida a dichas funcionalidades.
Sin embargo, en el caso de proyectos sencillos con funcionalidades bien definidas, y cuando el
equipo tiene la experiencia para desarrollar estos proyectos y por lo tanto puede hacer
estimaciones precisas, el método de cascada puede tener éxito.
Métodos Ágiles
Método Valores Principales Características Roles

Scrum  Control del Proceso Modelo iterativo time-  Product Owner
Empírico boxed con equipos  Scrum Master
 Auto organización auto-organizados.  Scrum Team
 Colaboración Procesos como Crear
 Priorización basada el Sprint Backlog,
en valor Crear Entregables,
 Time-boxing Mantener el Product
 Desarrollo iterativo Backlog Priorizado, y
la Retrospectiva del
Spring son parte de
cada Sprint. Las
Reuniones Diarias
ayudan a tener una
comunicación abierta.
FDD Desarrollo Planear, diseñar, y Propiedad individual  Jefe de Proyecto

Basado en construir por de clases,  Jefe de Arquitectura
Funcionalidades funcionalidad. modelamiento de  Gerente de Desarrollo
dominio de objeto,  Jefe de Programación
equipos de  Dueño de Clases
funcionalidades,  Experto del Dominio
modelamiento inicial,
gestión de
configuración de
modelo de turbulencia,
y desarrollos
regulares.
EP Programación  Simplicidad Enfocado en buenas  XP Coach

Extrema  Comunicación prácticas de desarrollo  XP Customer
 Retroalimentación de software,  XP Programmer
 Coraje Programación en  XP Admnistrator
 Respeto Pares, Desarrollo  XP Tracker
orientado a las  XP Tester
Pruebas TDD,
Propiedad colectiva de
código y
refactorización.
DSDM Métodos de  Enfocarse en la Fase de pre-proyecto,  Advisor user

Desarrollo de necesidad del negocio fase del ciclo de vida  Ambassador user
Sistemas Dinámicos  Entregar a tiempo del proyecto, y fase de  Analyst
 Colaborar post-proyecto.  Architect
 Nunca comprometer Estudio de factibilidad,  Developer
la calidad Estudio de negocio,  Executive Sponsor
 Construir Iteración del modelo  Project manager
funcional, Iteración de
incrementalmente a  Stakeholder
diseño y desarrollo, e
través de bases  Tester
sólidas implementación.
 Visionary
 Desarrollar
iterativamente
 Comunicarse
Continua y
Claramente
 Demostrar Control
Otros Métodos Ágiles
Lean Kanban Agile Unified Essential Open Unified

Crystal Clear Unified
Development Development Process Process
Process
PREGUNTAS - CAPÍTULO VISIÓN DE AGILE
1. ¿Cuál de las siguientes NO es un Principio del Manifiesto Ágil?
a. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.
b. Aceptamos que los requisitos cambien, a menos que el proyecto se encuentre en
etapas tardías del desarrollo. Los cambios tardíos en el ciclo de desarrollo es muy
caro de adoptar.
c. Entregamos software funcional de manera frecuente, entre dos semanas y dos
meses, con preferencia el periodo de tiempo más corto posible.
d. Los responsables de negocio y los desarrolladores trabajamos juntos de forma
cotidiana durante todo el proyecto.
2. ¿Qué componentes describen el enfoque Ágil?
a. Manifiesto ágil, declaración de interdependencia y principios ágiles.

b. Manifiesto ágil, declaración de interpretación y principios ágiles.
c. Manifiesto ágil, declaración de interdependencia y prácticas ágiles.
d. Políticas ágiles, declaración de interdependencia y principios ágiles.
3. ¿Cuál de las siguientes NO es una característica de los proyectos Ágiles?
a. Auto-organizados
b. Iterativos
c. Flexible
d. Comando y Control
4. Identifica el principio ágil INCORRECTO y su consecuencia.
a. Los responsables de negocio y los desarrolladores trabajamos juntos de forma

cotidiana durante todo el proyecto: es obligatorio que los interesados y el equipo
se reúnan y conversen diariamente.
b. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad:
esto permite que el software sea fácil de mantener.
c. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-
organizados: los equipos auto-organizados tienen un alto nivel de apropiación en
los diseños que ellos crean.
d. Entregamos software funcional de manera frecuente: esto asegura la
retroalimentación oportuna que puede ser incorporada al proceso de desarrollo de
productos en una etapa temprana.
5. La Declaración de Interdependencia (DOI) es un documento importante en gestión de

proyecto, especialmente para los Product Owners (PO). ¿Cuál de los siguientes
enunciados respecto al DOI, NO es correcto?
a. Recuerda al PO que el enfoque principal de desarrollo de proyectos es el ROI

temprano.
b. Afirma que el PO debe garantizar resultados confiables inculcando un sentido de
propiedad compartida en los interesados.
c. Establece que el PO es la voz oficial de todos los temas; el equipo no gozará de
autonomía en cualquier parte del proceso de desarrollo.
d. Reconoce que la incertidumbre y los riesgos son inevitables dentro del proceso de
desarrollo, por lo que el PO juega un papel importante gestionando la
incertidumbre y reduciendo el riesgo.
6. ¿Cuál de los siguientes principios NO es soportado por Ágil?
a. El enfoque principal del proceso de desarrollo es asegurar incrementar el retorno

sobre la inversión (ROI).
b. El modelo de desarrollo iterativo e incremental debe enfocarse en la entrega
continua de características valoradas por el negocio.
c. La interferencia continua de los clientes obstaculiza el proceso de desarrollo, por
lo que el involucramiento del cliente deberá reducirse al mínimo.
d. Estrategias para situaciones específicas, procesos y prácticas deben ser
implementadas para asegurar la efectividad y confiabilidad.
VISIÓN GENERAL DE SCRUM
Scrum es uno de los marcos de trabajo ágil para desarrollo de proyectos. Emplea un enfoque
adaptativo e iterativo para gestionar proyectos y desarrollo de productos. Ha sido diseñada para
ser rápida, es un método flexible que entrega alto valor en el menor tiempo.
PLANIFICANDO EN SCRUM
A diferencia de los métodos tradicionales de planificación de proyectos que implican una

planificación adelantada que demanda mucho esfuerzo, la planificación de un proyecto Scrum es
un esfuerzo continuo. Después de algunas demostraciones, los interesados pueden comunicar
mejor los requisitos. Esto permite replanificar el proyecto de acuerdo a los nuevos requerimientos.
Otra característica de los proyectos Scrum es que los cambios pueden hacerse en cualquier etapa
del proyecto.
Esto no quiere decir que en Scrum no se planifica. En lugar de ello, los planes se desarrollan
durante todo el proyecto en base a repriorizaciones, retroalimentación y otros factores
emergentes. Así, la planificación inicial Scrum sólo incluye la creación de un esquema básico del
proyecto. Durante el desarrollo, la planificación es completada en ráfagas cortas, según sea
necesario.
Las metodologías ágiles (incluyendo Scrum) reducen los residuos mediante la disminución de
trabajo que no entrega valor. La planificación de un proyecto no aporta directamente valor al
negocio. Por lo tanto, la planificación en cualquier etapa de un proyecto Scrum debe ser lo más
eficiente posible. La planificación adelantada para el proyecto completo se considera desperdicio,
porque los proyectos Agiles están propensos a una alta tasa de cambio. Por lo que, la planificación
se realiza Justo a Tiempo (Just in Time (JIT)).
Scrum es más útil en proyectos que involucren los siguientes puntos:

1. El desarrollo de proyectos de tecnología de vanguardia.
2. Los equipos son multifuncionales, altamente calificados y dedicados.
3. El desarrollo de productos se desenvuelve en entornos hipercompetitivos.
4. Los cambios de requisitos con frecuentes e intempestivos.
5. Necesidad frecuente de retroalimentación debido a los requisitos complejos.
MARCO DE TRABAJO SCRUM
De acuerdo con Una guía para el conocimiento de Scrum (Guía SBOK™ 2013), Scrum puede ser
mejor entendido a través de sus principios, procesos y aspectos.
Principios Scrum
1. Control del Proceso Empírico
Scrum establece que la toma de decisiones basada en la observación y experimentación
es mejor que la planificación detallada al inicio del proyecto. El control del proceso
empírico está basado en tres ideas principales: transparencia, inspección y adaptación.
Este enfoque es más apropiado para procesos que generan salir no repetibles e
impredecibles.
2. Auto-organización
En lugar del estilo de gestión tradicional comando y control, Scrum enseña que los
trabajadores de la actualidad tienen mucho conocimiento que ofrecer que sólo su
experiencia técnica y que pueden entregar mayor valor cuando se auto-organizan.
3. Colaboración
Scrum enseña que el desarrollo del producto es un proceso de creación de valor
compartido que necesita que los interesados trabajen e interactúen junto para entregar
mayor valor.
4. Priorización basada en el valor

La entrega de alto valor en un tiempo corto requiere priorizar y dividir lo que se hará a
partir de lo que necesita ser implementado.
5. Time-boxing
El tiempo es considerado una restricción y el time-boxing proporciona el ritmo con el que
todos los interesados trabajan y contribuyen. Time-boxing se refiere a la fijación de
periodos cortos de tiempo para realizar una actividad.
Si el trabajo realizado queda incompleto al final del time-box, entonces este se mueve a
otro time-box.
Ejemplos de time-boxes de Scrum incluyen:
 Las reuniones diarias de Scrum (15 minutos por lo general)
 Iteraciones que duran entre una a seis semanas.
Los time-boxes pueden proporcionar la estructura adecuada para proyectos ágiles que
tienen un componente de incertidumbre, son dinámicos por naturaleza, y son propensos
a los cambios. Ayudan a medir el progreso del proyecto e indican cuándo modificar el
enfoque.
6. Desarrollo Iterativo
En proyectos complejos – en los que el cliente no es capaz de definir requisitos muy
concretos o no está seguro cómo lucirá el producto final – el modelo iterativo es más
flexible para asegurar que cualquier cambio solicitado por el cliente sea incluido como
parte del proyecto. La nueva información puede ser utilizada para refinar y mejorar la
precisión de los planes, requerimientos, estimaciones y otros aspectos del proyecto.
Un principio esencial de Scrum es que los requerimientos de cualquier proyecto de largo plazo no
pueden ser entendidos completamente o definidos al inicio del proyecto, especialmente si el
mercado sufre cambios constantemente, por lo que este enfoque debe permitir que el equipo sea
flexible para incorporar cambios de requerimientos. En el enfoque tradicional, el método predictivo
de desarrollo no puede manejar tales cambios. En cambio, Scrum es especialmente útil para
proyectos complejos con gran incertidumbre en los cuales los pronósticos de largo plazo podrían
conllevar a riesgos críticos.
Aspectos Scrum
Los aspectos de Scrum se deben abordar y gestionar a lo largo de un proyecto Scrum. Los cinco
aspectos de Scrum son:
1. Organización
2. Justificación de Negocio
3. Calidad
4. Cambio
5. Riesgo
Procesos de Scrum
Un proyecto Scrum sigue el modelo de cinco fases. Las cinco fases son las siguientes:
1. Iniciar
2. Planear y Estimar
3. Implementar
4. Revisión y Retrospectiva
5. Lanzamiento
Los 19 procesos de Scrum abordan las actividades y el flujo específico de un proyecto Scrum.
Fase Procesos
Crear la Visión del Proyecto

Identificar al Scrum Master e interesados
Initiate Formar el Equipo Scrum
(Iniciar) Desarrollar Epic(s)
Crear la Lista de Pendientes del Producto Priorizada
Realizar la Planificación de las Entregas (Release)
Crear Historias de Usuarios

Aprobar, Estimar y Comprometerse con Historias de
Plan and Estimate Usuarios
(Planear y Estimar) Crear Tareas

Estimar el Trabajos
Crear la Lista de Pendientes de Sprint
Crear Entregables
Implement
Realizar el Standup Diario
(Implementar)
Mantener la Lista de Pendientes del Producto Priorizada
Review and Retrospect Convocar Scrum de Scrums
(Revisión y Demostrar y Validar el Sprint

Retrospectiva) Realizar la Retrospectiva del Sprint
Release Enviar los Entregables

(Lanzamiento) Realizar la Retrospectiva del Proyecto
ROLES DE SCRUM
Los roles de Scrum se dividen en dos categorías:
 Core Roles—Los Core Roles son las funciones que obligatoriamente se requieren para
producir el producto o servicio del proyecto, estos están comprometidos con el proyecto, y son
los responsables del éxito de cada Sprint y del proyecto en su totalidad.
 Non-core Roles: Son las funciones que no son obligatoriamente necesarias para el proyecto
Scrum, y pueden incluir miembros de los equipos que están interesados en el proyecto, pero
no tienen ningún papel formal en el equipo del proyecto. Ellos pueden interactuar con el
equipo, pero no son responsables del éxito del proyecto. Estos roles no esenciales también
deben tenerse en cuenta en cualquier proyecto de Scrum.
Los core roles son el Product Owner, Scrum Master, y el Equipo Scrum. Juntos se les conoce
como el Equipo Central/Principal de Scrum (Scrum Core Team). Es importante tener en cuenta
que, de estos tres roles, ninguno tiene autoridad sobre los otros.
La figura presenta un resumen de los roles principales del Equipo Core de Scrum.
Equipo Scrum
El Equipo Scrum es responsable de crear los entregables del producto. Un Equipo Scrum
normalmente es pequeño, tiene entre 6 a 10 miembros. El equipo decide la cantidad de trabajo
comprometido en un Sprint. El Equipo Scrum normalmente es multi-funcional, ejecutan tareas de
desarrollo, aseguramiento de calidad, etc...
Responsabilidades y Roles Generales Es multi-funcional y auto-organizado.

Goza de completa autonomía durante un
Sprint
Sus miembros son generalistas en los distintos
dominios y especialistas en al menos uno.
La igualdad se mantiene entre todos los
miembros del equipo.
Responsabilidad recae en todo los miembros
del equipo.
Scrum Master
El Scrum Master es un protector y facilitador que asegura que el equipo cuente con el mejor
ambiente para completar con éxito el desarrollo del producto. El Scrum Master ayuda al equipo a
aplicar las prácticas Scrum y protege el equipo de impedimentos externos, promoviendo así la
eficacia de este.
Responsabilidades y Roles Generales Es un protector y facilitador del equipo.

Protege al equipo de interferencias externas.
No consigue que el trabajo sea hecho, pero sí
facilita el equipo.
Asegura que el equipo siga e implemente
prácticas Scrum.
Motiva al equipo, es un coach del equipo.
Como agente de cambio, asegura un proceso
de cambio fluido y efectivo.
Product Owner (Dueño del Producto)
El Product Owner interviene en el proyecto desde el punto de vista del cliente. El cliente es la
persona u organización que adquiere el producto, servicio u otro resultado.
El cliente es un interesado importante junto con los usuarios y patrocinadores.
Product Owner representa a los interesados y a sus necesidades; es responsable de asegurar

que el Equipo Scrum entregue valor, a través del producto, al proyecto. El Product Owner es
“dueño” del producto y es responsable de la finalización exitosa del proyecto; este rol es el enfoque
principal de este curso.
La siguiente tabla resume las responsabilidades del Product Owner en los diferentes procesos de
Scrum.
Proceso Responsabilidades del Product Owner
 Define la Visión del Proyecto
Create Project Vision  Ayuda a crear el Acta de Constitución del Proyecto y el
Presupuesto del Proyecto
 Ayuda a elegir al Scrum Master para el proyecto
Identify Scrum Master and
Stakeholder(s)  Identifica a los interesados
 Ayuda a determinar los miembros del Equipo Scrum
 Ayuda a desarrollar el Plan de Colaboración
Form Scrum Team  Ayuda a desarrollar el Plan para la Formación del Equipo
con el/los Scrum Master(s)
Develop Epic(s)  Crea Epic(s) y Personas
 Prioriza los elementos del Product Backlog (cartera de

Create Prioritized Product pendientes)
Backlog  Define el Criterio de Terminado (Done)
 Crea un Cronograma de Planificación de Versiones
(Releases)
Conduct Release Planning
 Ayuda a determinar la duración del Sprint
 Ayuda a crear Historias de Usuarios
Create User Stories  Define el Criterio de Aceptación para cada Historia de
Usuario
 Aprueba los Historias de Usuarios
Approve, Estimate and  Facilita el compromiso del Equipo Scrum sobre las Historias
Commit User Stories de Usuarios que puede implementar.
 Explica las Historias de Usuarios al Equipo Scrum mientras
Create Tasks crean la Lista de Tareas
 Proporciona orientación y aclaración al Equipo Scrum en la
Estimate Tasks estimación de esfuerzo para las tareas
Create Sprint Backlog  Ayuda al Equipo Scrum a crear el Sprint Backlog
Create Deliverables  Aclara los Requisitos del Negocio al Equipo Scrum
Groom Prioritized Product  Refina la Product Backlog y reprioriza si es necesario

Backlog
 Acepta / Rechaza los Entregables
 Proporciona retroalimentación al Scrum Master y al Equipo
Demonstrate and Validate Scrum
Sprints  Actualiza el Plan de Versiones (Releases) y la Priorización
del Product Backlog
 Ayuda con el lanzamiento de las Versiones de Producto y se
Ship Deliverables encarga de la coordinación con el Cliente
Retrospect Project  Participa en las Reuniones de Retrospectiva del Proyecto
De la misma forma que existe un rol de Product Owner en un proyecto, podría haber un Product
Owner del Programa en un Programa, o un Product Owner del Portafolio en un Portafolio.
Voz del Cliente - Voice of the Customer (VOC)

El cliente es el interesado más importante para cualquier compañía. Por lo tanto, es muy
importante entender sus necesidades y requerimientos. La voz del cliente se enfoca en
necesidades declaradas y no declaradas del cliente, que deben entenderse muy bien antes de
diseñar cualquier producto o servicio. En general, en un entorno de Scrum, El Product Owner
representa la Voz del Cliente.
La siguiente figura enumera las características deseables para los roles básicos de Scrum.
FLUJO SCRUM
La figura a continuación proporciona una visión general del flujo de un proyecto Scrum.
• El ciclo de Scrum comienza con la Fase de Inicio, durante la cual se determina la Visión del
Proyecto y se crea el Product Backlog (Cartera de Necesidades) priorizado.
• Luego el trabajo es completado en varios Sprints. Cada Sprint comienza con una Reunión de
Planificación del Sprint (Sprint Planning Meeting) durante la cual son escogidas las tareas (los
elementos con prioridad alta del Product Backlog) para el Sprint próximo a comenzar.
• Un Sprint suele durar entre 1 - 6 semanas en el cual el Equipo Scrum trabaja en la elaboración
Entregables (Deliverables) potencialmente listos en incrementos de producto.
• Las reuniones diarias (Daily Stand-up Meetings) se llevan a cabo durante el Sprint donde
Los miembros del Equipo Scrum reportan el trabajo avanzado, el trabajo que se proponen
terminar y los impedimentos que están afrontado.
• Al final del Sprint, se lleva a cabo una reunión de revisión del Sprint (Sprint Review Meeting)
en el cual se le presenta una demostración del trabajo terminado al Product Owner y a los
interesados relevantes. El Product Owner acepta o rechaza los entregables presentados.
• El ciclo de Sprint termina con una Reunión de la Retrospectiva del Sprint (Retrospect Sprint
Meeting).
PREGUNTAS - CAPÍTULO VISIÓN SCRUM
1. ¿Qué método de proceso de control es seguido en Scrum?

a. Definido
b. Empírico
c. Explícito
d. Lógico
2. ¿Cuál de los siguientes NO es correcto?

a. Ágil valora las personas sobre los procesos.
b. Ágil valora el valor del negocio sobre el plan de conformidad.
c. Ágil valora el control definido del proceso sobre el control empírico del proceso.
d. Ágil valora el liderazgo colaborativo sobre comando y control.
3. ¿Quién de los siguientes representa la voz del cliente?

a. Scrum Master
b. Product Owner
c. Líder Equipo Scrum
d. Ninguno de los anteriores
4. Todas las siguientes son ventajas de un equipo multifuncional, EXCEPTO:

a. Toma rápida de decisiones
b. Mejor comunicación
c. Competencia efectiva
d. Orientado al objetivo
5. Todos los siguientes son atributos de un miembro del Equipo Scrum Ideal, EXCEPTO
(seleccione todas las que correspondan):
a. Auto-motivado
b. Orientado al proceso
c. Dependiente
d. Colaborar
6. ¿Cuál de las siguientes es responsabilidad del Scrum Master (seleccione todas las que
correspondan)?
a. Capacitar y facilitar al Equipo Scrum
b. Completar el desarrollo del producto de forma exitosa
c. Proporcionar al equipo un entorno de trabajo saludable
d. Conseguir recursos financieros para el desarrollo del producto
7. ¿Quién es responsable del desarrollo del producto?

a. Scrum Master
b. Equipo Scrum
c. Patrocinador
d. Product Owner
FASE: INICIAR
La primera fase de método Scrum es la fase Iniciar. Los procesos relacionados con la iniciación
de un proyecto son los siguientes: Crear la Visión del Proyecto, Identificar al Scrum Master e
interesados, Formar el Equipo Scrum, Desarrollar Epic(s), Crear la Lista de Pendientes del
Producto Priorizada, Realizar la Planificación de las Versiones (Release).
PROCESO 1: CREAR LA VISIÓN DEL PROYECTO (CREATE PROJECT VISION)
Define la Visión del Proyecto
Una salida importante de este primer proceso de la fase de Iniciar es la identificación del Product
Owner. El Product Owner es la persona responsable para que el proyecto brinde el máximo valor
al negocio. Él o ella también es responsable de la articulación de requisitos por parte de los
Clientes y de mantener la Justificación de Negocio para el Proyecto. El Product Owner representa
a la voz del Cliente. Cada Equipo Scrum tendrá un Product Owner designado.
Otro resultado clave del proceso Crear la Visión del Proyecto es una forma y bien estructurada
Declaración de la Visión del Proyecto, la cual 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.
Un Product Owner debe ser capaz de concebir el éxito de un producto. Las organizaciones
generalmente realizan estudios de mercado y otras actividades, como la planificación y el análisis,
para conceptualizar los productos. Un inconveniente de este enfoque es que se asume que los
requisitos del clientes son predecibles y se ignoran otros factores de variación. Otro enfoque
consiste en sumergirse en el proceso de desarrollo. Este podría llevar a un gran error, porque la
organización no ha medido con precisión los requerimientos del cliente o incluso no entiende qué
aspecto debe tener el producto para que sea exitoso.
Una buena Visión de Producto describe qué aspecto debe tener el producto y cómo funcionará.
Es un documento que crea un objetivo único para que el equipo trabaje enfocado a este. Es un
punto de referencia para el equipo en caso exista alguna ambigüedad en los requerimientos del
cliente. Una buena Visión de Producto responde a las siguientes preguntas:
 ¿Quién es el cliente objetivo?

 ¿Cuál es la oportunidad del producto?
 ¿A qué categoría pertenece el producto?
 ¿Cuáles son los principales beneficios que obligan a los usuarios a comprar el producto?
 ¿Cómo se diferencia de los productos de la competencia?
 ¿Cuál es el punto de venta principal?
Ayuda a crear el Acta de Constitución y el Presupuesto del Proyecto
Un Acta de Constitución es una declaración oficial de los objetivos y salidas deseados del
proyecto. En muchas organizaciones, el Acta de Constitución es un documento oficial autorizado
formalmente del proyecto, proporcionando al equipo un mandato escrito para comenzar el trabajo
del proyecto.
El presupuesto del proyecto es un documento financiero que incluye el costo del personal,
materiales y otros gastos relacionados al proyecto. Este es autorizado y aprobado, normalmente,
por el patrocinador para contar con los fondos suficientes disponibles. Una vez que el presupuesto
se apruebe, el Product Owner y el Scrum Master podrían ser involucrados en la gestión del
Presupuesto del Proyecto y también para asegurar que las personas y otros recursos requeridos
para las actividades del proyecto estén disponibles.
1. Caso de Negocio del 1. Reunión de la Visión del 1. Product Owner Identificado *

Proyecto* Proyecto * 2. Declaración de la Visión del
2. Product Owner del 2. Sesiones JAD Proyecto *
Programa 3. Análisis FODA (SWOT) 3. Acta de Constitución del
3. Scrum Master del 4. Análisis de Brechas Proyecto
Programa 4. Presupuesto del Proyecto
4. Interesados del Programa
5. Jefe Product Owner
6. Product Backlog del
Programa
7. Prueba del Proyecto
8. Prueba de Concepto
9. Visión de la Empresa
10. Misión de la Empresa
11. Estudio del Mercado
12. Recomendaciones del
Cuerpo de Asesoramiento
de Scrum (SGB)
PROCESO 2: IDENTIFICAR AL SCRUM MASTER Y A LOS INTERESADOS

IDENTIFY SCRUM MASTER AND STAKEHOLDER(S)
El segundo paso en la fase de Inicio en un proyecto Scrum es identificar al Scrum Master y a los
interesados.
Ayuda a terminar la selección del Scrum Master para el Proyecto
El Product Owner puede aceptar sugerencias de otras fuentes, como del Scrum Master de
Programa, de la Matriz Organizacional de Recursos, Matriz de Destrezas Requeridas y el Cuerpo
de Asesoramiento de Scrum para elegir una persona como Scrum Master. El Product Owner
podría utilizar herramientas como criterios de selección, capacitación, y asesoramiento de
expertos del departamento de Recursos Humanos para identificar al mejor de los candidatos a
Scrum Master.
Es importante que cuando el Product Owner seleccione al Scrum Masters tenga en cuenta sus
habilidades de resolución de conflictos, que encarne el estilo de gestión : Liderazgo Servicial y
que se comprometa a brindar al Equipo Scrum un ambiente propicio para la entrega exitosa del
proyecto.
Criterios de selección
La selección adecuada del(los) Scrum Master(s) y la identificación de los interesados adecuados
es crucial para el éxito de cualquier proyecto. En algunos proyectos pueden haber pre-condiciones
que estipulen determinados miembros del equipo y sus roles.
Los siguientes criterios de selección son importantes para ser un Scrum Master:
1. Habilidades para la resolución de problemas—Es uno de los principales criterios a
considerar al seleccionar al Scrum Master. El Scrum Master debe tener las habilidades y
experiencia necesarias para ayudar a eliminar cualquier Impedimento que encare el Equipo
Scrum.
2. Disponibilidad—El Scrum Master debe estar disponible para agendar, supervisar y facilitar las
reuniones, incluyendo Release Planning Meeting, Daily Standup Meeting, y otras reuniones
relacionadas al Sprint.
3. Compromiso—El Scrum Master se debe comprometer a que el Equipo Scrum esté dotado de
un ambiente de trabajo propicio para asegurar la entrega exitosa del proyecto Scrum.
4. Líder Servicial – El Scrum Master debe poseer cualidades básicas que permitan que sea un
Líder Servicial. El Scrum Master debe escuchar, utilizar la empatía, el compromiso y la visión
mientras que comparte el poder y la autoridad con los miembros del equipo. Los líderes serviciales
son mayordomos que logran resultados enfocándose en la satisfacción de las necesidades del
equipo.
Identifica a los Interesados
Cuando se identifica a los Interesados, es importante recordar que los Interesados incluyen a
todos los clientes, los usuarios y patrocinadores, quienes a menudo interactúan con el Product
Owner, Scrum Master y Equipo Scrum para proveer entradas y facilitar la creación de los
productos del Proyecto. Los Interesados influyen en el proyecto a lo largo de todo su ciclo de vida.
1. Product Owner * 1. Criterios de Selección * 1. Scrum Master Identificado*

2. Declaración de la Visión 2. Consejo Experto del 2. Interesados Identificados*
del Proyecto * Recursos Humanos
3. Product Owner del 3. Entrenamiento y Costos de
Programa capacitación
4. Scrum Master del 4. Costos de Recursos
Programa
5. Jefe del Product Owner
6. Jefe del Scrum Master
7. Interesados del Programa
8. Requisitos de Personal
9. Disponibilidad y
compromiso de las
Personas
10. Matriz de Recursos de la
Organización
11. Matriz de Destrezas
Requeridas
de Scrum
PROCESO 3: FORMAR EL EQUIPO SCRUM (FORM SCRUM TEAM)
Ayuda a seleccionar a los Miembros del Equipo Scrum
El Equipo Scrum es una parte principal de cualquier proyecto Scrum, y conseguir a los miembros
adecuados es importante para la entrega exitosa de estos proyectos. Los miembros del Equipo Scrum
son especialistas generalistas, donde cada uno debe poseer un conocimiento general de diversos
campos y son expertos en al menos uno. Más allá de ser expertos técnicos, son las habilidades
interpersonales de cada miembro del equipo que determinará el éxito de los equipos auto-organizados.
Los miembros ideales de un Equipo Scrum son independientes, auto-motivados, enfocados en el

clientes, responsables y colaboradores. El equipo debe ser capaz de fomentar un ambiente de
pensamiento independiente y toma de decisiones grupal con el fin de extraer los mayores beneficios
de la estructura.
Ayuda a elaborar el Plan de Colaboración
La colaboración es un elemento muy importante en Scrum. La planificación de cómo los diferentes

decisores, los interesados y los miembros del equipo participarán y colaborarán entre sí es vital.
El Plan de Colaboración es una salida opcional que puede ser formal o informal. A veces, puede
ser simplemente un acuerdo verbal entre los interesados, ya que en Scrum se evita
documentación innecesaria. Sin embargo, para proyectos grandes, complejos, especialmente
donde los equipos son distribuidos, puede ser necesario poner en marcha un acuerdo más formal.
Ayuda a elaborar el Plan de Desarrollo de Equipos con el (los) Scrum Master(s)
Desde que el Equipo Scrum es multi-funcional, cada miembro necesita participar activamente en
todos los aspectos del proyecto. El Scrum Master debe identificar problemas con los miembros
del equipo y direccionar con ellos de forma diligente para mantener un equipo efectivo.
Para construir la cohesión del equipo, el Scrum Master debe garantizar que las relaciones entre
los miembros del equipo sean positivas y que todos como equipo estén enfocados en lograr los
objetivos del proyecto y de la organización, esto permite tener una mayor eficiencia y
productividad.
1. Product Owner * 1. Selección del Equipo Scrum* 1. Equipo Scrum Identificado *

2. Scrum Master* 2. Consejo Experto del Recursos 2. Respaldos de los miembros del
3. Declaración de la Visión del Humanos equipo
Proyecto* 3. Costo asociado con el 3. Plan de Colaboración
4. Jefe del Product Owner Personal 4. Plan de Desarrollo del Equipo
5. Requisitos del Personal 4. Costo de Entrenamiento y
6. Disponibilidad y Compromiso Capacitación
de las Personas 5. Costos de Recursos
7. Matriz de Recursos de la
Organización
8. Matriz de Destrezas
Requeridas
9. Requerimientos de Recursos
10. Recomendaciones del Cuerpo
de Asesoramiento de Scrum
PROCESO 4: DESARROLLO DE EPIC(S) (DEVELOP EPIC(S))
Crea Epic(s) y Personas
En terminología Scrum, un Epic es definido cómo una Historia de Usuario no refinada, la cual es
generalmente muy grande para ser completada en un solo Sprint. Los Epics son escritos en las etapas
iniciales del proyecto, en las que la mayoría de Historias de Usuario son funcionalidades de alto nivel
o descripciones del producto, y los requisitos están ampliamente definidos y basados en la Visión del
Proyecto. Por lo que es necesario desglosarla en Historias de Usuario (User Stories) más pequeñas
en algún punto del proyecto antes de implementarlas.
Estas Historias de Usuario no refinadas se colocan en el Product Backlog Priorizado. Una vez que
estas Epics sean propuestas para ser implementadas en el próximo Sprint, se descomponen en
Historias de Usuario pequeñas y más granulares. Estas pequeñas Historias de Usuario son
generalmente simples, cortas y fáciles de implementar o bloques de tareas que son completadas en
un Sprint.
El Product Owner es el responsable de crear las Epics y las Historias de Usuarios. Generalmente, el
Product Owner crea las Historias de Usuario, pero en algunos casos son desarrolladas por el Equipo
Scrum en coordinación con el Product Owner. Sin embargo, la responsabilidad de asegurar que los
requerimientos de negocio del cliente sean convertidos en requerimientos funcionales que el
desarrollador pueda entender fácilmente e implementar, es del Product Owner.
El Equipo Core Scrum puede hacer uso de muchas herramientas para crear eficientemente Epics y
podría considerar varios factores tales como Solicitudes de Cambio aprobados y no aprobados, Leyes
y Regulaciones, Contratos, etc. Algunas de estas herramientas utilizadas en el proceso Desarrollo de
Epic(s) son: Reunión de Grupo de Usuario, Talleres de Historia de Usuario, Reuniones de Grupos de
Opinión y Cuestionarios. Si bien en la creación de Epics, es importante identificar riesgos, el Equipo
Core de Scrum también podría utilizar una sería de técnicas de identificación de riesgos.
Otra salida principal a este proceso son las Personas. , las cuales son complementos a los Epics, dado
que ayudan al equipo a entender mejor a los usuarios y sus necesidades y objetivos. Personas son
personajes de ficción con descripción muy detallada que representan a la mayoría de los usuarios y
otros interesados que podrían no utilizar directamente el producto final, son creados para identificar las
necesidades de la base de usuarios destino. La creación de personas específicas puede ayudar al
equipo a identificar usuarios y entender sus necesidades y metas. Basado en una persona, un Product
Owner puede priorizar funcionalidades y crear un Product Backlog.
Una cita que ilustra las necesidades de la persona puede ser incluida también. A continuación se
muestra un ejemplo de una Persona para un sitio web de viajes.
Recopilación de Epics / Historias de Usuario
La recopilación de requisitos en la forma de Epics/Historia de Usuario es un esfuerzo continuo. Al inicio

del proyecto, el Product Owner colabora con el cliente para recopilar los requisitos, los cuales son de
alto nivel y no están claramente definidos en este punto. Las Epics serán articuladas y definidas más
adelante en el proyecto. Las brechas en la funcionalidad serán identificadas luego de algunas
iteraciones exitosas, y las Historias de Usuario serán escritas para completar estas brechas.
Un Product Owner puede tener muchas técnicas de recopilación de Epics/Historias de Usuario.

Algunas de ellas son las siguientes:
 Entrevista a los Usuarios- Una de las formas más comunes de descubrir requerimientos es
entrevistar diferentes tipos de usuarios de una aplicación o producto.
 Reunión de Grupo de Usuarios- Las reuniones de grupo de usuarios involucran a interesados

relevantes y proporcionan al equipo Core Scrum información de primera mano acerca de
expectativas de los usuarios. Esto ayuda en la formulación de los Criterios de Aceptación del
producto y da información valiosa para el desarrollo de Epics.
 Cuestionarios- Observar a un usuario de una aplicación puede ayudar a obtener

retroalimentación rápida acerca de áreas de mejora y descubrir requerimientos que podrían
ser olvidados o ignorados.
 Talleres de Historia de Usuario- Un Taller de Historia de Usuario puede ser un buen camino
para recopilar requerimientos. El taller involucra a todos los interesados relevantes. El equipo
escribe la mayor cantidad de historias posibles durante la sesión de tormenta de ideas.
1. Scrum Core Team* 1. Reunión de Grupo de 1. Epic(s) *

2. Declaración de la Visión del Usuarios * 2. Personas *
Proyecto * 2. Talleres de Historia de 3. Cambios Aprobados
3. Interesados Usuario 4. Riesgos Identificados
4. Product Backlog del 3. Reunión de Grupos de
Programa Opinión (Focus Group)
5. Solicitudes de Cambio
4. Entrevista a Usuarios o
Aprobadas
Clientes
6. Solicitud de Cambio no
Aprobadas 5. Cuestionarios
7. Riesgos del Portafolio y del 6. Técnicas de Identificación
Programa de Riesgos
8. Leyes y Regulaciones 7. Juicio Experto del Cuerpo
9. Contratos de Asesoramiento de
10. Información Previa del Scrum
Proyecto
de Scrum
PROCESO 5: CREAR LA LISTA DE REQUERIMIENTOS PENDIENTES DEL
PRODUCTO PRIORIZADA(CREATE PRIORITIZED PRODUCT BACKLOG)
Product Backlog
Este es un los procesos más importantes para el Product Owner. Luego que los Epics y Personas son
creados, el Product Owner crea la Lista Priorizada de Pendientes del Producto (Prioritized Product
Backlog). Esta lista es priorizada donde los elementos de mayor valor, es decir los que dan el máximo
valor comercial tienen la prioridad más alta.
El Product Backlog es una lista de requerimientos que, al convertirse en funcionalidad de

producto potencialmente comercializable, entregará la Visión del Producto.
Es responsabilidad del Product Owner elaborar el Product Backlog Priorizado inicial basado en los
Epics, Enunciado de la Visión del Proyecto, Requerimientos de Negocios e Interesados. El Product
Owner debe ser muy consciente de las necesidades y expectativas del negocio y de los requerimientos
del producto.
Un Product Backlog debería tener las siguientes características:
 Ser priorizado por valor, de modo que las características más importantes se construyan
primero.
 Se deben tener en cuenta todos los requisitos necesarios para completar el proyecto.
 Es dinámico y evoluciona constantemente.
 Sólo existe un Product Backlog, esto significa que se requiere que el Product Owner priorice
las tareas de todo el trabajo a realizar.
En el Product Backlog también se suelen incluir requisitos tales como correcciones de errores,
requerimientos no funcionales, y tareas que podrían no tener valor directo de negocio, sin embargo
deben ser realizadas.
Al comienzo de cualquier proyecto, el Product Backlog es poco probable que sea una lista clara y
articulada. En cambio, el Product Backlog probablemente tendrá muchos Epics (historias de alto nivel).
Es responsabilidad del Product Owner ordenar la lista, así todos los elementos serán claramente
definidos y entendidos por el equipo.
Prioriza los Elementos del Product Backlog (Product Backlog Items PBIs)
Priorizar el Product Backlog implica determinar la criticidad de una Historia de Usuario. A veces,
el cliente dirá “todos los elementos tienen alta prioridad”. Si bien puede ser cierto, no se podrá
tener un producto terminado.
Incluso una lista de elementos de alta prioridad debe ser priorizada. Mientras se prioriza se tiene
en cuenta estos tres factores: valor, riesgo e incertidumbre y dependencias.
1. Valor
Es responsabilidad del Product que se entreguen aquellos elementos más valiosos primero.
Incluso un elemento de gran valor podría no ser parte de la primera versión cuando hay un grupo
de elementos con valor más alto que son suficientes para la primera versión.
2. Riesgo e Incertidumbre
El riesgo es un aspecto inherente a cualquier negocio. El riesgo e incertidumbre están vinculados.

Cuando hay más incertidumbre el proyecto es más riesgoso. Por lo tanto, es importante que a los
elementos más riesgos se les asigne mayor prioridad. Los elementos riesgos también necesitarán
acciones de mitigación. Cuando las acciones de mitigación de riesgos son priorizadas en el
product backlog, este se convierte en Product Backlog priorizado ajustado a riesgos (Risk
Adjusted Prioritized Product Backlog).
3. Dependencias
No siempre es posible crear un Product Backlog en el que las Historias de Usuario no sean
dependientes entre sí. Los requerimientos funcionales a menudo dependen de otros
requerimientos funcionales e incluso no funcionales. Las dependencias pueden restringir la
libertad que tenemos mientras priorizamos el Product Backlog. Por lo tanto, es importante resolver
dependencias tanto como sea posible. Dos de las maneras más comunes de resolver
dependencias es o bien dividir una sólo historia en varias partes o combinar historias
interdependientes.
Herramientas Comunes de Priorización
 Esquema de Priorización MoSCoW—El esquema de priorización MoSCoW deriva su nombre

de las primeras letras de las frases "Must have" (Debe tener), “Should have” (Debería tener),
"Could have” (Podría tener), y "Would like to have, but not at this time” (Quisiera tenerlo, pero
no ahora). Las etiquetas están en orden decreciente de prioridad. "Debo tener" estas Historias
de Usuarios son aquellas que si no son incluidas en el producto, este no tendrá valor; y
"Quisiera pero no ahora" estas Historias de Usuarios son aquellas que, a pesar de que sería
bueno tenerlas, no es necesario incluirlas. “Would like to have” es a veces representado por
“Won´t have”.
 Comparación por Pares (Paired Comparison)— En esta técnica se prepara una lista de
todas las Historias de Usuarios del Product Backlog Priorizado. Luego, cada Historia de
Usuario se toma de forma individual y se compara con las otras Historias de Usuarios en la
lista, uno a la vez. Cada vez que dos Historias de Usuarios se comparan, se toma una decisión
sobre cuál de los dos es más importante. A través de este proceso, se puede obtener una lista
priorizada de las Historias de Usuarios.
 Método de los 100 Puntos (100-point method) — Fue desarrollado por Dean Leffingwell y
Don Widrig (2003). Se trata de dar al Cliente 100 puntos que puede usar para votar por las
Historias de Usuarios más importantes. El objetivo es dar más peso a las Historias de Usuarios
que son de mayor prioridad en comparación con las otras Historias de Usuarios disponibles.
Cada miembro del grupo asigna puntos a las diversas Historias de Usuarios, dando más puntos
a aquellas que consideran más importantes. Al finalizar el proceso de votación, la Priorización
se determina calculando el total de puntos asignados a cada Historia de Usuario.
Define el Criterio de Terminado (Done Criteria)
El criterio de Terminado se diferencia del Criterio de Aceptación en un aspecto principal. Mientras

que el Criterio de Aceptación son únicos por cada Historia de Usuario, el Criterio de Terminado
es un grupo de reglas que se aplican a todas las Historias de Usuario. Un Criterio de Terminado
genérico podría incluir:
 Ser revisado por otros miembros del equipo.
 Pasar por las pruebas unitarias de la Historia de Usuario.
 Satisfacer o exceder con éxito las pruebas de control de calidad.
 Completar toda la documentación relacionada a la Historia de Usuario.
 Finalizar con la corrección de todos los errores.
 Presentación exitosa del incremento del producto a los interesados y representantes del
negocio.
1. Scrum Core Team* 1. Métodos de Priorización de 1. Product Backlog Priorizado

2. Epic(s) * Historias de Usuarios * (Prioritized Product
3. Personas * 2. Talleres de Historia de Backlog)*
4. Interesados Usuario 2. Criterio de Terminado
5. Declaración de la Visión del 3. Planificación de Valor (Done Criteria)*
Proyecto 4. Técnicas de Evaluación de
Riesgo
Programa
5. Estimación de Valor del
7. Requisitos del Negocio
8. Solicitudes de Cambio Proyecto
Aprobadas 6. Métodos de Estimación de
9. Riesgos Identificados Historias de Usuario
10. Contratos 7. Juicio Experto del Cuerpo
11. Recomendaciones del de Asesoramiento de
Cuerpo de Asesoramiento Scrum
de Scrum
PROCESO 6: REALIZAR LA PLANIFICACIÓN DE LAS VERSIONES (CONDUCT

RELEASE PLANNING)
Crea el Cronograma de Planificación de Versiones
En este proceso, el Equipo Core de Scrum trabaja elaborando el Cronograma de Planificación de las
Versiones (Release Planning Schedule) para entregar incrementos de producto a los interesados. El
Cronograma de Planificación de las Versiones indica qué entregables serán liberados a los clientes,
junto con los intervalos planeados y las fechas de cada versión. Es responsabilidad del Product Owner
definir la estrategia de versiones y asegurar que esta sea comunicada y entendida por el equipo.
Estrategia de Versiones basada en la Funcionalidad - Si la estrategia de versiones está basada en

la funcionalidad, entonces el producto debe ser lanzado lo antes posible. Sin embargo, debe haber
suficiente valor en el producto para ser liberado efectivamente. El Product Owner define el producto
mínimos comercializable (Minimun Marketable Feature MMF), también llamado Primera Entrega
Factible (First Feasible Delivery FFD), como la mínima funcionalidad necesaria para el lanzamiento
inicial. Si el Product Backlog inicial es priorizado correctamente, entonces el MMF incluirá las “x”
características más importantes en el Product Backlog.
La velocidad del equipo es un criterio importante para decidir los plazos para la versión. Una vez que
se escoja la longitud del Sprint y las Historias de Usuario de alta prioridad sean estimadas, la velocidad
histórica del equipo es utilizada para identificar cuánto trabajo el equipo podría completar en un Sprint
particular. Si es el primer proyecto donde se utiliza Scrum, entonces se tendrá que dar la mejor
estimación de cuánto trabajo se puede ejecutar en un Sprint. La velocidad del equipo se ajusta durante
la ejecución del proyecto basada en la experiencia.
Estrategia de Versiones basada en Fechas- Si la estrategia de versiones está impulsada por la
fecha, entonces no es posible definir un MMF. Si hay una fecha límite fija, como presentar el producto
en una audiencia de prueba en una fecha determinada, entonces el objetivo es proporcionar el producto
funcionando con mayor valor posible en el plazo determinado. En este caso, es crucial que el Product
Owner realice un buen trabajo identificando las características con más alto valor.
Directivas para las Versiones
 Cada versión debe proporcionar valor significativo para el cliente.
 Cada Sprint debe tener una funcionalidad potencialmente comercializable como salida. A las
características con alto valor en el negocio se les debe dar la más alta prioridad en el Product
Backlog y deben ser desarrolladas primero. Esto garantiza que el valor más alto posible se
proporciona al final de cada iteración.
 Las interdependencias entre las características, así como otras precondiciones de los
elementos del Product Backlog, como la infraestructura, que podrían no ser requisitos
explícitos en una Historia de Usuario, necesitan ser consideradas en la planificación. Estos son
incluidos en el Product Backlog como elementos no funcionales. Esto garantiza que cada
salida puede ser utilizada inmediatamente.
Ayuda a determinar la Duración del Sprint
La duración del Sprint es determinada por el tiempo mínimo que se necesita para crear
incrementos de producto que generen valor al negocio. Esta una decisión estratégica basada en
la experiencia del Equipo Scrum y las consideraciones del desarrollo del producto. Una vez que la
duración del Sprint es fijada, normalmente no cambia en el proyecto. Podría ser modificada en medio
del proyecto debido a mejoras en el ambiente del proyecto y en la velocidad del equipo. Para elaborar
el Cronograma de Planificación de Versiones y para fijar la duración del Sprint se utilizan varias
entradas como las de los interesados, Declaración de Visión del Proyecto, Product Backlog Priorizado,
Requerimientos de Negocio y calendario de feriados.
Un Sprint puede durar entre 1 y 6 semanas. Sin embargo para obtener el máximo beneficio de un
proyecto Scrum se recomienda mantener la duración del Sprint en 4 o menos semanas, a menos que
el proyecto tenga requerimientos estables, donde los Sprints puede ser ampliados a 6 semanas.
1. Scrum Core Team* 1. Sesiones de Planificación 1. Cronograma de
2. Interesados* de las Entregas* Planificación de las
3. Declaración de la Visión del 2. Métodos de Priorización de Entregas*
Proyecto * las Entregas * 2. Duración del Sprint *
4. Product Backlog 3. Clientes Objetivo para el
Priorizado * Lanzamiento
5. Criterio de Terminado * 4. Product Backlog Priorizado
6. Product Owner del y Refinado
Programa
7. Scrum Master del
Programa
8. Jefe del Product Owner
Programa
10. Requisitos del Negocio
11. Calendario de Feriados
de Scrum
PREGUNTAS - CAPÍTULO FASE: INICIAR
1. ¿Cuál de las siguientes afirmaciones no es verdadera para el Product Backlog?

a. El Product Backlog es priorizado de manera que el equipo construye las
características más valiosas primero.
b. El Product Backlog es dinámico y evoluciona en el proyecto.
c. Los elementos del Product Backlog son priorizados basados en la complejidad.
d. El Product Backlog es constantemente repriorizado para incorporar requerimientos

emergentes del cliente.
2. ¿Cuál es la regla para el ordenamiento de los elementos en el Product Backlog?

a. Los elementos más pequeños en la parte superior.
b. Los elementos con menos interdependencias en la parte superior.
c. Los elementos más complejos en la parte superior.
d. Los elementos con mayor valor de negocio en la parte superior.
3. Los Epics pueden ser definidos como:
a. Historias de Usuario grandes.
b. Historias de Usuario con alto valor de negocio.
c. Historias de Usuario más importantes.

d. Ninguna de las anteriores.
4. ¿Cuál de las siguientes afirmaciones NO es correcta?
a. Las Historias de Usuario son cortas, tienen una descripción simple de la
funcionalidad deseada.
b. Las Historias de Usuario generalmente tienen la perspectiva del desarrollador.
c. Las Historias de Usuario pueden ser escritas en distintos niveles de detalle.
d. Las Historias de Usuario, cuando son desarrolladas, genera funcionalidades del
producto.
5. Todas las siguientes preguntas son respondidas por la Visión del Producto, EXCEPTO:
a. ¿Quién es el cliente objetivo?

b. ¿Cuál es la categoría del producto?
c. ¿Cuál es nuestro principal punto de venta?
d. ¿Cómo la Visión del Producto concuerda con el desarrollo del producto?
6. ¿Cuál de las siguientes afirmaciones NO es un factor en la priorización del Product Backlog?

a. Factibilidad
b. Riesgo
c. Complejidad
d. Dependencias
7. ¿Cuál de las siguientes afirmaciones NO son verdaderas respecto a la planificación de las
versiones?
a. Una funcionalidad puede ser liberada sólo si cumple los criterios de aceptación
definidos por el Product Owner.
b. El Equipo Scrum y el Product Owner tienen la autoridad para aceptar y rechazar la

funcionalidad desarrollada.
c. Una funcionalidad desarrollada en una iteración no será entregada al cliente hasta el
final de la iteración.
d. La versiones están ordenadas de forma lógica para garantizar que se aborden las
interdependencia entre las características.
8. ¿Cuándo el Product Owner libera una funcionalidad?
a. Cuando el Equipo Scrum decida.
b. Después de cada Sprint.

c. Después de cada Sprint alternativo.
d. De acuerdo a las necesidades del cliente.
FASE: PLANEAR Y ESTIMAR
Como parte de esta fase, el Equipo Core de Scrum crea, aprueba, estima y se compromete con un
grupo de Historias de Usuarios, adicionalmente crea y estima tareas, finalmente crea el Sprint Backlog.
PROCESO 1: CREAR HISTORIAS DE USUARIOS (CREATE USER STORIES)
Ayuda a Crear Historias de Usuario
Las Historias de Usuario eliminan la necesidad de la documentación detallada de los requerimientos

del cliente. Son escritas en lenguaje que el negocio entiende. La responsabilidad de crear las Historias
de Usuario recae en el Product Owner. Generalmente el Product Owner crea las Historias de Usuario,
pero en algunos casos estos son creados por el Equipo Scrum en coordinación con el Product Owner.
Las Historias de Usuario son descripciones breves de la funcionalidad del negocio desde un punto de
vista del usuario. Esta herramienta fuerza a los interesados a identificar al usuario (o persona) y la
razón de negocio de cada funcionalidad.
El formato típico de una Historia de Usuario es el siguiente:
Como <rol del usuario> deseo <descripción del requerimiento> para <beneficio>.
Las Historias de Usuario son escrito en lenguaje claro y sencillo y son descripciones cortas acerca de
la funcionalidad deseada desde la perspectiva del usuario final.
Este es un ejemplo de una Historia de Usuario de tamaño Epic:
“Como un usuario avanzado, deseo tener permisos administrativos, para que pueda realizar
funciones administrativas.”
Una Historia de Usuario tiene naturaleza iterativa y podría ser escrita frecuentemente durante el
proyecto. Cuando una Historia de Usuario es demasiado grande para que el Equipo Scrum la pueda
completar en un solo Sprint, es considerada un Epic, y se dividirá en muchas varias Historias de
Usuario antes que sea implementada. El Epic del ejemplo anterior, podría ser dividido en docenas ( o
posiblemente cientos), incluyendo los siguientes:
 “Como un usuario avanzado, deseo tener permisos administrativos, para que pueda asignar a un
usuario permisos de lectura, escritura o modificación.”
 “Como un usuario avanzado, deseo tener permisos administrativos, para que pueda añadir o
eliminar nuevos usuarios.”
Las Historias de Usuario puede estar asociadas como Temas (“Themes”). Un Tema (Theme) es una
colección de Historias de Usuarios. Los Temas pueden contener uno o más Epics. Muchos Temas
pueden estar asociados con un producto, pero un Tema no puede estar relacionado con más un
producto a la vez.
Criterio para una Historia de Usuario bien elaborada
Podemos utilizar el acrónimo INVEST para entender las características de una Historia de Usuario bien
escrita. El acrónimo significa: Independent, Negotiable, Valuable, Estimable, Small y Testable.
 Independent (Independiente) — El objetivo de escribir Historias de Usuario es hacer que

cada una de estas sea independiente y autónoma. Esto es importante, porque ayuda al
Product Owner a evaluar e incluir Historias de Usuario en el Product Backlog Priorizado basado
en el valor de cada uno.
A menudo las Historias de Usuarios dependen intrínsecamente una de otra. En tales
situaciones, no estará claro qué historia debe tener la estimación más alta. Una forma de
solucionar esta situación es combinar estas historias en una historia independiente y grande.
Si alguna de las funcionalidades requeridas ya fue creada o está siendo implementada,
entonces la estimación debe ser revisada para reflejar este cambio. También, es importante
definir una Historia de Usuario no funcional que define las precondiciones de cada una de las
dependencias.
 Negotiable (Negociable) — Una Historia de Usuario no debe ser inamovible y debe tener
margen suficiente para permitir la negociación entre el Equipo Scrum y el equipo de negocio.
A veces el equipo de negocio sacrificará funcionalidades debido a las limitaciones de
presupuesto, o el Equipo Scrum podría tener que convencer al equipo de negocio a
incrementar el presupuesto cuando una característica crítica del usuario es requerida a pesar
de las restricciones presupuestarias.
 Valioso (Valuable) — Es importante que cada característica en el Product Backlog tenga valor.
Decir que una característica tiene valor no significa necesariamente que esta tiene valor en
términos definidos por el usuario final. Algunas características podrían trabajar en un segundo
plano (no visible) o podría indirectamente soportar otras funcionalidades que el usuario
requiere, por lo que estas características todavía tienen valor. Este valor deber ser considerado
por el Product Owner para que pueda priorizarlo e incluirlo en el Product Backlog.
 Estimable (Estimable) — Una de las características de una buena Historia de Usuario es que
fácilmente se puede estimar. Las estimaciones no tienen que ser precisas, pero deben lo
suficientemente buenas para utilizarlas en la priorización. Historias de Usuario grandes son
difíciles de estimar, e historias pequeñas son generalmente fáciles de estimar. Las Historias
que son difíciles de estimar pueden indicar problemas de fondo – podría ser que la Historia es
muy grande o podría no reflejar con claridad lo que la Historia de Usuario necesita satisfacer.
 Pequeño (Small) — Una Historia de Usuario pequeña es relativamente fácil de estimar. Son
más sencillas de hacer seguimiento y por lo general pueden ser completadas dentro de una
iteración. Historias grandes tardan más tiempo, y los retrasos toman más tiempo reportar.
Cuando el Product Owner está tratando de crear historias que tienen el tamaño adecuado, él
o ella debe considerar la experiencia y capacidades del Equipo Scrum.
 Verificable (Testable) — Si una Historia de Usuario no puede ser probada y su funcionalidad

verificada, entonces será difícil de evaluar si esta puede ser considerada como Terminada. El
Criterio de Aceptación de la Historia de Usuario debe estar claramente definido antes de
determinar si es o no verificable.
Diferencia entre una Historia de Usuario y un Caso de Uso
La diferencia básica entre una Historia de Usuario y un Caso de Uso radica en la perspectiva y la
intención, la cual afecta el nivel de detalle capturado.
El Caso de Uso se enfoca en las interacciones entre un sistema y uno o más actores, donde un
actor puede ser un usuario u otro sistema. El Caso de Uso describe un proceso y sus pasos con
el detalle suficiente, de modo que puede ser entendido por si mismo. La descripción de las
interacciones, normalmente, tiene un formato de llamada y respuesta.
Por otro lado, la Historia de Usuario se concentra en los valores del usuario y es mucho más ligera
que el Caso de Uso. Proporciona suficiente detalle para que el lector pueda comprender la
funcionalidad en general que fue identificada. Se promueve el uso del lenguaje cotidiano para
asegurar que la Historia de Usuario sea comprendida por desarrolladores y cliente. A diferencia
con el Caso de Uso, una Historia de Usuario es un recordatorio para tener una conversación con
tu cliente.
Criterio de Aceptación
Junto con las Historias de Usuario, el Product Owner define los criterios de aceptación, que son
los criterios de éxito de cada Historia de Usuario.
Los criterios de aceptación claramente definidos son cruciales para la entrega oportuna y eficaz
de las Historias de Usuario las cuales en última instancia determinar el éxito del proyecto. Estos
son escritos y definidos por el Product Owner. Deben describir explícitamente las condiciones que
las Historias de Usuario deben satisfacer.
Los criterios de aceptación son únicos para cada Historia de Usuario. Por ejemplo, una Historia
de Usuario para crear un sitio web en línea para un supermercado podría ser la siguiente:
“Como un comprador en la tienda en línea, debería ser capaz de añadir y/o eliminar elementos
del carrito de compras antes de comprometer la venta, para que pueda estar seguro de tener
presupuesto.”
Los criterios de aceptación para esta Historia de Usuario podrían ser escritos de esta forma:
 El carrito de la compra tiene que actualizarse automáticamente cuando un usuario agrega un

elemento.
 Un usuario puede eliminar/modificar exitosamente los contenidos del carrito de compras
desde una sola ventana.
 Los elementos del carrito de compras son guardados hasta que el usuario borre su contenido
o cierra la sesión del sitio web sin guardar.
Es importante para el Product Owner tener en cuenta que las Historias de Usuario que cumplan
con la mayoría, pero no todos, de los criterios de aceptación no pueden ser aceptadas como
terminados.
Estimación de Historias de Usuarios es un trabajo en equipo- El Product Owner prioriza las

Historias de Usuario de acuerdo al valor del negocio. Esto se hace a nivel del proyecto, así como
a nivel de cada iteración. Cuando la Historia de Usuario forma parte del Product Backlog, el equipo
la estima. Las Historias de Usuario son estimadas en Puntos de Historia (story points). Un punto
de historia está relacionado al esfuerzo requerido para desarrollar una sola unidad de producto
con la complejidad menos relativa. Por lo tanto, un punto de historia se traduce en una unidad de
producto. Los factores que influyen en el proceso de estimación incluyen al número de
requerimientos en el Product Backlog, la complejidad de las Historias de Usuario e incertidumbre
y riesgos.
Estas estimaciones son cruciales, porque el Product Owner se basa en ellas para la planificación
de las versiones. La estimación es una actividad importante de equipo, ya que las estimaciones
permiten predecir los resultados del proyecto.
1. Scrum Core Team* 1. Experiencia en la Escritura 1. Historias de Usuarios *
2. Product Backlog de Historias de Usuario * 2. Criterios de Aceptación de
Priorizado* 2. Talleres de Historia de la Historia de Usuario *
3. Criterio de Terminado * Usuario 3. Product Backlog Priorizada
4. Personas * 3. Reuniones de Grupo de y Actualizada
5. Interesados Usuarios 4. Personas Actualizadas y
6. Epic(s) 4. Reuniones de Grupo Refinadas
7. Requisitos del Negocio Focales
8. Regulaciones y Leyes 5. Entrevistas al Cliente /
9. Contratos Usuario
10. Recomendaciones del 6. Cuestionarios
Cuerpo de Asesoramiento 7. Métodos de Estimación de
de Scrum Historia de Usuarios
8. Juicio Experto del Cuerpo
de Asesoramiento de
Scrum
PROCESO 2: APROBAR, ESTIMAR Y COMPROMETERSE CON LAS

HISTORIAS DE USUARIOS (APPROVE, ESTIMATE, AND COMMIT USER
STORIES)
Aprueba Historias de Usuario
Después que las Historias de Usuarios son creadas, tienen que ser aprobadas por el Product
Owner. El Product Owner evalúa las Historias de Usuarios de acuerdo al nivel de satisfacción de
los requerimientos de negocio y verificando si cumplen con sus respectivos Criterios de
Aceptación.
Estimando Historias de Usuario (Equipo Scrum)
Después de que las Historias de Usuarios son aprobadas por el Product Owner, el Equipo Core
Scrum comienza el trabajo de estimación de estas. Estimar los recursos requeridos y el tiempo
con precisión es un aspecto crítico en cualquier organización para garantizar una buena
experiencia de la entrega del proyecto para el cliente. Sin embargo, las estimaciones, por
definición, no son precisas. La precisión de la estimación varia de acuerdo a la complejidad del
proyecto, el tamaño, disponibilidad del equipo, la prioridad del equipo, la volatilidad de los
requerimientos, etc. El Equipo Scrum puede utilizar diversas herramientas y técnicas de
estimación, que incluyen Wideband Delphi, Planning Poker y Estimación Relativa.
Facilita al Equipo Scrum y Compromete Historias de Usuario
Después de la estimación, el Equipo Scrum se compromete desarrollar un grupo de Historias de

Usuario aprobadas y estimadas para el siguiente Sprint.
Cabe señalar que es responsabilidad del Product Owner asegurar que las Historias de Usuarios
aprobadas ofrezcan valor y satisfagan las necesidades y requerimientos de los interesados en el
proyecto. Una vez aprobadas, las Historias de los Usuarios son estimadas por el equipo. Las
Historias de Usuarios aprobadas y estimadas que el Equipo Scrum cree que puede completar en
el siguiente Sprint son comprometidas, en consulta con el Product Owner y forman parte del Sprint
Backlog.
1. Scrum Core Team* 1. Reunión del Grupo de 1. Historias de Usuarios

2. Historias de Usuarios * Usuarios * Aprobadas, Estimadas y
3. Criterios de Aceptación de 2. Planificación Poker Comprometidas *
Historia de Usuario* 3. Puño de Cinco
4. Recomendaciones del 4. Estimación de Puntos de
Cuerpo de Asesoramiento Costo
de Scrum 5. Otras Técnicas de
Estimación
6. Juicio Experto del Cuerpo
de Asesoramiento de
Scrum
PROCESO 3: CREAR TAREAS (CREATE TASKS)
Explica las Historias de Usuario al Equipo Scrum mientras crean la Lista de Tareas
En este proceso, el Equipo Scrum se dedica a desglosar las Historias de Usuario en tareas o
actividades. El rol del Product Owner es ayudar a clarificar las Historias de Usuario y requerimientos
para permitir al equipo capturar adecuadamente las tareas necesarias para las Historias de Usuario
comprometidas en el Sprint actual.
Reunión de Planificación de Tareas (Task Planning Meeting)
Para que los miembros del Equipo Scrum, Creen Tareas, una Reunión de Planificación de Tareas se
lleva a cabo para revisar las Historias de Usuario Comprometidas a detalle para eliminar ambigüedades
y resolver todas las preguntas. La creación de tareas se realiza durante la Reunión de Planificación de
Tareas. Esta reunión está dividida en dos partes:
•El Product Owner sugiere Historias de Usuario que deben formar parte del
Sprint.
•El Equipo Scrum determina cuántas Historias de Usuario pueden ser
ejecutadas en un Sprint.
Primera •Se alcanza consenso en las Historias de Usuario que serán incluídas en el
Parte Sprint.
• El Equipo Scrum determina cómo convertir las Historias de Usuario

seleccionadas en Incrementos de Producto desglosándolas en tareas.
Segunda •El Equipo Scrum se compromete con los entregables del Sprint.
Parte
El Product Owner es el jugador principal en la primera parte de la reunión. Ya ha priorizado los

elementos del Product Backlog y debe utilizar parte de esta reunión para explicar los elementos con
mayor prioridad que desearía tenerlos en el siguiente Sprint al Equipo Scrum. El Scrum Master y el
Scrum Team son los principales asistentes. Durante esta reunión, el Product Owner alinea las
expectativas de los interesados con las del Equipo Scrum. Mientras que los interesados desean que el
equipo desarrolle el producto teniendo en cuenta el tiempo estimado, los recursos financieros y
humanos disponibles; el Equipo Scrum necesita medir la viabilidad de las tareas desde un punto de
vista técnico. Por lo tanto, se requiere información de los interesados, no sólo para que el Equipo Scrum
organice su trabajo, sino también para asegurar que la funcionalidad a desarrollar sea factible y
rentable cuando se implemente.
El objetivo del Equipo Scrum es alcanzar un consenso en las Historias de Usuario que serán incluidas
en el Sprint.
En la segunda parte de la Reunión de Planificación de Tareas (Task Planning Meeting), el Equipo

Scrum determina cómo convertir las Historias de Usuario seleccionadas en Incrementos de Producto
desglosándolas en tareas. La principal salida de esta reunión es la Lista de Tareas, la cual contiene
las tareas comprometidas por el Equipo Scrum para el Sprint.
1. Scrum Core Team* 1. Reunión de Planificación 1. Lista de Tareas *
2. Historias de Usuario de Tareas* 2. Historias de Usuarios
Aprobadas, Estimadas y 2. Tarjetas Aprobadas, Estimadas,
Comprometidas * 3. Descomposición Comprometidas y
4. Determinación de Actualizadas
Dependencias 3. Dependencies
PROCESO 4: ESTIMAR LAS TAREAS (ESTIMATE TASKS)
Proporciona Orientación y Clarificación al Equipo Scrum en la Estimación de las Tareas
Una vez que la Lista de Tareas esté lista, el Equipo Scrum estima las tareas. Este proceso es crítico
para los miembros del Equipo Scrum para estimar el esfuerzo necesario para realizar cada tarea y así
planear la forma de proceder. La estimación es hecha tomando en cuenta la duración y el esfuerzo
requerido para convertir las tareas en entregables. “Esfuerzo” hace referencia tanto al personal como
a otros recursos requeridos para completar las tareas dentro de un Sprint. El Product Owner no debe
interferir en este proceso, sin embargo brinda orientación y clarificación al Equipo Scrum para estimar
las tareas.
Reuniones de Estimación de Tareas (Task Estimation Meeting)
Para estimar las tareas, el Equipo Scrum puede utilizar varias técnicas de Estimación. Es
importante que el Equipo Scrum trabaje con Criterios de Estimación consensuados. El objetivo
principal es utilizar los Criterios de Estimación para mantener tamaños relativos de estimación y
minimizar la necesidad de re-estimación. Los Criterios de Estimación pueden ser expresados de
muchas formas, dos ejemplos comunes son los Puntos de Historia y tiempo ideal.
La salida más importante de este proceso es la Lista del Esfuerzo Estimado de las Tareas, la cual
es una lista tareas relacionadas con sus Historias de Usuario Comprometidas que forman parte
del Sprint. Normalmente, la precisión de los estimados varía de acuerdo a destreza del equipo.
Es esfuerzo estimado es expresado en términos de los criterios de estimados acordados por el
equipo. La Lista de Esfuerzo Estimado de las Tareas es utilizada por el Equipo Scrum durante las
Reuniones de Planificación del Sprint para crear el Sprint Backlog y el Sprint Burndown Chart.
La Reunión de Planificación de Tareas (Task Planning Meeting) y la de Estimación de Tareas

(Task Estimation Meeting), por lo general, son llevadas a cabo como parte de la Reunión de
Planificación del Sprint (Sprint Planning Meeting).
1. Scrum Core Team* 1. Reuniones de Estimación de 1. Lista del Esfuerzo
2. Lista de Tareas * Tareas * Estimado de Tareas*
3. Criterios de Aceptación de 2. Criterios de Estimación * 2. Lista de Tareas
las Historias de Usuario 3. Planificación Poker Actualizadas
4. Dependencias 4. Puño de Cinco
5. Riesgos Identificados 5. Otras Técnicas de
6. Recomendaciones del Estimación
de Scrum
PROCESO 5: CREAR LA LISTA DE PENDIENTES DEL SPRINT (CREATE

SPRINT BACKLOG)
Ayuda al Equipo Scrum crear el Sprint Backlog
Este es el ultimo proceso de la fase de Planificación y Estimación. El Sprint Backlog es creado

durante la Reunión de Planificación de Sprint (Sprint Planning Meeting). Después de que la Lista
del Esfuerzo Estimado de Tareas haya sido elaborada, el Equipo Core de Scrum toma los
elementos de la Lista de Tareas para revisarlos a detalle. Cada miembro del Equipo selecciona
las tareas que planea trabajar durante el Sprint. Desde que el Equipo Scrum es auto-organizado,
la decisión de quién trabajará en qué es hecha por los Miembros del Equipo. Ni el Product Owner
ni el Scrum Master dan instrucciones al equipo sobre qué elementos deben trabajar y cómo tienen
que hacer su trabajo. El Product Owner es el puente entre el Equipo Scrum y los interesados
mientras que el Scrum Master es el líder facilitador y mentor del Equipo Scrum.
Durante un Sprint, es posible que nuevas tareas podrían ser descubiertas, las cuales son
necesarias para el desarrollo de la funcionalidad prevista. También es posible que las tareas
previamente identificadas pueden no ser necesarias.
En consecuencia, el Equipo Scrum modifica el Sprint Backlog. Algunos equipos incluyen algunas
tareas adicionales como tareas de respaldo durante un Sprint, que se pueden ejecutar si el equipo
completa las tareas asignadas y tiene capacidad libre. El Product Owner podría revisar qué
elementos del Product Backlog priorizado pueden ser añadidos a Sprint actual.
Las principales salidas de este son el Sprint Backlog y el Gráfico Sprint Burndown.
1. Sprint Backlog (Lista de Pendientes del Sprint)
Es la lista de las tareas a ser ejecutadas por el Equipo Scrum en el próximo Sprint. Es una
práctica común que el Sprint Backlog se muestre en un Scrumboard o tablero de tareas, este
proporciona una representación visible y constante de la situación de las Historias de Usuarios
en el backlog. Como Product Owner, este podría ser un artefacto importante para regularmente
revisar el estado del proyecto y debería estar ubicado en un lugar de fácil acceso para todo el
Equipo Core de Scrum. También se incluyen en el Sprint Backlog algunos Riesgos asociados
con las diversas tareas. Las actividades de mitigación a los riesgos identificados podrían ser
incluidas como tareas en el Sprint Backlog.
Un Scrumboard estándar contiene 4 columnas que indican el progreso de las tareas estimadas
para el Sprint: la columna “Pendiente” (“To Do”) para las tareas que aún no empiezan, la
columna “En Progreso” (“In Progress”) para tareas que empezaron pero no han sido
completadas aún, la columna “En Pruebas” (“Testing”) para tareas que han sido completadas
pero se encuentran en el proceso de ser probadas y la columna “Terminado” (“Done”) para
tareas terminadas y probadas exitosamente. Una columna opcional es la quinta: “Stories”. Al
inicio del Sprint, todas las tareas se colocan en la columna “To Do” y se van moviendo a las
columnas siguientes de acuerdo al avance.
La siguiente figura muestra un ejemplo de un Scrumboard:
2. Sprint Burndown Chart – Es un gráfico que muestra la cantidad de trabajo que queda por
hacer en el Sprint actual. El Gráfico Sprint Burndown inicial es acompañado por un Burndown
planeado. El Gráfico Sprint Burndown debe actualizarse al final de cada día laborable.
La siguiente figura muestra un ejemplo del Sprint Burndown Chart:
 Este gráfico muestra el trabajo estimado pendiente (en el eje Y) y el tiempo (en el eje X).
 Al final del día, los miembros del Equipo Scrum actualizan el gráfico con el trabajo
completado.
 El gráfico Sprint Burndown es un buen indicador de la velocidad del equipo en el Sprint

actual y permite hacer pronósticos para saber si el equipo podrá completar o no todas las
Historias de Usuario comprometidas.
 La línea discontinua en el gráfico indica la tendencia ideal, y la línea continua representa

la tendencia real. La región por encima de la línea discontinua es la zona de peligro que
indica un retraso en la finalización de la tarea. La región por debajo de la línea discontinua
indica que el equipo podría haber sobreestimado el esfuerzo necesario y puede tener
capacidad libre en el Sprint.
Una vez que el Sprint Backlog se haya finalizado y el Equipo Scrum se haya comprometido al
mismo, no deben añadirse nuevas Historias de Usuarios; sin embargo, puede ser necesario
añadir las tareas que pueden haberse pasado por alto o ignorado de las Historias de Usuario
comprometidas. Si surgen nuevas necesidades durante un Sprint, se añadirán al Product
Backlog Priorizado y se incluirán en un Sprint posterior.
1. Scrum Core Team* 1. Reunión de Planificación 1. Sprint Backlog *

2. Lista del Esfuerzo Estimado del Sprint (Sprint Planning 2. Sprint Burndown Chart*
de Tareas* Meeting) *
3. Duración del Sprint * 2. Herramientas de
4. Velocidad del Sprint Previo Seguimiento del Sprint
5. Dependencias 3. Métrica de Seguimiento del
6. Calendario del Equipo Sprint
PREGUNTAS - CAPÍTULO FASE: PLANEAR Y ESTIMAR
1. ¿Cuál de los siguientes atributos NO aplica a las Historias de Usuario?
a. Negociable (Negotiable)
b. Verificable (Testable)
c. Estimable (Estimative)
d. Técnico
2. ¿Cuál de las siguientes NO es correcta?
a. El Product Owner asegura que el equipo siga los principios Scrum.
b. El Product Owner es responsable de evaluar la viabilidad del producto.
c. El Product Owner inspecciona el entregable para validar los criterios de

aceptación.
d. El Product Owner representar a un única voz en la decisión de los criterios del

producto.
3. ¿Quién de los siguientes es responsable de lograr el máximo valor de negocio del

proyecto?
a. Scrum Master
b. Product Owner
c. Equipo Scrum
d. Interesados externos
4. ¿Cuáles son las dos tareas más importantes ejecutadas por el Product Owner?
a. Desarrollo del producto
b. Creación del Product Backlog
c. Definición de los criterios de aceptación
d. Estimación de las Historias de Usuario
5. ¿Cuál de las siguientes dos alternativas son ciertas respecto al rol del Product Owner en
la Reunión de Planificación del Sprint (Sprint Planning Meeting)?
a. El Product Owner juega un rol importante en ambos segmentos del la Reunión de

Planificación del Sprint.
b. El Product Owner alinea las expectativas del Equipo Scrum con las de los
interesados.
c. El Product Owner explica los elementos con alta prioridad al equipo.
d. El Product Owner protege al equipo de interferencia externa.
6. ¿Cuál de las siguientes NO es responsabilidad del Product Owner?
a. Visión del Producto
b. Definición objetiva
c. Cronograma de Versiones
d. Estimación de Tareas
7. ¿Cuál de las siguientes NO es una actividad de la Reunión de Planificación del Sprint

(Sprint Planning Meeting)?
a. El Product Owner explica las Historias de Usuario al Equipo Scrum.
b. El Equipo Scrum en consulta con el Product Owner, estima las tareas de un Sprint
dado.
c. Basadas en las estimaciones, el Equipo Scrum se compromete con pocas

Historias de Usuario para ser completadas en el próximo Sprint.
d. El Equipo Scrum obtiene retroalimentación de los interesados.
FASE: IMPLEMENTAR
La fase de Implementar abarca las ejecución de las tareas y actividades para crear el producto,
servicio o resultado del proyecto. Estas actividades incluyen la creación de varios entregables,
llevar a cabo la Reunión diaria y el mantenimiento del Product Backlog (es decir revisar, ajustar y
actualizar periódicamente).
PROCESO 1: CREAR ENTREGABLES (CREATE DELIVERABLES)
Clarifica los Requerimientos de Negocio al Equipo Scrum
En este proceso es donde principalmente se realizan los trabajos de desarrollo. El Equipo Scrum
es responsable de la creación de los Entregables del Sprint (Sprint Deliverables), mientras que el
Product Owner y el Scrum Master también tienen un rol importante en este proceso.
 El Product Owner es un puente entre el Equipo Scrum y los Interesados, proporcionando
a los miembros del Equipo Scrum la información necesaria que necesitan mientras
desarrollan los entregables Sprint.
 El Scrum Master es responsable de asegurar un ambiente propicio para el desarrollo del
trabajo de los entregables del Sprint.
El esfuerzo principal de desarrollo recae en el Equipo Scrum, y como este es auto-organizado y

multi-funcional, la decisión de cómo desarrollar algunas tareas recae en los miembros del Equipo
Scrum. Ni los interesados, ni el Scrum Master, tampoco el Product Owner pueden dirigir al equipo
en la forma de desarrollar los entregables. Los miembros del Equipo Scrum son expertos en sus
dominios, y su juicio y experiencia son aplicadas a todos los aspectos técnicos y de gestión del
proyecto durante este proceso.
La salida más importante de este proceso es el entregable del Sprint, también conocido como el
incremento del producto, el cual satisface todas las características y funcionalidades definidas en
las Historias de Usuario del Sprint. Si los miembros del Equipo Scrum enfrentan cualquier
obstáculo mientras completan los entregables del Sprint, ellos los registran en el Registro de
Impedimentos (Impediment Log). Un Registro de Impedimentos es mantenido por el Scrum
Master, y es su responsabilidad resolver los problemas y eliminar los impedimentos.
Cuando el Product Owner quiere hacer cambios en medio del Sprint, el alcance del Sprint en curso
no puede ser modificado. Si el cambio que se requiere es tan importante que el resultado del
Sprint en curso podría ser inútil sin hacer estas modificaciones, entonces el actual Sprint debería
ser terminado, y un nuevo Sprint que incorpora el cambio debe ser iniciado. Caso contrario, el
cambio será incluido en un Sprint posterior.
Si la estimación del equipo para el Sprint fue significativamente incorrecta, entonces el equipo, o
bien tendrá capacidad libre para implementar Historias de Usuario (si es una sobreestimación) o
no será capaz de completar las Historias de Usuario comprometidas (si es una subestimación).
En cualquier caso, el equipo debería consultar al Product Owner la forma de proceder. El Product
Owner debe tomar una decisión de negocio respecto a qué elementos adicionales del Product
Backlog deben ser añadidos al Sprint actual (si el equipo tiene capacidad libre) o qué Historias de
Usuario pueden quedar pendientes (si el equipo no tiene suficiente capacidad).
1. Scrum Core Team* 1. Experiencia del Equipo* 1. Entregables del Sprint
2. Sprint Backlog * 2. Software (Sprint Deliverables)*
3. Scrumboard* 3. Otras Herramientas de 2. Scrumboard Actualizado*
4. Impediment Log* Desarrollo 3. Impediment Log
5. Cronograma de 4. Juicio Experto del Cuerpo Actualizado*
Planificación de la Entrega de Asesoramiento de 4. Solicitudes de Cambio no
6. Dependencias Scrum Aprobadas
7. Recomendaciones del 5. Riesgos Identificados
Cuerpo de Asesoramiento 6. Riesgos Mitigados
de Scrum 7. Dependencias
Actualizadas
PROCESO 2: REALIZAR LA REUNIÓN DIARIA (CONDUCT DAILY STANDUP)
La colaboración se promueve en el Equipo Scrum a través de la Reuniones Diarias (Daily Standup

Meetings). Esta es una reunión diaria de corta duración, generalmente dura 15 minutos como
máximo. En esta reunión corta, los miembros del Equipo Scrum informan su estado y sus planes
para las siguientes 24 horas al resto del equipo. Se revisa el trabajo completado desde la última
Reunión Diaria (Daily Standup Meeting) y se proyecta el trabajo que debe ser hecho antes de la
siguiente Reunión.
La duración de las reuniones es muy corta y se espera que todos los miembros del Equipo Scrum
asistan. Sin embargo, la reunión no se cancela o se retrasa si uno o más miembros no pueden
asistir.
En estas reuniones cada miembro del Equipo Scrum responde a estas tres preguntas específicas:
 ¿Qué terminé ayer?

 ¿Qué voy a terminar hoy?
 ¿Qué impedimentos u obstáculos (si los hay) estoy enfrentando en la actualidad?
Aparte de la colaboración, las Reuniones Diarias promueven la transparencia entre los miembros
del Equipo Core Scrum. El Scrum Master ayuda a los miembros del equipo a resolver problemas
e impedimentos. El Scrum Master sólo es un facilitador, no dirige la reunión. El Daily Standup
Meeting solo es un foro de intercambio de información. Cualquier discusión sobre la resolución de
un problema, si es necesaria, se realiza después de la reunión diaria. El Scrum Master recolecta
información de los impedimentos que los miembros del Equipo Scrum están enfrentando al
realizar los trabajos del Sprint y los resuelve después de la reunión.
1. Scrum Team* 1. Reunión Diaria de Standup 1. Sprint Burndown Chart
2. Scrum Master* (Daily Standup Meeting)* Actualizado*
3. Sprint Burndown Chart * 2. Tres Preguntas Diarias * 2. Impediment Log
4. Impediment Log* 3. Sala de Guerra (War Room) Actualizado*
5. Product Owner 4. Video Conferencia 3. Equipo Scrum Motivado
6. Experiencia del Día Previo 4. Scrumboard Actualizado
de Trabajo 5. Solicitud de Cambio no
7. Scrumboard Aprobada
8. Dependencias 6. Riesgos Identificados
7. Riesgos Mitigados
8. Dependencias Actualizadas
PROCESO 3: MANTENIMIENTO DE LOS PENDIENTES PRIORIZADOS DEL

PRODUCTO (GROOM PRIORITIZED PRODUCT BACKLOG)
Refina el Product Backlog Priorizado
Una de las responsabilidades más importantes del Product Owner es refinar el Product Backlog.
Para asegurar que los elementos priorizados del Product Backlog (de los siguientes dos o tres
Sprints) estén refinados, es recomendable que entre el 7% al 10% de cada Sprint sea destinado
para refinar el backlog. El Product Owner es responsable de añadir o modificar los elementos del
Product Backlog Priorizado como resultado de los cambios de requerimientos de negocio y es
responsable de proporcionar información adicional detallada de las Historias de Usuario que se
implementarán en el siguiente Sprint.
Este proceso asegura que el Product Backlog Priorizado esté refinado bien antes de la siguiente
Reunión de Planificación del Sprint, así el Equipo Scrum tendrá un grupo de historias bien
analizadas y claramente definidas que permitirá agilizar el desglose de tareas y el proceso de
estimación.
¿Por qué Refinar?
 Basándose en el aprendizaje del Sprint en curso, pueden haber cambios en los requisitos,
o podrían haber nuevas prioridades que se pueden incorporar fácilmente en el siguiente
Sprint.
 Esta hace posible la flexibilidad del modelo Scrum mediante la incorporación de la última
perspectiva de negocio y técnica para el desarrollo de productos.
El Procesos
1. Analizar los Requerimientos del Cliente y la Retroalimentación del Sprint Actual
a. Porque los requerimientos y expectativas del clientes para proyectos
complejos son poco claros, el Product Backlog continuamente cambia. Los
cambio a los requerimientos del cliente tiene que ser analizados antes que
sean incorporados.
b. La retroalimentación de la funcionalidad de la solución actual también es
utilizada como entrada mientras se refina el Product Backlog para futuros
Sprints.
2. Priorizar el Product Backlog
a. Basándose en la información del cliente, cambios externos del mercado y

aprendizaje de Sprints previos y el actual, es Product Backlog es repriorizado.
3. Desglosar los Epics / Historias de Usuario Largas
a. Basándose en la prioridad del Product Backlog, las Historias de Usuario son

creadas para el siguiente Sprint. Los elementos largos son desglosados en
muchas Historias de Usuario, así estas puede ser estimadas.
¿Cuándo refinar?
Es muy importante que los equipos planeen el refinamiento del Product Backlog en el momento
adecuado. Este proceso garantiza que los equipos estén en el camino correcto al crear el
producto. El Product Owner puede llevar a cabo este proceso ya sea antes del inicio del un Sprint
o a medio camino de este, de acuerdo a sus necesidades. Este puede ser un ejercicio continuo
ejecutado cuando sea necesario y no necesita ser hecho una sola vez.
Al llevar a cabo la sesión de refinamiento antes del inicio del Sprint, da al Product Owner la
oportunidad de recibir retroalimentación de las partes interesadas y de usuarios finales para
comprender mejor sus necesidades, mientras el equipo empieza a desarrollar. Si la sesión de
refinamiento es ejecutada antes del inicio del siguiente Sprint, entonces es importante que el
equipo no se distraiga del Sprint actual. Por lo tanto, se sugiere que esa sesión se lleve a cabo
días antes del inicio del siguiente Sprint.
En caso se realice el refinamiento continuo, las sesiones podrían ejecutarse una vez por semana.
Sesiones Efectivas de Refinamiento del Product Backlog
Debido a que el Product Owner encabeza la Reunión de Refinamiento del Product Backlog, es
importante que se fije una meta antes de empezar la reunión, para evitar la improvisación. Así la
reunión será más eficiente. Es importante limitar el número de interesados que participarán en la
reunión porque al tener muchos participantes podría disminuir la eficiencia de esta. El Product
Owner podría invitar sólo a aquellos interesados cuya retroalimentación es requerida. También
debe incluir a todo el Equipo Scrum, porque ellos podrían ayudar a afinar las características
basadas en las aportaciones o problemas que enfrentan. Si luego de la sesión de refinamiento se
reprioriza o cambia el Product Backlog, entonces es importante que el equipo tenga el
conocimiento de estos cambios.
Una reunión efectiva debe dar como resultado la definición del Product Backlog que permite que
el Equipo Scrum entienda claramente los requerimientos del cliente.
Requerimientos No Funcionales
Los requerimientos no funcionales están relacionados a la seguridad, usabilidad, accesibilidad,

estabilidad y otros atributos del producto. Estos requerimientos no funcionales son tan importantes
como los funcionales. El incumplimiento de estos requisitos puede indicar que el producto no
cumplirá con los requisitos de usabilidad, confiabilidad, desempeño o compatibilidad.
Estos pueden ser limitaciones en el Product Backlog, ya que pueden imponer restricciones en
diferentes aspectos del producto, como el diseño y la funcionalidad.
Un Product Owner debe tener en cuenta los requisitos no funcionales y capturarlos mientras que
los Epics y características se planifican. También tiene que tener en cuenta el tiempo y recursos
necesarios para probar las Historias de Usuario para los requisitos no funcionales y debe utilizar
de preferencia un sistema automatizado para probarlos porque las pruebas manuales pueden
llegar a ser engorrosas.
Entendimiento de la Importancia de las Historias y la Priorización del Product Backlog
El rol del Product Owner es extremadamente importante para decidir qué funciones se colocan en
el entregable de acuerdo a la importancia del negocio. Es responsabilidad del Product Owner
garantizar que las Historias de Usuario tienen el detalle suficiente para que el equipo pueda
implementarlas. Cuando el Sprint empieza, el Product Owner debe tener un Product Backlog
Priorizado con las Historias de Usuario más importantes bien definidas y listas para que el equipo
pueda trabajar con ellas. El equipo decidirá cuántas historias pueden implementar en el Sprint.
No todas las Historias de Usuario encajarán en un Sprint, por lo que la priorización es obligatoria.
Resumen del Refinamiento del Product Backlog
Adapta los requerimientos cambiantes de los clientes.
Utiliza la retroalimentación de Sprints actuales para modificar el Product Backlog.
Desglosa los elementos de mayor prioridad en Historisa de Usuario y los

prepara para el siguiente Sprint.
El Equipo Scrum invierte entre 7 a 10% del tiempo del Sprint en curso.
1. Scrum Core Team* 1. Reunión de Revisión del 1. Product Backlog
2. Product Backlog Product Backlog Priorizado Priorizado Actualizado*
Priorizado* * 2. Cronograma de
3. Entregables Rechazados 2. Técnicas de Comunicación Planificación del
4. Solicitudes de Cambio 3. Otras Técnicas de Entregable Actualizado
Aprobadas Refinamiento del Product
5. Solicitudes de Cambio no Backlog Priorizado
Aprobadas
6. Riesgos Identificados
Programa Actualizado
8. Retrospect Sprint Log
9. Dependencias
10. Cronograma de
Planificación del Entregable
de Scrum
PREGUNTAS - CAPÍTULO FASE: IMPLEMENTAR
1. ¿Cuál es la duración habitual de la Reunión Diaria (Daily Standup Meeting)?

a. Cinco minutos
b. Una hora
c. Quince minutos
d. Las reuniones diarias no son time-boxed
2. El rol que facilita la Reunión Diaria es responsabilidad de:
a. El Scrum Master
b. El Product Owner
c. El lider del Scrum Team
d. El grupo completo
3. ¿Cuándo los Epics se desglosan en Historias de Usuario para que muestren toda la
funcionalidad requerida?
a. En el proceso de creación del Product Backlog
b. En el proceso de estimación de la tarea.
c. En el proceso de definición del objetivo
d. En el proceso de refinamiento del Product Backlog.
4. ¿Cuál de las siguientes alternativas NO son una ventaja del refinamiento del Product
Backlog?
a. Observaciones de Sprints previos son incorporados en Sprints futuros.
b. Los últimos avances relacionados a los requerimientos del negocio y técnicos son
considerados para Sprints futuros.
c. El Product Backlog es refinado antes de la Reunión de Planificación del Sprint, así
el equipo tiene idea de los requerimientos que se modificaron antes de la reunión.
d. Elimina el requerimiento para la Reunión de Retrospectiva del Sprint.
5. El Criterio de Aceptación:
a. Reduce la complejidad de las características que han sido incluidas en el backlog.

b. Ayuda al equipo a seguir las normas de calidad respecto a la funcionalidad.
c. Es formulada por el Scrum Master en revisión conjunta con los miembros del
Equipo Scrum.
d. Es formulada por el Scrum Master en revisión con el Product Owner.
FASE: REVISAR Y RETROSPECTIVA
La fase Revisión y Retrospectiva se ocupa de la revisión de los entregables y del trabajo que se
ha hecho, y determina las mejores prácticas y métodos utilizados para hacer el trabajo relacionado
al proyecto. En las grandes organizaciones, la fase Revisión y Retrospectiva puede incluir la
convocatoria de Reunión de Scrum de Scrums.
PROCESO 1: CONVOCAR SCRUM DE SCRUMS (CONVENE SCRUM OF

SCRUMS)
Este proceso sólo aplica para grandes proyectos Scrum donde varios Equipos Scrum están
trabajando sincronizadamente para asegurar el progreso del proyecto. Dado que los equipos
trabajan en paralelo, asegurar que todos avancen uniformemente es un tema crítico para los
plazos del proyecto. A veces, las tareas de un equipo pueden depender de la entrega a tiempo de
una tarea de otro equipo. Por lo que tiene que existir un mecanismo que asegure que los equipos
coordinen y que se comuniquen efectivamente.
Esto se lleva a cabo normalmente mediante el Scrum de Scrum que es parecido al Daily Scrum
pero a nivel de varios equipos. Esta reunión es facilitada por el Jefe Scrum Master (Chief Scrum
Master) quien también ayuda a direccionar los impedimentos que impactan a más de un equipo.
Los Scrum Masters de cada Equipo Scrum, o representantes, asisten a la reunión Scrum de
Scrum. Los participantes dan información de sus Registros de Impedimentos, Dependencias, y
sus resultados del proceso de Retrospectiva del Sprint.
Cada equipo proporciona respuestas a cuatro preguntas específicas:

1) ¿En qué ha estado trabajando mi equipo trabajando desde la última reunión?
2) ¿Qué hará mi equipo hasta la próxima reunión?
3) ¿Qué consideraban otros equipos que mi equipo termine que aún no se ha hecho?
4) ¿Qué está planeando hacer nuestro equipo que podría afectar a otros equipos?
La salida principal de las Reuniones Scrum de Scrum es la mejor coordinación entre varios
equipos trabajando en el mismo proyecto.
1 Scrum Master o 1. Reunión de Scrum de 1. Mejor coordinación de
Representantes del Equipo Scrums (Scrum of Scrums Equipos *
Scrum * Meeting)* 2. Incidentes Resueltos
2. Jefe Scrum Master (Chief 2. Cuatro Preguntas por 3. Impediment Log
Scrum Master) Equipo* Actualizado
3. Jefe Product Owner (Chief 3. Video Conferencia 4. Dependencias
Product Owner) 4. Sala de Reunión Actualizadas
4. Agenda de la Reunión 5. Juicio Experto del Cuerpo
5. Impediment Log de Asesoramiento de
6. Dependencias Scrum
7. Salidas de la Retrospectiva
del Sprint
PROCESO 2: DEMOSTRAR Y VALIDAR EL SPRINT (DEMOSTRATE AND

VALIDATE SPRINT)
Acepta o Rechaza los Entregables
En este proceso, el Equipo Scrum presenta los Entregables del Sprint (Sprint Deliverables) al
Product Owner, quien valida que esos entregables cumplan con los Criterios de Aceptación.
La salida de la Reunión de Revisión del Sprint (Sprint Review Meeting) es la aceptación o el

rechazo de los elementos del Sprint Backlog por el Product Owner.
Solo las funcionalidades del producto que satisfacen la definición de Terminado (Done) pueden
ser presentadas, y las funcionalidades en proceso (WIP) son incluidas en un Sprint futuro. Los
miembros del equipo presentan el trabajo completado durante el Sprint, responden a preguntas
de los interesados y toman nota de sus sugerencias de cambio.
Proporciona retroalimentación necesaria al Scrum Master y al Equipo Scrum
El Product Owner y los interesados más importantes participan de la Reunión de Revisión del
Sprint para inspeccionar qué ha sido completado hasta el momento y para determinar si algún
cambio debe ser implementado en el proyecto o en los procesos en los siguientes Sprints. La
retroalimentación de cualquier cambio del proyecto o producto o nuevos requisitos se comunican
al Scrum Master y al Equipo Scrum.
Actualiza el Plan de Versiones y Prioriza el Product Backlog
Si la funcionalidad satisface los criterios de aceptación, entonces está lista para ser transferida al
entorno de negocio. El Product Owner podría escoger por liberar inmediatamente la funcionalidad
o esperar para realizar el lanzamiento luego de unos cuantos Sprints. El Product Owner tiene la
autoridad para decidir cuándo, y después de cuántos Sprints, un lanzamiento se llevará a cabo.
Aunque el resultado final de todos los Sprints deben ser potencialmente comercializables, en la
práctica no sucede esto con cada Sprint. El Product Owner decide sobre los lanzamientos de las
versiones de acuerdo con el Plan de Cronograma de Versiones.
El Product Owner debe actualizar el Plan de Versiones y el Product Backlog Priorizado basándose
en las Historias de Usuario aceptadas y rechazadas. Si algunos entregables no cumplen con los
criterios de aceptación, tales como los entregables rechazados. Las Historias de Usuario
asociadas con entregables rechazados permanecen en el Product Backlog Priorizado para que
puedan ser incluidos en un siguiente Sprint.
1. Scrum Core Team* 1. Reunión de Revisión del 1. Entregables Aceptados *

2. Entregables del Sprint Sprint (Sprint Review 2. Entregables Rechazados
(Sprint Deliverables)* Meeting)* 3. Riesgos Actualizados
3. Sprint Backlog* 2. Análisis de Valor Ganado 4. Resultados del Análisis de
4. Criterio de Terminado 3. Juicio de Experto del Valor Ganado
(Done Criteria)* Cuerpo de Asesoramiento 5. Cronograma de
5. Criterio de Aceptación de la de Scrum Planificación del
Historia de Usuario * Entregable Actualizado
6. Interesados 6. Dependencias
7. Cronograma de Actualizadas
Planificación de la Entrega
8. Riesgos Identificados
9. Dependencias
de Scrum
PROCESO 3: RETROSPECTIVA DEL SPRINT (RETROSPECT SPRINT)
Luego de la Reunión de Revisión del Sprint (Sprint Review Meeting), el Equipo Scrum se reúne
en la Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting). Este es un elemento del
marco de trabajo Scrum relacionado a la inspección y adaptación, dado que es una oportunidad
para que el Equipo Scrum se tome un momento para mirar hacia atrás y examinar el Sprint que
acaba de terminar para identificar mejoras potenciales en el proceso. Estas mejoras pueden
resultar no solo en un simple acuerdo entre miembros del equipo para hacer las cosas de otra
forma, también puede definir elementos no funcionales para el Product Backlog Priorizado.
En la Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting) participan el Scrum Master
y los miembros del Equipo Scrum. El Product Owner podría asistir pero no es obligatoria su
presencia.
Los miembros del equipo revisan qué se hizo bien y qué no en el Sprint que acaba de terminar.
Plantean los problemas que enfrentaron durante el Sprint y discuten cómo se podrían direccionar
estos temas. El Equipo identifica mejoras potenciales en la forma de trabajo y también sugiere
mejoras en la definición de Done basándose en su experiencia. Estas actividades mejoran el
sentido de pertenencia del Equipo Scrum.
1. Scrum Master* 1. Reunión de Retrospectiva 1. Mejoras Viables Acordadas *
2. Equipo Scrum* del Sprint (Retrospect 2. Acciones acordadas y
3. Salidas de Demostrar y Sprint Meeting)* asignadas con fecha de
Validar el Sprint * 2. ESVP Entrega
4. Product Owner 3. Lancha Rápida (Speed 3. Elementos Non-Functional
5. Recomendaciones del Boat) propuestos para el Product
Cuerpo de Asesoramiento 4. Técnicas de Métricas and Backlog Priorizado
de Scrum Medidas 4. Registro de la Retrospectiva
5. Juicio de Experto del del Sprint (Retrospect Sprint
Cuerpo de Asesoramiento Log)
de Scrum 5. Lecciones aprendidas del
Equipo Scrum
6. Recomendaciones
Actualizadas del Cuerpo de
Asesoramiento de Scrum
PREGUNTAS - CAPÍTULO FASE: REVISAR Y RETROSPECTIVA
1. No es obligatoria la participación del Product Owner en cuál de las siguientes reuniones

(seleccione todas las que apliquen)
a. Reunión de Planificación del Sprint (Sprint Planning Meeting)
b. Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting)
c. Reunión Diaria (Daily Standup)
d. Reunión de Revisión del Sprint (Sprint Review Meeting)
2. ¿Qué proceso permite a los miembros del Equipo Scrum hacerse responsables del
proyecto y mejorar la calidad?
a. Retrospectiva del Sprint
b. Aprobar, Estimar y Comprometerse con las Historias de Usuario
c. Ejecutar la Reunión Diaria
d. Refinar el Product Backlog
3. Durante el proceso de Retrospectiva del Sprint, el Scrum Master facilita la Reunión de

Retrospectiva del Sprint. La reunión es el paso final de un Sprint. ¿Cuál de las siguientes
alternativas es verdadera respecto a esta reunión?
a. Esta reunión asegura que los riesgos identificados se incorporen en el Product
Backlog Priorizado.
b. Al final de la reunión, el Equipo Scrum podrá estimar adecuadamente las Historias
de Usuario.
c. La presencia del Product Owner en esta reunión es obligatoria.
d. Esta reunión es un elemento importante del marco de trabajo de Scrum
relacionado a la inspección y adaptación.
4. ¿Con qué frecuencia se lleva a cabo la Reunión de Revisión del Sprint?

a. Según lo determine el Scrum Master.
b. Cuando el Product Owner convoque esta.
c. Al final de cada Sprint
d. Al final de cada proyecto
5. La reunión en la cual el equipo revisa el trabajo completado y presenta la funcionalidad

final del Sprint que acaba de finalizar al Product Owner es conocido como la:
a. Reunión de Visión del Producto (Product Vision Meeting)
b. Reunión de Planificación del Sprint (Sprint Planning Meeting)
c. Reunión de Revisión del Sprint (Sprint Review Meeting)
d. Reunión de Retrospectiva del Sprint (Sprint Retrospective Meeting)
6. ¿Cuál de los siguientes pares están correctamente relacionados?

a. Reunión Diaria : Foro para comunicar
b. Reunión de Revisión del Sprint: Entrega de Funcionalidades
c. Reunión de Planificación del Sprint: Inicio del desarrollo del producto
d. Reunión de Retrospectiva del Sprint: Evaluación del trabajo realizado en el Sprint
FASE: LANZAMIENTO
La fase de lanzamiento (release) destaca la entrega de los Entregables Aceptados al Cliente y la
identificación, documentación e internalización de las lecciones aprendidas del proyecto.
PROCESO 1: ENVIAR LOS ENTREGABLES (SHIP DELIVERABLES)
Ayuda a desplegar las Versiones de Producto y Coordina con el Cliente
Después que el Product Owner valida los entregables del Sprint basándose en los Criterios de
Aceptación y de Terminado, los Entregables Aceptados están listos para la entrega o lanzamiento
a los Interesados. Sin embargo, no todos los Sprints terminan en un lanzamiento. La decisión de
cuándo la entrega es un incremento de producto potencialmente comercializable para los
interesados es tomada en el proceso Conduct Release Planning.
El Cronograma de Planificación de Entrega (Release Planning Schedule) documenta qué

entregables serán liberados y cuándo. De este modo, las entradas principales para este proceso
son los Entregables Aceptados y el Cronograma de Planificación de Entrega.
Los entregables son desplegados utilizando los Métodos de Despliegue de la Organización. Cada
organización tiene sus propios Métodos de Despliegue. Estos guían cómo y cuándo los
entregables serán liberados a los interesados. Las principales salidas de este proceso son los
Entregables Trabajados, Acuerdos de Entregables Trabajados y Lanzamientos de Producto.
Las herramientas utilizadas para el lanzamiento de los entregables son las siguientes:
1. Métodos de Despliegue de la Organización – Los mecanismos de despliegue de cada

organización es diferente de acuerdo a la industria, los usuarios objetivo y el
posicionamiento. De acuerdo a las características del producto entregado, el despliegue
puede ser remoto, podría implicar un envío físico o la transición de un elemento. Debido
a que la implementación tiende a involucrar alto riesgo, las organizaciones normalmente
tienen mecanismos de despliegue bien definidos, que incluyen procesos detallados para
garantizar que se cumplan los estándares y medidas de aseguramiento de calidad
establecidos. Estos podrían incluir aprobaciones de cierre de algunos representantes de
gestión y usuarios; así como directivas respecto a la mínima funcionalidad que se puede
desplegar.
2. Plan de Comunicaciones – En muchos proyectos, el plan de Comunicación existe. Este

plan especifica los registros que deben ser creados y mantenidos durante todo el proyecto.
Muchos métodos se utilizan para transmitir información del proyecto a los interesados, y
el Plan de Comunicación define estos métodos, así como de quién es responsable de las
distintas actividades de comunicación. El estado de las pruebas de los entregables debe
ser comunicado por el Plan de Comunicación, según lo determine el Product Owner y el
Patrocinador. Un mecanismo de comunicación muy útil es representar de forma visual la
información más importante en un formato de fácil interpretación, en un lugar accesible
donde se pueda mantener actualizada esta información.
La principal salida de este proceso es la siguiente:
Acuerdos de Entregables Terminados – Los entregables que satisfacen los Criterios de

Aceptación reciben la aprobación y cierre formal por parte del cliente y patrocinador. La obtención
de la aceptación formal del cliente es fundamental para el reconocimiento de ingresos y la
responsabilidad del cierre de la versión. La responsabilidad para su obtención será definida por
políticas de la empresa y no necesariamente es responsabilidad del Product Owner.
Entregables Terminados – Esta salida es el Entregable final por el cual el proyecto fue autorizado.
A medida que se crean nuevos incrementos de los producto, son integrados continuamente a los
incrementos anteriores, por lo se tendrá un producto potencialmente comercializable disponible
en todo momento a lo largo del proyecto.
Lanzamiento del Producto- Los lanzamientos de Producto deben incluir lo siguiente:
 Contenido de la Versión—Esto consiste en la información esencial acerca de las

entregables que pueden ayudar al Equipo de Apoyo al Cliente (Cliente).
 Notas de la Versión— Las notas de la versión debe incluir criterios de lanzamiento

externos o los relacionados al mercado del Producto a ser entregado.
1. Product Owner * 1. Métodos de Despliegue de 1. Acuerdos de Entregables

2. Interesados * la Organización Trabajados (Working
3. Entregables Aceptados * (Organizational Deliverables Agreement)*
4. Cronograma de Deployment Methods) * 2. Entregables Trabajados
Planificación de Entrega * 2. Plan de Comunicación (Working Deliverables)
5. Scrum Master 3. Lanzamientos de Producto
6. Equipo Scrum (Product Releases)
7. Criterios de Aceptación de
Historia de Usuario
8. Plan Piloto
de Scrum
PROCESO 2: RETROSPECTIVA DEL PROYECTO (RETROSPECT PROJECT)
Participa en las Reuniones de Retrospectiva del Proyecto
El último proceso del flujo Scrum es la Retrospectiva del Proyecto, la cual es similar al proceso
Retrospectiva del Sprint, pero a nivel de proyecto. Después que todos los incrementos de producto
son entregados exitosamente a los interesados, el Equipo Core Scrum o los equipos revisan,
analizan e identifican qué se hizo bien y que no durante el ciclo del proyecto.
La reunión de Retrospectiva del Proyecto (Retrospect Project Meeting) tiene el objetivo de

identificar las mejores prácticas y recomendaciones para el Cuerpo de Asesoramiento Scrum
(Scrum Guidance Body). No solo ayuda a mejorar la colaboración y eficiencia del equipo, también
identifica mejoras para toda la implementación Scrum. Las sugerencias, opiniones y
conocimientos obtenidos en la reunión de Retrospectiva del Proyecto son registrados para
referencias futuras.
La Reunión de Retrospectiva del Proyecto es utilizada para determinar de qué manera se puede
mejorar la colaboración y efectividad del equipo en futuros proyectos. Oportunidades positivas,
negativas y potenciales de mejora son también discutidas. Esta reunión no es Time-boxed y podría ser
ejecuta de forma presencial o virtual. Los participantes incluyen al Equipo del Proyecto, el Jefe de
Scrum Master, Jefe de Product Owner e interesados. Durante la reunión, las lecciones aprendidas con
documentadas y los participantes buscan oportunidades de mejora de procesos y direccionamiento de
ineficiencias.
Las principales salidas del proceso de Retrospectiva son las siguientes:
 Mejoras viables acordadas.
 Acciones acordadas y asignadas con fecha de entrega.
1. Scrum Core Team(s)* 1. Reunión de la 1. Mejoras viables acordadas*

2. Jefe Scrum Master Retrospectiva del Proyecto 2. Acciones acordadas y
3. Jefe Product Owner (Retrospect Project asignadas con fecha de
4. Interesados) Meeting)* Entrega*
5. Recomendaciones del 2. Otras herramientas para la 3. Elementos Non-Functional
Cuerpo de Asesoramiento Retrospectiva del Proyecto propuestos para el Product
de Scrum 3. Juicio Experto del Cuerpo Backlog Priorizado y para el
de Asesoramiento de Program Product Backlog
Scrum 4. Recomendaciones
Actualizadas del Cuerpo de
Asesoramiento de Scrum
PREGUNTAS - CAPÍTULO FASE: LANZAMIENTO
1. Las salidas del proceso de Retrospectiva del Proyecto incluyen:
a. Mejoras viables acordadas, Product Backlog Priorizado
b. Mejoras viables acordadas, Acciones acordadas y asignadas con fecha de

entrega
c. Product Backlog Priorizado Actualizado, Acciones acordadas y asignadas con

fecha de entrega
d. Product Backlog Priorizado Actualizado, Notas de Versiones
2. Las principales salidas del proceso Enviar Entregables incluyen las siguientes,
EXCEPTO:
a. Acuerdo de Entregables Terminados
b. Entregables Terminados
c. Product Backlog
d. Versiones de Producto
3. El propósito de la Reunión de Retrospectiva de Proyecto es para:
a. Alentar el sentimiento de propiedad compartida entre los miembros del equipo

para hacerlos más responsables.
b. Determinar formas en las cuales la colaboración y efectividad del equipo puede

ser mejorada para futuros proyectos.
c. Planificar el siguiente proyecto para el equipo Scrum.
d. Celebrar los logros y ofrecer recompensas monetarias para los miembros del
equipo.
IMPLEMENTACIÓN DE SCRUM
ESCALABILIDAD DE SCRUM
Para ser eficaz, los Equipo Scrums deben tener idealmente de seis a diez miembros. Esta práctica
podría llevar a la idea errónea de que el método de Scrum sólo se puede utilizar para proyectos
pequeños. Sin embargo, se puede escalar fácilmente para el uso eficaz en proyectos grandes. En
situaciones donde el tamaño del Equipo Scrum excede los diez miembros, múltiples Equipo
Scrums se pueden formar para trabajar en el proyecto. El proceso Convocar Scrum of Scrum
facilita la coordinación entre los Equipo Scrums lo que permite una aplicación efectiva en los
proyectos grandes.
Los proyectos grandes o complejos a menudo se implementan como parte de un Programa o

Portafolio. El método de Scrum también se puede aplicar para gestionar Programas y Portafolios.
El enfoque lógico de las directrices y los principios de este marco pueden utilizarse para gestionar
proyectos de cualquier tamaño, que abarcan distintas geografías y organizaciones. Los proyectos
grandes pueden tener varios Equipos Scrums trabajando de forma paralela por lo que es
necesario sincronizarse y facilitar el flujo de información y mejorar la comunicación.
El proceso Convocar Scrum de Scrum asegura esta sincronización. Los diversos Equipos Scrums
están representados en esta reunión y el objetivo es proporcionar actualizaciones sobre el
progreso, discutir los retos que enfrentan durante el proyecto y coordinar las actividades. No hay
reglas fijas en cuanto a la frecuencia de estas reuniones. Los factores que determinan la
frecuencia son el nivel de dependencia entre los equipos, el tamaño del proyecto, el nivel de
complejidad y las recomendaciones del Cuerpo de Asesoramiento de Scrum.
SCRUM EN PROGRAMAS Y PORTAFOLIOS.
Programas
En los Programas, los roles principales para la gestión de Scrum son:
1. Product Owner del Programa — Define los objetivos y las prioridades estratégicas para el
Programa.
2. Scrum Master del Programa — Resuelve problemas, remueve Impedimentos, facilita y lleva a
cabo reuniones para el Programa.
Estas funciones son similares a las del Product Owner y Scrum Master excepto que satisfacen las
necesidades del Programa o unidad de negocio en lugar de las de un sólo Equipo Scrum.
Portafolios
En Portafolios, los roles importantes para la gestión de Scrum son:
1. Product Owner del Portafolio —Define los objetivos estratégicos y las prioridades del Portafolio.
2. Scrum Master del Portafolio —Resuelve problemas, elimina Impedimentos, facilita y lleva a
cabo reuniones para el Portafolio.
La siguiente figura ilustra cómo el método Scrum se puede utilizar en toda la organización para
los Portafolio, Programa o Proyectos.
Scrum en toda la organización para Proyectos, Programas y Portafolios
Trabajando con Equipos de Programas y Portafolios
Al aplicar Scrum para gestionar proyectos en el marco de un Programa o un Portafolio se

recomienda que los principios generales de Scrum que se presentan en el SBOKTM se cumplan.
Se entiende, sin embargo, que con el fin de cumplir con el Programa en su totalidad o las
actividades relacionadas con el Portafolio e interdependencias, pueden ser necesarios pequeños
ajustes en el conjunto de herramientas, así como en la estructura organizacional.
Los Portafolios y Programas tienen equipos separados y con diferentes objetivos. Los equipos de
gestión de Programa tienen por objetivo ofrecer capacidades y llevar a cabo ciertas metas que
contribuyan a objetivos específicos del Programa. Por el contrario, el equipo de Portafolio tiene
que equilibrar los objetivos de los distintos Programas para alcanzar los objetivos estratégicos de
la organización en su totalidad.
La gestión de comunicación con los equipos de Portafolio y Programas
Los problemas que se enfrentan al utilizar Scrum dentro de un Programa o Portafolio implican
principalmente la coordinación entre los numerosos equipos. Esto puede conducir al fracaso si no
se gestiona con cuidado. Las herramientas utilizadas para la comunicación deben ser escaladas
para que coincida con los requisitos de los equipos que participan en un Programa o un Portafolio.
Cada Equipo Scrum debe atender no sólo la comunicación interna, sino también la comunicación
externa con otros equipos y los interesados del Programa o Portafolio.
Reuniones de Scrum of Scrums (SoS) Scrum of Scrums Meeting

Un Scrum of Scrums (SoS) Meeting es un elemento importante al escalar o ajustar Scrum a proyectos
grandes . Por lo general, hay un representante en la reunión de cada uno de los Equipo Scrums. Por
lo general el representante es el Scrum Master, pero también puede asistir cualquier miembro del
Equipo Scrum si es necesario. Esta reunión es usualmente facilitada por el Jefe Scrum Master y su
objetivo es centrarse en las áreas de coordinación e integración entre los diferentes Equipo Scrums.
Tal reunión se lleva a cabo en intervalos predeterminados o cuando lo requieran los Equipo Scrums.
En organizaciones donde hay varios Equipo Scrums trabajando en varias partes de un proyecto de
forma simultánea, SoS se puede escalar a otro nivel, esta se conoce como Scrum of Scrum of Scrums
Meeting. En esta situación, una Reunión SoS mantiene la coordinación de cada grupo de los Equipo
Scrums.
La Figura ilustra la dinámica de las reuniones Scrum of Scrums (SoS)
Reunión de Scrum of Scrums (SoS)
TRANSICIÓN A SCRUM
Los dos métodos básicos para hacer la transición a Scrum son de arriba a abajo y de abajo a
arriba. En el método de arriba hacia abajo, la transición es comunicada en toda la organización.
Existe un esfuerzo por proveer capacitación del cambio a todos los involucrados. Esta
comunicación puede ser fuente de resistencia al cambio. La otra posibilidad es cambiar las cosas
gradualmente dentro de la cultura de la organización. Después, la transición a Scrum será de
forma incremental.
Con una implementación de arriba hacia abajo, podrían haber conflictos de comunicación. Por
ejemplo, un líder de ingeniería implantó Scrum en su organización sin el consentimiento por parte
del área de ventas. Esto llevaría a grandes conflictos con el mismo Product Owner.
Otro aspecto a considerar de la transición es saber el impacto de la transición de la organización

a los métodos Scrum. Toda organización puede hacer la transición al mismo tiempo. Sin embargo,
este método es más susceptible a problemas que pueden resultar en la interrupción de actividades
que generan ganancias. Por lo tanto, es generalmente preferible hacer la transición en diferentes
secciones de forma iterativa para reducir el riesgo y proveer lecciones aprendidas para futuras
iteraciones.
Mapeo de Roles tradicionales a Scrum
Los roles tradicionales de la gestión de proyecto son divididos en tres roles en Scrum : Product Owner
, Scrum Master y Scrum Team.
 El Product Owner se comunica con los interesados y establece las prioridades del proyecto.
 El Scrum Master ejecuta los deberes del jefe de proyecto porque remueve los impedimentos.
 El Scrum Master, como el jefe de proyecto, es responsable de asegurar que los procesos
Scrum sean ejecutados adecuadamente.
 Los miembros del Equipo también ejecutan algunos roles tradicionales del jefe de proyecto,
dado que ellos se auto gestionan y son dueños de su tiempo. Esto permite que el equipo tenga
un sentido de pertenencia para que busque su propio éxito.
Mantenimiento de la Participación de los Interesados

Scrum requiere gran apoyo por parte de los interesados del proyecto. Las siguientes son las acciones
recomendadas para el mantenimiento de la participación y el apoyo de los interesados.
 Establecer un acuerdo de trabajo con los interesados para promover su colaboración y

participación efectiva.
 Evaluar continuamente los cambios del proyecto que afectan a los interesados para asegurar
que nuevos interesados del proyecto estén comprometidos.
 Mantener una comunicación regular con los interesados.
 Administrar las expectativas de los interesados.
Importancia del Soporte Ejecutivo

Los ejecutivos son las personas que financian el proyecto. Por tanto, para que cualquier proyecto de
Scrum sea exitoso, los ejecutivos deben apoyarlo. Para conservar el apoyo ejecutivo:
 Comuníquese regularmente con los ejecutivos.

 Mantenga a los ejecutivos informados de los últimos avances.
 Informe a los ejecutivos de cualquier conflicto o retrasos potenciales en la entrega del proyecto
para minimizar el impacto.
Es importante que los ejecutivos que financian el proyecto tengan claridad respecto a los siguientes
temas:
 ¿Cuál es el beneficio de implementar el Método Scrum?

o ¿Cómo este cambio crea beneficios y / o evita pérdidas para la organización?
o ¿Cuán imprescindible es adaptarse al actual ambiente de negocios?
 ¿Cuáles son los plazos límite y costos de la transición?
o ¿Cuál es el tiempo estimado para completar la transición y cuál es el costo de la
transición?
o ¿Cuáles son los hitos principales para realizar la transición?
o ¿Qué tan frecuentemente los ejecutivos se va a reunir para revisar el avance del
proyecto?
 ¿Cuáles son los riesgos que involucra la transición?
o ¿Cuáles son obstáculos o riesgos potenciales en la implementación?
o ¿Cuál es el costo y tiempo adicional requerido para mitigar cada uno de estos riesgos?
PREGUNTAS - CAPÍTULO IMPLEMENTANDO SCRUM
1. ¿Cuál de los siguientes NO es un desafío en la implementación de Scrum en grandes

proyectos?
A. Se requieren varios equipos para trabajar en sincronía.
B. Falta de un Product Backlog general para monitorear el progreso de todos los proyectos.
C. Nivel adicional en la jerarquía en tenga el rol de Jefe Product Owner.
D. Interdependencia de las tareas entre los equipos.
2. ¿Quién es responsable del todo el éxito o fracaso en proyectos grandes?

A. Jefe de Scrum Master
B. Jefe de Product Owner
C. Equipo Scrum
D. Interesados
3. ¿Cuál de los siguientes es parte de la Reunión Scrum de Scrums?

A. Si alguna de tus decisiones podrían afectar a otros equipos.
B. Hablar de los problemas que pueden haber surgido para cualquiera de los equipos de
Scrum.
C. Resolución de Impedimentos que pueden haber surgido.
D. Resumen de las tareas a realizar en el Sprint.
4. ¿Cuál de las siguientes afirmaciones es FALSA respecto a Scrum en equipos grandes?

(seleccione las que corresponden)
A. Los equipos grandes tienen Jefe de Scrum Masters y Jefe de Product Owners para
controlar el progreso del proyecto.
B. El Jefe de Product Owner facilita la reunión de Scrum de Scrums.
C. El Jefe de Product Owner es responsable de la asignación de recursos.
D. El Jefe de Scrum Master es responsable del éxito o fracaso del proyecto.
IMPORTANCIA DEL VALOR
Un proyecto de negocio se lleva a cabo para crear valor a este. Debido a que el valor es la razón
principal del proyecto, la Entrega impulsada por el Valor debe ser el enfoque de cualquier proyecto
y está arraigado en el ADN de los proyectos Scrum. El Manifiesto Ágil da fé de esto cuando declara
su preferencia por el “software funcionando sobre documentación extensiva”, a través de su
principio “entrega de software funcionando frecuentemente”, y con “ el software funcionando es la
primera medida de avance”. Por lo tanto es responsabilidad del Product Owner asegurar que la
creación es el enfoque del proyecto.
Scrum tiene como objetivo ofrecer valor temprano al proyecto. Debido a la naturaleza impredecible
del desarrollo del producto, es importante entregar componentes destacados tan pronto como sea
posible. Esta entrega temprana de valor da una oportunidad para la reinversión, así como para
demostrar el valor del proyecto a los interesados.
Prácticas de Entrega Impulsado por el Valor
1. Evaluación del valor- El valor del proyecto de negocio es estimado utilizar indicadores
financieros como Retorno sobre la Inversión (ROI), Valor Presente Neto (VPN) y Tasa
Interna de Retorno (TIR).
2. Caso de Negocio- Un caso de negocio es un documento que describe porque los

patrocinadores potenciales deben emprender el proyecto. Esta proporciona un beneficio
monetario estimado. Si el proyecto no brinda un valor monetario directo y es un servicio
que debe ser proporcionado, entonces un caso de negocio puede mostrar el riesgo que
los patrocinadores podrían evitar si el proyecto es implementado.
Un caso de negocio normalmente incluye la siguiente información:
 Descripción del proyecto
 Costos y beneficios esperados para los patrocinadores del proyecto
 Evaluación del valor del proyecto mediante el cálculo del Retorno de Inversión
(ROI), Valor Presente Neto (VPN) y Tasa Interna de Retorno (TIR).
 Riesgos que se pueden evitar si el proyecto se lleva a cabo.
 Sugerencias de los interesados.
3. Juegos Agiles (Juegos Colaborativos)

Juegos Colaborativos, también conocidos como juegos de innovación, son técnicas
utilizadas por equipos e interesados para identificar problemas y acordar soluciones.
Hay varios juegos de colaboración que se pueden utilizar en los proyectos Scrum:
 Recordar el Futuro: Este ejercicio ayuda a establecer una visión para el proyecto
y obtener requerimientos de los interesados.
 Podar el Árbol de Producto: Este ejercicio de tormenta de ideas es llevado a

cabo para determinar características y funcionalidades del producto.
 Lancha rápida: Con este ejercicio, los equipos e interesados identifican

beneficios y amenazas del proyecto.
 Dinero de Monopolio: En este ejercicio, los clientes distribuyen una cantidad
determinada de dinero de juego entre un conjunto de características.
 Comprar una característica: Este ejercicio ayuda a priorizar las características

una vez que estén finalizados.
 Bang for the Buck: Este ejercicio evalúa el valor del negocio versus el costo.
4. Valor de la Planificación : Después de evaluar el valor del proyecto con herramientas

como Mapa de Flujo de Valor, Chartering, Priorización basada en el valor y hojas de ruta
del producto, el proyecto es planificado maximizando la Entrega basada en el Valor. La
responsabilidad para determinar “cómo” se creará el valor recae en el Equipo Scrum,
mientras que el Product Owner se concentra en “qué” debe ser desarrollado. La
planificación del valor es una función muy importante del Product Owner, ya su visión y su
habilidad para determinar efectivamente esta, dará como resultado el equipo entregue
productos exitosos.
5. Valor de la Entrega : Una vez que completa la evaluación y planificación del valor, el
equipo pasa a ejecutar y entregar valor. Para hacer este trabajo efectivamente, los equipos
técnicos deben eliminar los siete desperdicios o muda sugeridos por Mary Poppendieck.
Los siete desperdicios incluyen: hacer un trabajo parcial (como código que aún no se ha
probado), procesos extra (documentación y formalidad oficial innecesaria), espera
(aprobaciones pendientes), cambio de tareas (recursos que son distribuidos en muchos
proyectos), funcionalidades extra (funcionalidades que no son esenciales para el
producto), movimiento (tiempo y esfuerzo para comunicar o transferencia de entregables)
y defectos (errores y defectos de software).
6. Valor de la Confirmación: Scrum es utilizada para crear productos y servicios que

son a menudo intangibles. Debido a esto, es importante validar la ruta actual del proyecto
con las directrices que se establecieron al inicio. Esto se puede hacer utilizando prototipos,
simulaciones y demostraciones. La presentación de prototipos y simulaciones de las
funcionalidades a los clientes es una práctica importante para confirmar valor.
7. Valor del Seguimiento y Reporte: El control de la tasa de entrega de valor es un

aspecto importante de los proyectos Scrum. El seguimiento periódico y la elaboración de
informes ayudan a evaluar el estado del proyecto, los cuales pueden ser comunicados al
cliente.
Valor Ganado Agile
Los gráficos de la curva S y los diagramas Gantt tiene sus propias limitaciones para
realizar el seguimiento y reporte del progreso del proyecto. Por esto que el Análisis de
Valor Ganado (Earned Value Analysis EVA) y la Gestión del Valor Ganado (Earned Value
Management EVM) fue creado. El Análisis de Valor Ganado mide el desempeño real del
proyecto comparado con el desempeño planeado en cualquier punto. Sin embargo, para
que esta herramienta sea efectiva se necesita tener una línea base fuerte. La Gestión de
Valor Ganado se enfoca en la proyección en el tiempo que ayudará a saber cuándo se
completará el proyecto y a saber el costo final. El Análisis de Gestión Ganado utiliza
elementos visuales, en forma de gráficos, como una forma básica para comunicar el
estado.
Diagrama de Flujo Acumulado (CFDs)
El Diagrama de Flujo Acumulado da información valiosa sobre el estado del proyecto y es

una herramienta importante para realizar seguimiento e informar el estado de los
proyectos ágiles. El área sombreada muestra el total de funcionalidades a ser construidas.
CFDs proporcionan una representación visual de cómo el proyecto se está realizando. Es
una herramienta útil para identificar obstáculos y cuellos de botella dentro de los procesos.
Si el CFD muestra una banda de proceso que está cada vez más pequeña que el proceso
anterior mientras que el proceso anterior se hace más grande con el tiempo, entonces el
proceso con la banda más pequeña es el cuello de botella, por lo que se tendrá que hacer
cambio para hacer que el flujo sea más eficiente.
Un ejemplo del diagrama CFD es el siguiente:
Gestión de Riesgo
La gestión del riesgo es tan importante como la creación de valor y debe ser ejecutada
durante todo el proyecto. Los riesgos se evalúan basados en: la probabilidad de riesgo y
el impacto del riesgo. Si la probabilidad de riesgo es calculada como un porcentaje del y
el impacto del riesgo es calculado en términos monetarios, entonces será fácil de evaluar
el Valor Monetario del Riesgo (EVM) del riesgo.
La fórmula de la severidad del riesgo es calculada de la siguiente forma:
Severidad de Riesgo = Probabilidad de Riesgo x Impacto de Riesgo
El cálculo de la severidad de riesgo puede también ayudar a priorizarlos y dar prioridad a

la respuesta de estos, esto no solo se aplica a proyectos Agiles. Sin embargo, los
proyectos Agiles están enfocados en la creación de valor, y el cálculo del VME puede
ayudar a identificar y evitar riesgos. La severidad del riesgo se puede calcular en una
escala numérica. Al tener un valor monetario asignado a un riesgo es posible priorizarlo
contra el valor de una funcionalidad generada.
Backlog ajustado a los Riesgos (Risk – adjusted Backlog): Un riesgo puede tener un
impacto positivo o negativo al proyecto. Por lo tanto, se planifican las actividades de
gestión de riesgos para minimizar cualquier riesgo negativo. Scrum rápidamente identifica
y mitiga los riesgos y puede aprovechar las herramientas de gestión de riesgo.
Antes de emprender cualquier proyecto, los representantes del negocio calculan el ROI
estimado para el proyecto completo, que luego se divide en las funcionalidades
individuales. Así, se crea una lista de características priorizada con los valores de retorno
de la inversión (ROI). Del mismo modo, los pasos para evitar los riesgos están evaluados
de forma monetaria mediante el cálculo del valor del riesgo. El valor monetario de la acción
de mitigación del riesgo es calculada utilizando el Valor Monetario Esperado (EMV), en la
que se utiliza la siguiente fórmula. El cliente se aproxima a estos valores.
Valor Monetario Esperado = impacto de riesgo (en moneda) x probabilidad de riesgo (en
porcentaje)
A continuación se muestra un product backlog priorizado:
Risk adjusted Backlog
Con características y acciones de respuesta

SPOC Cuaderno de Trabajo Resuelto

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SPOC Cuaderno de Trabajo Resuelto

Hochgeladen von

Copyright:

Verfügbare Formate

© 2014 SCRUMstudy.com v4.

Objetivos del Curso

Resultados del Curso

Metodología del Curso

Membresía Básica - Gratuita

Membresía Avanzada – Cuota Anual

Acerca del Examen de Certificación SPOCTM Certification Exam

¿POR QUÉ UTILIZAR AGIL?

La rápida evolución del mercado y de la tecnología; exige estar a la vanguardia.

La disminución del "time to market" de los productos y el incremento de la

Reducción de los costos de pruebas (simulaciones y automatización).

El valor del cliente es entregado en el punto de venta, no en la planificación.

La necesidad de un método de desarrollo adaptativo más que de uno tradicional,

Los individuos y las Interacciones Procesos y Herramientas

Es decir, mientras que hay valor en los elementos de

2. Software funcionando sobre la documentación extensiva

3. Colaboración con el Cliente sobre la negociación contractual

4. Responder ante el cambio en vez de seguir un plan

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

3. Entregamos software funcional de manera frecuente, entre dos semanas y dos

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que brindarles

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo

7. El software funcionando es la medida principal del avance del proyecto.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,

9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-

1. Nuestra mayor prioridad es satisfacer al  Satisfacción al cliente (no a la oficina de gestión de

3. Entregamos software funcional de  Entrega frecuente.

5. Los proyectos se desarrollan en torno a  La diferencia de “tener el mejor equipo” frente a

7. El software funcionando es la medida  Hacer software que funcione es el enfoque

Escrita en 2005 como complemento al Manifiesto Ágil, la “Declaración de Interdependencia” es la

Los enfoques ágiles y adaptables vinculan personas, proyectos y valor.

Somos una comunidad de líderes de proyecto altamente exitosos en la entrega de resultados.

 Incrementamos el retorno de inversión, haciendo del flujo continuo de valor nuestro

 Entregamos resultados fiables mediante la participación de los clientes en las

 Esperamos la incertidumbre y la gestionamos a través de iteraciones, anticipación y

 Liberamos la creatividad y la innovación al reconocer que las personas son la fuente

 Impulsamos el rendimiento mediante la rendición de cuentas del grupo para resultados

 Mejoramos la eficacia y la confiabilidad a través de estrategias, procesos y prácticas

El DOI es un documento importante para todos los involucrados en un proyecto de desarrollo.

 Garantizar un mayor retorno de la inversión (ROI) centrándose en el valor y su flujo

 Obtener resultados fiables mediante la maximización del involucramiento del cliente. El

 Esperar que la incertidumbre y los riesgos disminuyan al dividir el trabajo en pequeñas

 Impulsar el rendimiento mediante la activación de la rendición de cuentas grupal para

 Mejorar la eficacia y la confiabilidad a través de la implementación de estrategias

GESTIÓN DE PROYECTOS TRADICIONAL VERSUS AGIL

El énfasis está en Personas Procesos

Aseguramiento de Calidad Centrada en el Cliente Centrada en el Proceso

Planificación por Adelantado Baja Alta

Perspectiva hacia el cambio Adaptabilidad Sostenibilidad

Liderazgo Colaborativo, Líder Servicial Comando y control

Medición del Rendimiento Valor del negocio Plan de Conformidad

La figura de abajo muestra la diferencia entre el Método de Gestión Tradicional y el Ágil

Scrum vs Método Tradicional

Método Valores Principales Características Roles

FDD Desarrollo Planear, diseñar, y Propiedad individual  Jefe de Proyecto

EP Programación  Simplicidad Enfocado en buenas  XP Coach

DSDM Métodos de  Enfocarse en la Fase de pre-proyecto,  Advisor user

Lean Kanban Agile Unified Essential Open Unified

1. ¿Cuál de las siguientes NO es un Principio del Manifiesto Ágil?

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

2. ¿Qué componentes describen el enfoque Ágil?