Hoy Presentaciones Scrum Master

K
Prof. M.Sc. (c) Manuel Sigüeñas, SCRUMstudy™ Certified Trainer

Scrum Fundamentals Certified (SFC), Scrum Developer Certified (SDC), Scrum Master Certified (SMC). Scrum Product Owner Certified (SPOC),
SCRUMstudy Agile Master Certified (SAMC), Scaled Scrum Master Certified (SSMC), Scaled Scrum Product Owner Certified (SSPOC).
Es el más popular y el más ampliamente
aceptado
Se basa en el Cuerpo de conocimiento de

Scrum (Guía SBOK™)
Acerca de Amplia aceptación en la industria

SCRUMstudy
Es confiable y tiene un entorno estándar de
• SCRUMstudy certifica a cientos de estudiantes mensualmente:
evaluación
más que cualquier otro órgano de acreditación en Scrum y Ágil.
• Con más 61,000 miembros, el grupo de SCRUMstudy en
LinkedIn es el grupo de Scrum y Agile más grande y en mayor
crecimiento en LinkedIn.
Nombre establecido en las certificaciones
de Scrum y Ágil
Crecimiento
de SCRUM
Resumen de las
Certificaciones
SCRUM
Esquema de certificación de SCRUMstudy
Todos los exámenes de certificación de SCRUMstudy son supervisados en línea. Los participantes necesitarán una
computadora y una cámara web para hacer el examen, mismo que será supervisado en vivo por VMEdu.
Certificaciones de SCRUMstudy
¿QUÉ ES ÁGIL?
“La agilidad es la habilidad de crear y responder al cambio a fin de
obtener beneficios en un turbulento entorno empresarial. La agilidad
es la capacidad para equilibrar la flexibilidad y estabilidad”
Necesidad de ser ágil
El rápido cambio en el mercado y la tecnología; la necesidad de estar a la vanguardia.
La reducción del “tiempo para comercializar” productos y el aumento en la demanda de innovación por parte del cliente”
La reducción de prueba (testing) y costos de experimentación (simulación y automatización).
El valor del cliente se entrega en el punto de venta, no en el punto de planificación.
La necesidad de un método adaptable de desarrollo en vez de los métodos tradicionales y predecibles.

Manifiesto ágil, la aplicación de cualquier método ágil requiere de un
entendimiento de los cuatro valores señalados:
• Individuos e interacciones sobre procesos y herramientas.

• Software funcionando sobre documentación extensiva.
• Colaboración con el cliente sobre negociación contractual.
• Responder ante el cambio sobre seguir un plan.
“Aunque valoramos los elementos de la derecha, valoramos más los de la

izquierda”
Principios ágiles:
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con
valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles
aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, preferencia al periodo de
tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el
proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que
necesitan, confiarles la ejecución del trabajo.
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.
El software funcionando es la medida principal de progreso.
Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos
ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto – organizada.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.
¿QUÉ HA CAMBIADO?
TRADICIONAL TRIÁNGULO DE ACERO TRIÁNGULO ÁGIL
Alcance Valor
Costo Tiempo Calidad Limitantes
Los métodos ágiles requieren que cambie la mentalidad de los métodos tradicionales. Mientras que los métodos en cascada (waterfall)
se enfocan en el alcance y lo utilizan para determinar los costos y el tiempo, los frameworks ágiles se enfocan en el valor del negocio y
Lo utilizan para determinar la calidad y los limitantes del desarrollo.
Gestión adaptativa de proyectos:
MÉTODO DE
DESARROLLO PROGRAMACIÓN DESARROLLO DESARROLLO
CRYSTAL SCRUM
DE SISTEMAS EXTERNA BASADO EN ADAPTATIVO DE
1988 1995 DINÁMICOS 1996 FUNCIONALIDADES SOFTWARE
1995
Crystal: se enfoca en la eficiencia y lo habitable como componentes de la seguridad del proyecto. Clystal Clear (requiere de entrega
frecuente de código usable para el usuario; mejora reflexiva y comunicación osmótica), se enfoca en personas, no en procesos o
artefactos.
Método de desarrollo de sistemas dinámicos: es un método iterativo e incremental que incluye principios de desarrollo ágil,
incluyendo la participación constante del usuario y el cliente. Fija costos, calidad y tiempo al inicio, y utiliza la priorización MoScow.
Programación Extrema: Es un método que mejora la calidad del software y responde los requerimientos cambiantes del cliente.
Desarrollo basado en funcionalidades: Es un proceso basado en el modelo y de breve iteración, consiste en 5 actividades
básicas: Desarrollar un modelo general, crear una lista de funcionalidades, planificar por funcionalidad, diseñar por funcionalidad.
Desarrollo adaptativo de software: Es un método que consiste en una serie repetitiva de ciclos de especulación, colaboración y
aprendizaje. Ofrece un aprendizaje constante y se adapta fácilmente al estado actual del proyecto.
Otros métodos ágiles:
• Lean Development: es la aplicación de principios ligeros para el desarrollo del
producto, es una actividad interfuncional.
• Kanban Development: es un método para el desarrollo de productos y
procesos de software con énfasis en la entrega justo a tiempo sin sobrecargar
los desarrolladores de software.
• Proceso Unificado Ágil: es un método para desarrollar aplicaciones de software
de negocios con el use de técnicas ágiles.
• Proceso Unificado Esencial: es un método que identifica las prácticas que sean
necesarias para aplicar a la situación y combinarlas con sus propios procesos.
• Proceso Unificado Abierto: es un método que incluye el desarrollo iterativo,
casos de uso y utiliza escenarios para guiar el desarrollo, la gestión de riesgos y
un método centrado en arquitectura.
Resumen de
SCRUM
Resumen de Scrum
• Un proyecto de Scrum implica un esfuerzo colaborativo para crear un

producto o servicio nuevo, o cualquier otro resultado según lo que
defina la Declaración de visión del proyecto.
• Los proyectos se ven afectados por limitaciones de tiempo, costo,
alcance, calidad, recursos, capacidades organizacionales y demás
limitaciones que dificultan su planificación, ejecución, gestión y por
ultimo su éxito.
• Sin embargo, la implementación exitosa de los resultados de un
proyecto terminado, proporciona considerable beneficios de negocio a
una organización.
• Por lo tanto, es importante que las organizaciones selecciones e
implementen un apropiado método para la gestión de proyectos.
¿Qué es SCRUM?
• Scrum es uno de los métodos ágiles más populares. Es

un framework adaptable, iterativo, rápido, flexible y
eficaz, diseñado para ofrecer un valor considerable en
forma rápida a lo largo del proyecto. Scrum garantiza
transparencia en la comunicación y crea un ambiente
de responsabilidad colectiva y de progreso continuo.
• El framework de Scrum, tal como se define en la Guía
SBOK™, está estructurado de tal manera que es
compatible con el desarrollo de productos y servicios en
todo tipo de industrias y en cualquier tipo de proyecto,
independientemente de su complejidad.
¿Qué es SCRUM?
Figura 1-1 Flujo de Scrum para un sprint

Historia de
SCRUM
Historia de Scrum – Método de
Rugby
• El framework fue introducido a finales de la década de 1980.
• Fue desarrollado por Hirotaka Takeuchi e Ikujiro Nonaka.
• Fue descrito como un método innovador para el desarrollo de
productos, al que llamaron: método holístico o Rugby.
• Fue definido como una estrategia flexible e integral para el
desarrollo de productos.
• El método se basa en estudios de caso de manufactura de
distintas industrias.
• El desarrollo de productos no debe ser como una carrera de
relevos secuencial, sino que debe ser similar al juego de
Rugby.
Historia de Scrum – Método de
Rugby
• 2013 – Fue lanzada la primera edición del Cuerpo de Conocimiento
de Scrum (Guía SBOK®). Fue desarrollada con el apoyo de más de 52
expertos en la materia de más de 10 países.
• 2015 - Fue lanzada la segunda edición del Cuerpo de Conocimiento
de Scrum (Guía SBOK®).
• 2015 – Se formó el grupo de SCRUMstudy en LinkedIn. Hoy en día es
la comunidad de practicantes de Scrum y Ágil más grande y en mayor
crecimiento con más de 61,000 miembros.
• 2017 – Fue lanzada la segunda edición del Cuerpo de Conocimiento
de Scrum (Guía SBOK®) con secciones detalladas sobre el
escalamiento de Scrum para grandes proyectos y para la empresa
¿Por qué
Scrum?
Scrum vs. Gestión de proyectos
tradicional
ENFOQUE ÁGIL CASCADA
ÉNFASIS EN LAS PERSONAS EN LOS PROCESOS
DOMINIO IMPREDECIBLE/EXPLICATIVO PREDECIBLE
DOCUMENTACIÓN MÍNIMA; SOLO LO NECESARIO EXCESIVA
GARANTÍA DE CALIDAD CENTRADA EN EL CLIENTE CENTRADA EN PROCESOS
ESTILO DE PROCESO ITERATIVO LINEAL
ORGANIZACIÓN AUTO-ORGANIZADA GESTIONADA
PLANIFICACIÓN POR ADELANTADO BAJA ALTA
PERSPECTIVA HACIA EL CAMBIO ADAPTABILIDAD SOSTENIBILIDAD

PRIORIZACIÓN DE REQUERIMIENTOS BASADA EN EL VALOR DEL NEGOCIO Y SE FIJA EN EL PLAN DEL PROYECTO
ACTUALIZA CONSTANTEMENTE
ESTILO DE GESTIÓN DESCENTRALIZADO AUTOCRÁTICO
LIDERAZGO COLABORATIVO; LIDERAZGO SERVICIAL COMANDO Y CONTROL
MEDIDA DEL DESEMPLEO VALOR DEL NEGOCIO CONFORMIDAD CON EL PLAN

RETORNO SOBRE LA INVERSIÓN TEMPRANO/A LO LARGO DEL PROYECTO A FINAL DE LA VIDA DEL PROYECTO
Tabla 1-3: Scrum vs. Gestión tradicional de proyectos. Página 17 de la Guía SBOK™
Beneficios
de SCRUM
Beneficios de Scrum
•El control de proceso empírico y la entrega

iterativa hacen que los proyectos sean
adaptables y abiertos a la incorporación del
cambio.
Beneficios de Scrum
•Todos los emisores de información, tales como

el Scrumboard y el Sprint Burndown Chart son
compartidos, lo cual lleva a un ambiente laboral
abierto.
Beneficios de Scrum
•Los procesos de Realizar el Daily Standup y

Demostrar y validar el sprint permiten una
constante retroalimentación.
Beneficios de Scrum
•Los entregables mejoran progresivamente

sprint tras sprint mediante el proceso de Refinar
el Backlog Priorizado del Producto.
Beneficios de Scrum
•El proceso iterativo permite la entrega

constante de valor mediante el proceso de
Enviar entregables, tan frecuentemente como el
cliente lo requiera.
Beneficios de Scrum
•Los procesos de Scrum están diseñados para

que las personas involucradas puedan trabajar a
un ritmo sostenido al que pueden, en teoría,
continuar en forma indefinida.
Beneficios de Scrum
•El proceso de Crear el backlog priorizado del

producto garantiza que los requerimientos de
alto valor del cliente se cumplan primero.
Beneficios de Scrum
•La asignación de un tiempo específico (Time-

boxing) y la reducción del trabajo no esencial
llevan a niveles más altos de eficiencia.
Beneficios de Scrum
•Los procesos de Realizar Daily Standup y

Retrospectiva del sprint conducen a mayores
niveles de motivación entre los empleados.
Beneficios de Scrum
•La colaboración y la co-ubicación de equipos

interfuncionales conducen a la resolución de
problemas con mayor rapidez
Beneficios de Scrum
•El proceso de Crear el Backlog Priorizado del

Producto y las revisiones periódicas después de
la creación de entregables aseguran entregas
eficientes al cliente.
Beneficios de Scrum
•El énfasis en el valor del negocio y contar con un

enfoque colaborativo con los stakeholders
asegura un framework orientado al cliente.
Beneficios de Scrum
•Los procesos de Realizar Daily Standup y

Retrospectiva del sprint promueven la
transparencia y la colaboración, llevando a un
ambiente laboral de alta confianza y
garantizando una baja fricción entre los
empleados.
Beneficios de Scrum
•El proceso de Comprometer historias de

usuarios permite a los miembros del equipo
asumir la propiedad del proyecto, resultando en
una mejor calidad.
Beneficios de Scrum
•Un framework colaborativo permite que los

equipos interfuncionales altamente cualificados
logren todo su potencial y una alta velocidad.
Beneficios de Scrum
•Los procesos de Retrospectiva del sprint y

Retrospectiva del proyecto crean un ambiente
de introspección, aprendizaje y adaptabilidad, lo
cual resulta en un ambiente laboral innovador y
creativo.
Principios de
SCRUM
Principios de Scrum
Figura 1-3: Principios de Scrum. SBOK, página 9

Detalles adicionales: SBOK, páginas 23-39
Principios de Scrum
Los principios de Scrum son la base en la que

se sostiene el framework de Scrum.
Los principios de Scrum se pueden aplicar a
cualquier tipo de proyecto en cualquier
organización.
Deben cumplirse a fin de garantizar la
aplicación efectiva del framework de Scrum.
Principios de Scrum
Los aspectos y procesos de Scrum pueden ser modificados.
Los principios de Scrum no están abiertos a la discusión ni pueden
modificarse, y deben aplicarse tal como se especifica en la Guía
SBOK™.
Mantener los principios intactos y usarlos apropiadamente infunde
confianza en el framework de Scrum respecto al cumplimiento de los
objetivos del proyecto.
Control de
proceso
empírico
Principios de Scrum Control de proceso empírico
¿Cuáles son las tres

¿Cómo se toman principales
las decisiones en características del
Scrum? Control de proceso
empírico?
Control de proceso empírico - Transparencia
La transparencia permite que todas las facetas de cualquier proceso de

Scrum sean observadas por cualquiera.
Esto promueve un flujo de información fácil y transparente en toda la
organización y crea una cultura de trabajo abierta.
Control de proceso empírico - Transparencia
Figura 2-1: Transparencia en Scrum. SBOK, página 25

Control de proceso empírico - Inspección
La inspección en Scrum se representa mediante lo siguiente:

Uso de un Scrumboard común y otros emisores de información que
muestran el progreso del Equipo Scrum en completar las tareas del
sprint actual.
Recopilación de la retroalimentación del cliente y otros stakeholders
durante los procesos de Desarrollar de épica(s), Crear Backlog
Priorizado del Producto y Realizar planificación del lanzamiento.
La inspección y aprobación de los entregables por parte del Product
Owner y el cliente en el proceso de Demostrar y validar el sprint.
Control de proceso empírico - Inspección
Figura 2-2: Inspección de Scrum. SBOK, página 26

Control de proceso empírico - Adaptación
La adaptación se da cuando el equipo principal de Scrum y los

stakeholders aprenden mediante la transparencia y la inspección, y
después se adaptan al hacer mejoras en el trabajo que llevan a cabo.
Figura 2-3: Adaptación en Scrum. SBOK, página 27

Figura 2-3: Retos de la gestión de proyectos, página 28

AUTO-
organización
Principios de Scrum – Auto-organización
En Scrum se cree que los empleados se auto-motivan y buscan aceptar

más responsabilidades. Por lo tanto, presentan mucho más valor
cuando se auto-organizan.
La auto-organización no significa que a los miembros del equipo se les
permita actuar como quieran.
Principios de Scrum – Liderazgo servicial
El estilo preferido de liderazgo en Scrum es el

liderazgo servicial que hace énfasis en el logro de
resultados enfocándose en las necesidades del
Equipo Scrum.
Auto-organización – Objetivos de un equipo auto-organizado
Figura 2-5: Objetivos de un equipo de auto-organizado. SBOK, página 30

Colaboración
Principios de Scrum - Colaboración
• La colaboración en Scrum se refiere a que el Equipo Principal de

Scrum trabaja e interactúa con los stakeholders para crear y validar
los resultados del proyecto a fin de cumplir con los objetivos que se
plantean en la visión del proyecto.
• Cooperación
Sucede cuando el producto del trabajo consiste en la suma del esfuerzo del
trabajo de varias personas en un equipo.
• Colaboración
Sucede cuando un equipo trabaja en conjunto para aprovechar el aporte de
cada uno y producir algo más grande.
Dimensiones centrales del trabajo colaborativo
Conocimiento: Las personas que trabajan juntas deben estar al tanto del
trabajo de los demás
Articulación: Los colaboradores deben distribuir el trabajo en unidades;
dividir las unidades entre los miembros del equipo y después reintegrarlo
cuando el trabajo esté hecho.
Apropiación: Adaptar la tecnología a la situación individual; la tecnología
se puede utilizar de forma completamente distinta a lo esperado por los
diseñadores.
Beneficios de la colaboración
Figura 2 6: Beneficios de la colaboración en proyectos Scrum. SBOK, página 32

Principios de Scrum – Colaboración
Importancia de la co-ubicación en la colaboración

Para las prácticas de Scrum, se necesita una
comunicación de high-bandwidth. Por tanto, es
preferible que los miembros del equipo estén
co-ubicados.
La co-ubicación (del inglés colocation), permite
la interacción formal e informal entre los
miembros del equipo. Esto brinda la ventaja de
contar con miembros del equipo siempre a la
mano para facilitar la coordinación, la
resolución de problemas y el aprendizaje.
• Importantes beneficios de la co-ubicación.
• Las preguntas se contestan rápidamente.

• Los problemas se solucionan en ese momento.
• Existe menor fricción entre las interacciones.
• La confianza se gana con mucha más rapidez.
Herramientas de colaboración – Equipos co-ubicados
Interacciones cara a cara.
Sala de decisiones o War Rooms
Scrumboards
Exposiciones en la pared
Mesas compartidas
Herramientas de colaboración – Equipos distribuidos
Videoconferencias
Mensajería instantánea
Chats
Redes sociales
Monitores compartidos
Versiones de Scrumboard en software,
material visual de uso común, etc.
Priorización
Basado en
valor
Principios de Scrum – Priorización basada en valor
El framework de Scrum se guía por la finalidad de ofrecer el máximo

valor de negocio en un mínimo período de tiempo.
Una de las herramientas más eficaces para entregar el mayor valor en
el menor tiempo posible es la priorización.
La priorización se puede definir como la determinación del orden y la
separación de lo que debe hacerse ahora, de lo que debe hacerse
después.
Scrum utiliza la priorización basada en valor (Value-based

Prioritization) como uno de los principios básicos que impulsa la
estructura y funcionalidad de todo el framework de Scrum.
Ayuda a que los proyectos se beneficien mediante la capacidad de
adaptación y el desarrollo iterativo.
Scrum tiene como finalidad entregar un producto o servicio valioso
para el cliente en forma oportuna y continua.
La priorización la lleva a cabo el Product Owner cuando

prioriza las historias de usuario en el Backlog Priorizado del
Producto.
Este backlog contiene una lista de todos los requisitos
necesarios para llevar el proyecto a buen término.
El/la Product Owner trabaja con el cliente y el patrocinador
para entender los requerimientos del negocio que
proporcionan el máximo valor del negocio.
Los requerimientos de alto valor son identificados y se colocan
al principio del Backlog Priorizado del Producto.
• Product Owner debe trabajar con el Equipo Scrum para entender los
riesgos y la incertidumbre del proyecto.
• Estos riesgos se deben de tener en cuenta al priorizar las historias de
usuario.
• El Equipo Scrum también alerta al Product Owner sobre las
dependencias que surgen de la implementación.
Al priorizar las historias de usuario en el Backlog Priorizado del

Producto se consideran los siguientes tres factores:
Figura 2-7: Priorización basada en valor. SBOK, página 35

Time Boxing
Principio de Scrum - Time-boxing
Scrum trata al tiempo como uno de los limitantes más importantes en la

gestión de un proyecto.
Para hacer frente a la restricción del tiempo, Scrum introduce un concepto de

Time-boxing (o asignación de un bloque de tiempo), que propone la fijación de
una cierta cantidad de tiempo para cada proceso y actividad en un proyecto
Scrum.
Esto garantiza que los miembros del Equipo Scrum no ocupen demasiado o muy
poco tiempo para un trabajo determinado, y que no desperdicien su tiempo y
energía en un trabajo para el cual tienen poca claridad.
Ventajas del Time-boxing son las siguientes:
• Proceso de desarrollo eficiente
• Menos gastos generales
• Alta velocidad para los equipos

• El Time-boxing puede utilizarse para evitar la mejora

excesiva de un elemento.
Figura 2 8: Duración de los bloques de tiempo (Time-Box) para las reuniones

de Scrum. SBOK, p. 38
Desarrollo
Iterativo
Principios de Scrum – Desarrollo iterativo
El Scrum framework está guiado por el objetivo de ofrecer el máximo valor

empresarial en un mínimo período de tiempo.
Para lograr esto en forma práctica, Scrum cree en el desarrollo iterativo de
entregables.
En la mayoría de los proyectos complejos, el cliente puede tal vez no pueda
definir requisitos muy concretos o pudiera no estar seguro sobre cómo
debería de ser el producto final.
El modelo iterativo es más flexible para asegurar que cualquier cambio que
solicite el cliente se pueda incluir como parte del proyecto.
Principios de Scrum – Desarrollo iterativo
Figura 2 9: Scrum vs Cascada tradicional. SBOK, página 40

Desarrollo iterativo - ¿Cómo funciona?
Las historias de usuario tal vez tengan que ser escritas constantemente durante el
proyecto. En las etapas iniciales de redacción, la mayoría de las historias son las
funcionalidades de alto nivel.
Estas historias de usuario se conocen como épica(s). Las épicas generalmente son
muy grandes como para que los equipos las completen en un sólo sprint, y por lo
tanto se dividen en pequeñas historias de usuario.
Cada aspecto complejo del proyecto se divide mediante la elaboración progresiva
durante el proceso Refinar el Backlog Priorizado del Producto.
Desarrollo iterativo - ¿Cómo funciona?
En cada sprint, el proceso de Crear entregables se utiliza para desarrollar las
salidas del sprint. El Scrum Master tiene que garantizar que se sigan los procesos
de Scrum y facilitar al equipo el trabajo de la manera más productiva.
El Equipo Scrum se auto-organiza, teniendo como objetivo el crear entregables

del sprint a partir de las historias de usuario que están en el Sprint Backlog.
En grandes proyectos, varios equipos interfuncionales trabajan en paralelo a
través de los sprints, proporcionando soluciones potencialmente entregables al

final de cada sprint.
Después de completar cada sprint, el Product Owner acepta o rechaza los

entregables con base a los criterios de aceptación del proceso de Demostrar y
validar el sprint.
Desarrollo iterativo - Beneficios
El beneficio del desarrollo iterativo permite la

corrección a medida que todas las personas
involucradas obtengan una mejor comprensión de
lo que se debe entregar como parte del proyecto, e
incorporar lo aprendido de manera iterativa.
Así, el tiempo y el esfuerzo requerido para alcanzar
el punto final definitivo, se reduce
considerablemente y el equipo produce entregables
que se adaptan mejor al entorno empresarial.
Aspecto de
SCRUM
Aspectos de Scrum
Organización
Aspectos de Scrum – Organización
Es muy importante entender los roles y responsabilidades en un proyectos Scrum a
fin de asegurar su implementación exitosa.
Los roles de Scrum se dividen en dos amplias categorías:

1. Roles centrales
2. 2. Roles no centrales
Organización – Roles centrales
• Los roles centrales son aquellos que se requieren obligadamente para
crear el producto o servicio del proyecto. Las personas a quienes se
les asignan los roles centrales están plenamente comprometidas con
el proyecto y son las responsables del éxito de cada iteración del
mismo, así como del proyecto en su totalidad.
Responsable de lograr el máximo valor de
Product Owner
negocio para el proyecto.
Articula los requerimientos del cliente.
Mantiene la justificación del negocio para el
proyecto.
Representa la voz del cliente.
Scrum Master Se asegura que el Equipo Scrum cuenta con
un ambiente conductivo para completar con
éxito el proyecto.
Guía, facilita y enseña las prácticas de Scrum
a todos los involucrados en el proyecto.
Elimina impedimentos en el equipo.
Se asegura de que se estén siguiendo los
procesos de Scrum.
Equipo Scrum Responsable de entender los
requerimientos especificados por el
Product Owner.
Crea los entregables del proyecto.

Organización – Roles no centrales
Los roles no centrales son los que no son necesariamente obligatorios
para el proyecto Scrum, y estos pueden incluir a miembros de los
equipos que estén interesados en el proyecto.
No tienen ningún rol formal en el equipo del proyecto, y pueden
interactuar con el equipo, pero pueden no ser responsables del éxito
del proyecto.
Los roles no centrales deben tenerse en cuenta en cualquier proyecto
de Scrum.
Organización – Roles no
centrales
Stakeholders Es un término colectivo que incluye a clientes,

usuarios y patrocinadores.
Los stakeholders interactúan frecuentemente
con el Equipo Principal de Scrum e influyen en
el proyecto durante su desarrollo.
Lo más importante: los beneficios
colaborativos del proyecto son para los
stakeholders.
Scrum Guidance • Es un rol opcional que generalmente
Body (SGB) consiste en un conjunto de documentos
y/o un grupo de expertos que
normalmente están involucrados en la
definición de los objetivos relacionados
con la calidad, las regulaciones
gubernamentales, la seguridad y otros
parámetros claves de la organización.
• El SGB guía el trabajo llevado a cabo por
el Product Owner, el Scrum Master y el
Equipo Scrum.
Vendedores Los vendedores, incluyendo a individuos

u organizaciones externas, ofrecen
productos y/o servicios que no están
dentro de las competencias centrales de
la organización del proyecto.
Organización – Resumen de roles
Figura 3-1: Roles de Scrum. Guía SBOK, página 13

Organización – Selección de personal
Figura 3-3:Características deseadas de los roles centrales. Guía SBOK, página 56

Scrum en toda la organización
Figura 3-5: Scrum para proyectos, programas y portafolios en la

organización. SBOK, página 57
Justificación
del negocio
Aspectos de Scrum – Justificación del
negocio
Es importante que una organización lleve a cabo una evaluación
adecuada del negocio antes de iniciar cualquier proyecto.
Esto ayuda a los principales tomadores de decisiones a entender la
necesidad de cambio en la empresa o de un nuevo producto o servicio,
la justificación para seguir adelante con un proyecto y su viabilidad.
Justificación del negocio – Entrega
basada en valor
En Scrum, la justificación del negocio se basa en el concepto de entrega
basada en valor (Value-driven Delivery).
Una de las características clave de cualquier proyecto es la incertidumbre
sobre los resultados.
Es imposible garantizar el éxito de un proyecto, independientemente del
tamaño o la complejidad del mismo.
Considerando esta inseguridad de alcanzar el éxito, Scrum busca iniciar la
entrega de resultados lo antes posible en el proyecto.
Esta entrega temprana de resultados, y por lo tanto de valor, proporciona
una oportunidad para la reinversión y demuestra el valor del proyecto a los
stakeholders interesados.
Justificación del negocio –
Responsabilidades del Pruduct
Owner
Figura 4-2: Jerarquía de responsabilidades en la justificación del negocio

Tabla 4-2: Jerarquía de responsabilidades en la justificación
del negocio
Responsabilidades
Justificación del negocio –
Entrega basada en valor en Scrum vs.
Proyectos tradicionales
Figura 4-1: Entrega de valor en Scrum vs. Proyectos tradicionales.

SBOK, página 70
Pasos para determinar la entrega
basada en valor
Figura 4 3: Justificación del negocio y el ciclo de vida del proyecto.

SBOK, página 74
La calidad
Aspectos de Scrum - Calidad
La calidad se define como la capacidad con la que cuenta el producto o los
entregables para cumplir con los criterios de aceptación y de alcanzar el
valor de negocio que el cliente espera.
Los criterios de aceptación son los componentes objetivos mediante los
cuales se juzga la funcionalidad de una historia de usuario.
Los criterios de aceptación deben delinear explícitamente las condiciones
que deben satisfacer las historias de usuario.
Para asegurar que un proyecto cumpla con los requisitos de calidad, Scrum
adopta un enfoque de mejora continua donde el equipo aprende de sus
experiencias y de la participación de los stakeholders para mantener
constantemente actualizado el Backlog Priorizado del Producto con cualquier
cambio en los requerimientos.
Dicha lista nunca está completa hasta el cierre o conclusión del

proyecto.
Cualquier cambio en los requisitos refleja los cambios en el entorno
empresarial interno y externo y permite que el equipo funcione
continuamente y se adapte para alcanzar esos requisitos.
Debido a que Scrum requiere que el trabajo se realice en incrementos
durante los sprints, esto hace que los errores o defectos se noten con
más facilidad mediante pruebas de calidad repetitivas y no
simplemente cuando el producto final o servicio esté casi terminado.
Por otra parte, las tareas relacionadas a la calidad (por ejemplo,

desarrollo, pruebas y documentación) se completan como parte del
mismo sprint por el mismo equipo. Esto asegura que la calidad sea
inherente a cualquier entregable que se crea como parte de un sprint.
Las discusiones constantes entre el equipo principal de Scrum y los
stakeholders (incluyendo los clientes y los usuarios), junto con
incrementos reales del producto que se entregan al final de cada
sprint, aseguran que la brecha entre las expectativas de los clientes del
proyecto y los verdaderos entregables se reduzca constantemente.
Calidad- Criterios de aceptación y el flujo
de incremento del producto
Figura 5-1:Diagrama de flujo del incremento de proyecto, página 93

Calidad- Criterios mínimos de terminado
Figura 5-2:Criterios de terminado en cascada, página 95

Ciclo de planificar, hacer, verificar y actuar
(Ciclo PDCA, por sus siglas en inglés)
Figura 5-3: Ciclo PDCA en Scrum. SBOK, página 98

Cambio
Aspectos de Scrum - Cambio
Cada proyecto, independientemente de su método o framework,

está expuesto al cambio.
Es importante que los miembros del equipo del proyecto entiendan
que los procesos de desarrollo de Scrum están diseñados para
aceptar el cambio.
Las organizaciones deben tratar de maximizar los beneficios que se
derivan de los cambios y disminuir los impactos negativos a través de
los procesos de gestión de cambio diligente según los principios de
Scrum.
Aspectos de Scrum - Cambio
Un principio fundamental de Scrum es su reconocimiento de que
a) Los stakeholders (clientes, usuarios y patrocinadores) cambian de opinión acerca de lo
que quieren y lo que necesitan durante un proyecto (a esto se le conoce en ocasiones
como: “requisitos volátiles” o requirements churn);
b) Que es muy difícil, si no es que imposible, que los stakeholders definan todos los
requisitos al inicio del proyecto.
Los proyectos Scrum aceptan los cambios mediante el uso de sprints breves e iterativos que
incorporan la retroalimentación del cliente sobre los entregables del proyecto después de
cada sprint.
Esto permite que el cliente interactúe regularmente con los miembros del Equipo Scrum,
que vea los entregables a medida que estén listos y que cambie los requisitos
tempranamente en el ciclo de desarrollo.
Esto permite que el cliente interactúe regularmente con los miembros del Equipo Scrum,
que vea los entregables a medida que estén listos y que cambie los requisitos
tempranamente en el ciclo de desarrollo.
Cambio – Proceso de aprobación
de cambios
Figura 6-1: Ejemplo del proceso de aprobación de cambios. SBOK,

página 103
Cambio - Actualización del Backlog Priorizado
del Producto con los cambios aprobados
Figura 6 2: Actualización del Backlog Priorizado del Producto con los

cambios aprobados. SBOK, página 104
Cambio –Lograr la flexibilidad
Figura 6 2: Características de Scrum para lograr la flexibilidad. SBOK, página

107
Cambio – Motivos del cambio (Stakeholders)
Figura 6 : Motivación de los stakeholders para la solicitud de cambios

SBOK, página 108
Cambio – Motivos del cambio (Equipo principal
de Scrum)
Figura 6 : Motivación del equipo principal de Scrum para la solicitud de

cambios. SBOK, página 108
Cambio – Integración del cambio en Scrum
Figura 6 6: Integración del cambio en Scrum. SBOK, página 111

Cambio - Incorporación de cambios en
portafolios y programas
Figura 6-8: Incorporación de cambios en portafolios y programas. SBOK, página

117
Riesgo
Aspectos de Scrum - Riesgo
El riesgo se define como un evento incierto o

serie de eventos que pueden afectar los
objetivos de un proyecto y pueden contribuir
a su éxito o fracaso.
• Ejemplo:
Uno de los principales inversionistas en un proyecto pudiera retroceder
en un momento crítico. Esto es un riesgo que afecta negativamente al
proyecto.
En caso de que el proyecto encuentre a un mejor inversionista
dispuesto a invertir más y mejor, esto se puede considerar como una
oportunidad.
Riesgo – Procedimiento para la gestión de
riesgos
1. Identificación de riesgos: Utilizar diversas técnicas para identificar
todos los riesgos potenciales.
2. Evaluación de riesgos: Evaluar y estimar los riesgos identificados.
3. Priorización de riesgos: Dar prioridad al riesgo que habrá de
incluirse en el Backlog Priorizado del Producto.
4. Mitigación de riesgos: Desarrollar de una estrategia adecuada para
hacer frente a un riesgo.
5. Comunicación de riesgos: Comunicar a los stakeholders apropiados
los resultados de los primeros cuatros pasos de la gestión de
riesgos y determinar su percepción respecto a eventos inciertos.
Procedimiento para la gestión de riesgos
Los riesgos deben ser identificados, evaluados y atendidos con base a dos
factores:
• La probabilidad de ocurrencia de cada riesgo.

• El posible impacto en el caso de tal ocurrencia.
Los riesgos con una alta probabilidad y valor de impacto (que se calcula
multiplicando ambos factores) deben ser atendidos primero que aquellos
con un valor relativamente bajo.
En general, una vez que se detecta un riesgo, es importante entender el
mismo en relación con las causas probables y los posibles efectos.
Riesgo – Proceso de priorización de
riesgos
Figura 7 4: Proceso de priorización de riesgos. SBOK, página 129

Riesgo - Manejo de riesgos en portafolios y
programas
Figura 7-6: Manejo de riesgos en portafolios y programas. SBOK,

página 134
Riesgo – Técnicas de evaluación
Figura 7-1: Ejemplo de árbol de probabilidad, página 128

Figura 7-1: Ejemplo de diagrama de Pareto, página 129

Figura 7-1: Ejemplo de diagrama de Pareto, página 129

Fases y procesos
de Scrum
.
Fases y procesos de Scrum
Los procesos de Scrum abordan las actividades específicas y el flujo de

un proyecto de Scrum. En total hay 19 procesos agrupados en 5 fases.
Fases y procesos de Scrum
Tabla 1 1: Resumen de los procesos fundamentales de Scrum.

SBOK, página 16
Inicio
Fase de Scrum: Inicio
Figura 8-2: Resumen de la fase de inicio; SBOK, página 144

Fase de Scrum - Inicio
Se revisa el Caso de negocio del proyecto

(Project Business Case) para crear la
Declaración de la visión del proyecto
(Project Vision Statement).
Se identifica al Product Owner.
Fase de Scrum – Inicio
Figura 8-3: Crear la visión del proyecto – Entradas, Herramientas y Salidas; SBOK, página 145
Fase de Scrum – Inicio - Entradas
Caso de negocio del proyecto*
Program Product Owner / Program Scrum Master / Program Stakeholder(s)
Proyecto de prueba: la demostración o proyecto de prueba como experimento para

predecir y evaluar la viabilidad, el tiempo, el costo, los riesgos y los posibles efectos
del proyecto.
Prueba de concepto: la prueba del concepto demuestra y verifica que la idea detrás
del proyecto actual sea potencialmente viable en la vida real.
Visión de la empresa: entender la visión de la empresa ayuda a que el proyecto

mantenga su enfoque en los objetivos de la
organización y el futuro probable de la empresa.
Misión de la empresa: la misión de la empresa ofrece un framework para formular las

estrategias de la empresa y orienta la toma de decisiones generales en la compañía.
Estudio de mercado: preferencias de los clientes sobre los productos.
Recomendaciones del Scrum Guidance Body: es importante asegurarse de que la

visión del proyecto esté en línea con las recomendaciones proporcionadas por el
Scrum Guidance Body y que los procesos cumplan con las normas y directrices
establecidas por dicho organismo
Fase de Scrum – Inicio - Herramientas
Reunión de la visión del proyecto*: Esta ayuda a identificar el contexto empresarial,
los requerimientos de negocio y las expectativas de los stakeholders a fin de
desarrollar una declaración de la visión del proyecto eficaz.
Sesiones JAD: sesión de diseño de aplicación conjunta, es una técnica de recopilación

de requisitos. Es taller impartido y altamente estructurado que acelera el proceso de
Crear la visión del proyecto, ya que permite al(los) stakeholder(s) y a otras personas
que toman decisiones llegar a un consenso sobre el alcance, los objetivos y otras
especificaciones del proyecto.
Análisis FODA
Análisis de brecha: en una organización, esto involucra determinar y documentar la

diferencia entre las capacidades actuales del negocio y el conjunto final de
capacidades deseado.
Fase de Scrum – Inicio - Salidas
Product Owner identificado*
Declaración de la visión del proyecto*
Análisis FODA
Análisis de brecha: en una organización, esto involucra determinar y documentar la

diferencia entre las capacidades actuales del negocio y el conjunto final de
capacidades deseado.
Acta constitutiva del proyecto (Project Charter): es una declaración oficial de los
objetivos y resultados deseados del proyecto. En varias organizaciones, el acta
constitutiva del proyecto es el documento que autoriza el proyecto oficial y
formalmente, dándole al equipo la autoridad por escrito para iniciar el proyecto.
Presupuesto del proyecto: El presupuesto del proyecto es un documento financiero

que incluye el costo del personal, materiales y otros gastos relacionados en un
proyecto.
Fase de Scrum – Inicio
Figura 8-3: Crear la visión del proyecto -

Diagrama de flujo de datos; SBOK, página 145
Se identifican el/la Scrum Master y

Stakeholder(s) utilizando criterios de
selección específicos.
Figura 8-8: Identificar al Scrum Master y stakeholder(s)-

Entradas, herramientas y salidas; SBOK, página 153
Product Owner*
Program Product Owner
Programa Scrum Master
Program Stakeholder(s)
Requerimientos de las personas
Disponibilidad y compromiso de las personas: antes de seleccionar al Scrum Master y

stakeholder(s) debe confirmarse su disponibilidad. Solamente deben seleccionarse los
miembros del equipo que estarán disponibles y que puedan comprometerse plenamente
con el proyecto.
Matriz de recursos organizacionales: es una representación jerárquica de una combinación

de una estructura de organización funcional y una estructura organizativa proyectada.
Matriz de requerimientos de habilidades: también llamada framework de competencia, se

utiliza para evaluar las carencias de habilidades y los requisitos de formación para los
miembros del equipo.
Recomendaciones del Scrum Guidance Body

Criterios de selección*: Habilidades para resolver problemas,
disponibilidad, compromiso y estilo de liderazgo servicial
Asesoramiento de expertos recursos humanos
Capacitación y costos de capacitación
Costo de los recursos: una de las principales consideraciones en la

selección de las personas tiene que ver con las ventajas y
desventajas relacionadas con el nivel de experiencia en comparación
al salario
Scrum Master identificado*
Stakeholder(s) identificado(s)*
Figura 8-8: Identificar al Scrum Master y

stakeholder(s)-Diagrama de flujo de datos; SBOK,
página 154
Se identifican a los miembros del Equipo

Scrum.
El/la Product Owner es responsable de
seleccionar a los miembros del equipo;
generalmente en colaboración con el
Scrum Master.
Figura 8-8: Formar equipo Scrum- Entradas, herramientas y

salidas; SBOK, página 159
Product Owner*
Scrum Master*
Program Product Owner
Programa Scrum Master
Program Stakeholder(s)
Requerimientos de las personas
Disponibilidad y compromiso de las personas
Matriz de recursos organizacionales
Matriz de requerimientos de habilidades
Requisitos de recursos
Recomendaciones del Scrum Guidance Body

Selección del Equipo Scrum*
Asesoramiento de expertos en recursos humanos
Costos del personal
Capacitación y costos de capacitación
Costo de los recursos

Equipo Scrum identificado*
Substitutos (Back-up Persons)
Plan de colaboración: La colaboración es un elemento muy importante en Scrum. La

planificación de cómo interactúan y colaboran los tomadores de decisiones, los
stakeholder y los miembros del equipo es de suma importancia. El plan de
colaboración es una salida opcional que puede ser formal o informal.
Plan de formación del equipo

Figura 8-8: Formar equipo Scrum- Diagrama de flujo

de datos; SBOK, página 160
La Declaración de la visión del proyecto (Project Vision

Statement) sirve como base para el desarrollo de
épicas.
Las épicas son historias de usuario grandes sin refinar
en el Backlog Priorizado del Producto que no pueden
se entregadas en un solo ciclo de sprint.
Los prototipos se crean para identificar las necesidades
de los usuarios.
Los prototipos, conocidos en inglés como personas,
son personajes ficticios altamente detallados que
representan a la mayoría de los usuarios y demás
stakeholders que pudieran no utilizar directamente el
producto final. Los prototipos se crean para identificar
las necesidades de los usuarios.
Figura 8-10:Desarrollar épica(s)-Entradas, herramientas y salidas

; SBOK, página 166
Contratos aplicables:
Contrato de entrega incremental (Incremental Delivery Contract)—Este
contrato incluye puntos deinspección en intervalos frecuentes.
Contrato Joint Venture—Este tipo de contratos se utiliza generalmente
cuando dos o más partes se asocian para realizar el trabajo de un proyecto.
Contrato de desarrollo en fases (Development in Phases Contract)—Este
contrato facilita la disponibilidad de fondos cada mes o cada trimestre
después de concluir satisfactoriamente un lanzamiento.
Contrato de incentivos y sanciones—Este contrato se basa en el acuerdo de
que el proveedor será recompensado con un incentivo económico si los
productos del proyecto se entregan a tiempo, pero incurrirá en sanciones
económicas si la entrega se realiza tarde.
Figura 8-11:Desarrollar épica(s)-Diagrama de flujo; SBOK, página 166

Fase de inicio – Ejemplo de prototipo
Vanessa tiene 39 años de edad y

es residente de San Francisco. Le
apasionan los viajes y después de
haber tenido una exitosa carrera
como abogada, ha decidido
disfrutar de dicha pasión. Le gusta
tener opciones disponibles al
seleccionar sus viajes por avión y
servicios de alojamiento para
poder elegir el mejor a un precio
accesible. Se frustra con los sitios
web lentos y desordenados.
Las épicas son historias de usuario grandes

sin refinar en el Backlog Priorizado del
Producto.
También se establecen los criterios de
terminado.
Los criterios de terminado son un conjunto
de reglas que se aplican a todas las historias
de usuarios. Es importante contar con una
definición clara de terminado, ya que elimina
la ambigüedad de los requisitos y ayuda a
que el equipo se apegue a las normas
obligatorias de calidad.
Las épicas son historias de usuario grandes

sin refinar en el Backlog Priorizado del
Producto.
También se establecen los criterios de
terminado.
Los criterios de terminado son un conjunto
de reglas que se aplican a todas las historias
de usuarios. Es importante contar con una
definición clara de terminado, ya que elimina
la ambigüedad de los requisitos y ayuda a
que el equipo se apegue a las normas
obligatorias de calidad.
Figura 8-3: Crear el Backlog Priorizado del producto-

Métodos de priorización de las historias de usuarios:
Esquema de priorización MoSCoW—El esquema de priorización MoSCoW
obtiene su nombre de la versión en inglés de las frases: “Debe tener” (Must
have), “Debería tener” (Should have), “Podría tener” (Could have) y “No
tendrá” (Won’t have).
Comparación por pares: se comparan dos historias de usuario, se toma una decisión
en cuanto a cuál de las dos es más importante.
El método de los 100 puntos: implica otorgar 100 puntos al cliente a fin de que los
pueda utilizar para votar por las características que consideren 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 usuario disponibles.
Análisis de Kano:
1. Calidad atractiva (Exciters/Delighters): Características que son nuevas o de gran
valor para el cliente
2. Calidad unidimensional (Satisfiers): Características que le ofrecen valor al cliente
3. Calidad requerida (Dissatisfiers): Características que, si no están presentes, pudieran
causar la insatisfacción del cliente respecto al producto, pero que no afectan el nivel de
satisfacción si se cuenta con ellas.
4. Calidad indiferente (Indifferent): Características que no afectarán al consumidor de
ninguna manera y deben ser eliminadas.
Figura 8-3: Crear el Backlog Priorizado del producto-

El Equipo Principal de Scrum revisa las

historias
de usuario de alto nivel en el Backlog
Priorizado
del Producto para desarrollar un programa
de
planificación del lanzamiento.
Se determina la duración del sprint.
Figura 8-3: Realizar la planificación del lanzamiento-

Figura 8-3: Realizar el plan de lanzamiento- diagrama

de flujo de datos; SBOK, página 174
Fase de inicio – Diagrama de flujo de datos
Figura 8 16: Fase de inicio—Diagrama del flujo de

datos. SBOK, página 183
Planificación
y estimación
Fase de Scrum: Planificación y estimación
Figura 9-2: Resumen de la fase de Planificación y estimación; SBOK, Página 192

• Se crean las historias de usuario y los criterios

de aceptación de las historias de usuario.
• Generalmente las escribe el Product Owner.
• Están diseñadas para asegurar que los
requisitos del cliente estén claramente
representados.
• Los miembros del Equipo Scrum participan en
la creación de historias de usuario.
• Se incorporan en el Backlog Priorizado del
Producto.
• Indican tres cosas sobre el requerimiento:
¿Quién? ¿Qué? ¿Por qué?
Figura 9-4: Crear historias de usuario—Diagrama de flujo de datos

Figura 9-4: Crear historias de usuario—Diagrama de flujo de datos

Fase de Planificación y estimación
Formato de historias de usuario
Como <rol/prototipo de clientes>yo

debería <requerimiento> a fin de
<beneficio>.
Fase de Planificación y estimación Ejemplos de
historias de usuario
Como administrador de una base de datos, debo contar con la

capacidad de revertir una cantidad selecta de actualización de la base
de datos a fin de que se restablezca a la versión deseada.
Como desarrollador web, debo poder rastrear los datos de usuario
mediante un Login único para permitir la personalización de las ofertas
de producto o servicio a los visitantes.
Como cliente, debo poder iniciar sesión como visitante para poder ver
las ofertas sin necesidad de registro por falta de tiempo.
El/la Product Owner aclara las historias de

usuario.
El/la Scrum Master y el Equipo Scrum
estiman el esfuerzo necesario para
desarrollar la funcionalidad descrita en cada
historia de usuario.
Figura 9-5: Estimar historias de usuario—Entradas, herramientas y salidas

Herramientas
Al momento de desarrollar los criterios de aceptación de historias de usuario,

se debe tener en cuenta lo siguiente:
• Los criterios de aceptación no deben ser confusos, ambiguos o demasiado
generalizados.
• Los criterios de aceptación definidos deben garantizar que el equipo pueda
verificar que los resultados estén alineados con las metas y objetivos de la
organización que patrocina.
Los criterios de estimación pueden expresarse de muchas formas. Dos

ejemplos comunes son los puntos de historia y el tiempo ideal. Los valores de
puntos de historia se utilizan para representar el esfuerzo relativo o
comparativo para completar tareas. Mientras que el tiempo ideal
normalmente describe el número de horas que los miembros de un Equipo
Scrum trabajan exclusivamente en el desarrollo de los entregables del
proyecto sin incluir ningún tiempo dedicado a otras actividades o a trabajo
ajeno al proyecto.
Los mismos métodos de estimación utilizados para estimar historias de

usuario se pueden aplicar también a las tareas.
Salidas
La llama Effort Estimated Task List* (lista de tareas del esfuerzo

estimado) es una lista de tareas asociadas con las historias de usuario
incluidas en un sprint. Típicamente la precisión de las estimaciones
varía dependiendo de las habilidades del equipo El esfuerzo estimado
se expresa en términos de los criterios de estimación acordados por
el equipo. El Equipo Scrum utiliza la Effort Estimated Task List durante
las reuniones de planificación del sprint a fin de crear el Sprint
Backlog y el Sprint Burndown Chart. Se utiliza también para
determinar cuándo el equipo necesita reducir su compromiso o
asumir historias de usuario adicionales durante la planificación del
sprint.
Lista de tareas actualizada*

Figura 9-5: Estimar historias de usuario—Entradas, herramientas y salidas

El/la Scrum Master y el Equipo Scrum se

comprometen a entregar las historias de
usuario (aprobadas por el Product Owner)
para un sprint.
Figura 9-7: Comprometer tareas—Entradas, herramientas y salidas

Métodos de estimación
El Wideband Delphi es una técnica de estimación basada en grupo para determinar la

cantidad de trabajo necesario y el tiempo que tardará en completarse. Los individuos en el
equipo proporcionan estimaciones anónimas para cada artículo y las estimaciones iniciales
se trazan en una gráfica.
En el Planning Poker, a cada miembro del equipo se le asigna una baraja. Cada carta está
enumerada en forma secuencial y los números representan la complejidad del problema en
términos de tiempo o esfuerzo, según lo estimado por el miembro del equipo. Los
miembros del Equipo Scrum evalúan el artículo (tarea o historia de usuario) e intentan
entenderlo mejor antes de brindar su estimación para su desarrollo. Después, cada
miembro elige una carta de la baraja que represente su estimación para la historia de
usuario.
El puño de cinco, o Fist of Five, es un mecanismo sencillo y rápido que se puede utilizar
como práctica de estimación, así como técnica general de formación de consenso colectivo.
Tras el debate inicial sobre sobre la estimación de un elemento, se les pide a los miembros
del Equipo Scrum que voten en una escala de 1 a 5 utilizando sus dedos.
Un dedo: No estoy de acuerdo con la conclusión del grupo y tengo grandes inquietudes.
Dos dedos: No estoy de acuerdo con la conclusión del grupo y me gustaría hablar sobre
algunos asuntos menores.
Tres dedos: No estoy seguro y me gustaría sumarme a la conclusión de consenso del grupo.
Cuatro dedos: Estoy de acuerdo con la conclusión del grupo y me gustaría discutir algunos
asuntos menores.
Estimación por afinidad (Affinity Estimation), es una técnica que se utiliza para estimar
rápidamente un gran número de historias de usuarios con el uso de categorías. Utilizando
notas adhesivas o fichas y cinta, cada equipo coloca las historias de usuario en la pared o en
cualquier otra superficie en orden desde la más pequeña hasta la más grande. Para ello,
cada integrante del equipo inicia con un subconjunto de historias de usuario de todo el
Backlog Priorizado del Producto para colocarse por tamaño relativo. Esta colocación inicial
se hace en silencio. Una vez que todos han colocado en la pared sus historias de usuario, el
equipo las revisa y las puede mover según sea necesario. Esta segunda parte del ejercicio
incluye discusiones. Por último, el Product Owner indicará en la pared algunas categorías de
tamaño.
Dichas categorías pueden ser pequeñas, medianas o grandes, o bien, pueden estar
enumeradas utilizando valores de punto de la historia (Point Story Values) para indicar el
tamaño relativo. Después el equipo reubicará las historias de usuario en dichas categorías
en el paso final del proceso. Algunos de los beneficios claves de este método son que el
proceso es muy transparente, visible para todos y fácil de llevar a cabo.
Figura 9-8: Comprometer historias de usuario—Diagrama de flujo de datos

Las historias de usuario comprometidas se

desglosan en tareas específicas y se
compilan en una lista de tareas.
Figura 9-9: Identificar tareas—Entradas, herramientas y salidas

Figura 9-10: Estimar tareas—Diagrama de flujo de datos

Figura 9-9: Identificar tareas—Entradas, herramientas y salidas

Figura 9-12: Estimar tareas—Diagrama de flujo de datos

El Equipo Principal de Scrum estima el

esfuerzo requerido para lograr cada uno en
la lista de tareas.
El resultado de este proceso es la Effort
Estimated Task List (lista de tareas del
esfuerzo estimado).
El Equipo Principal de Scrum lleva a cabo
reuniones de planificación del sprint.
Se crear el Sprint Backlog que contiene
todas las tareas a completar.
Se elabora el Sprint Burndown Chart con un
Planned Burndown.
Figura 9-10: Crear el Sprint Backlog—Entradas, herramientas y salidas

Figura 9-14: Crear el Sprint Backlog—Diagrama de flujo de datos

Diagrama de flujo de datos
Figura 9-5: Fase de planificación y estimación—Diagrama de flujo

de datos. SBOK, página 220
Implementación
Fase de Scrum: Implementación
Figura 10-2: Resumen de la implementación (Esenciales)

Fase de Scrum - Implementación
El Equipo Scrum trabaja en las tareas del

Sprint Backlog para crear los entregables del
sprint.
Generalmente se usa un Scrumboard para
dar seguimiento al trabajo y a las
actividades que se están llevando a cabo.
Los problemas que enfrente el equipo
Scrum se pueden actualizar en un
Impediment Log.
Figura 10-3: Crear entregables—Entradas, herramientas y salidas

Figura 10-4: Crear entregables—Diagrama de flujo de datos

Fase de implementación - Scrumboard
Figura 10-5: Scrumboard. SBOK, página 227

Fase de implementación – Sprint Burndown
Chart
El Sprint Burndown Chart es una gráfica que muestra la cantidad de
trabajo pendiente en el sprint en curso. El Sprint Burndown Chart
inicial va a compañado de un Planned Burndown
El Sprint Burndown Chart puede ser actualizado al final de cada día a
medida que se completan los trabajos.
Diariamente se lleva a cabo una reunión

altamente focalizada y con límite de tiempo,
conocida como Daily Standup.
Es un foro donde el Equipo Scrum se pone al
día sobre su avance y los impedimentos.
Figura 10-6: Realizar el Daily Standup—Entradas, herramientas y salidas

Figura 10-7: Realizar el Daily Standup—Diagrama de flujo de datos

Fase de implementación – Tres preguntas
diarias
Tres preguntas:
• ¿Qué he hecho desde la última reunión?
• ¿Qué tengo planeado hacer antes de la siguiente reunión?
• ¿Qué impedimentos u obstáculos (si los hubiera) estoy enfrentando
en la actualidad?
El Backlog Priorizado del Producto se

actualiza constantemente.
Se puede llevar a cabo una reunión de
revisión del Backlog Priorizado del Producto.
Cualquier cambio o actualización al backlog
se discute y se incluye en el Backlog
Priorizado del Producto.
Figura 10-8: Refinar el Backlog Priorizado del Producto—Entradas,

herramientas y salidas
Figura 10-9: Refinar el Backlog Priorizado del Producto—Diagrama

de flujo de datos
Fase de implementación – Diagrama de flujo de datos
Figura 10 10: Fase de implementación—Diagrama de flujo de

datos. SBOK, página 250
Revisión y
retrospectiva
Fase Scrum – Revisión y retrospectiva
Figura 11-2: Descripción general de la Revisión y retrospectiva (esenciales).

SBOK, página 254
El Equipo Scrum demuestra los entregables

del sprint al Product Owner en una reunión
de revisión del sprint.
El propósito de esta reunión es obtener la
aprobación y aceptación del producto o
servicio por parte del Product Owner.
Figura 11-3: Demostrar y validar el sprint—Entradas, herramientas y salidas

Figura 11-4: Demostrar y validar el sprint—Diagrama de flujo de datos

El/la Scrum Master y el Equipo Scrum se

reúnen para analizar las lecciones
aprendidas.
La información se documenta como
lecciones aprendidas y se pueden aplicar a
futuros sprints.
Puede haber mejoras accionables
acordadas (Agreed Actionable
Improvements) o recomendaciones
actualizadas del Scrum Guidance Body.
Los objetivos primordiales de la reunión son
identificar tres elementos específicos:
• Las cosas que el equipo necesita seguir
haciendo: mejores prácticas
• Las cosas que el equipo necesita empezar a
hacer: mejoras en el proceso
• Las cosas que el equipo necesita dejar de
hacer: problemas de proceso y
embotellamiento
Figura 11-9: Fase de revisión y retrospectiva—Diagrama de flujo de datos. SBOK, página

260
Figura 11-6: Retrospectiva del sprint—Diagrama de flujo de datos

Fase de Revisión y retrospectiva Diagrama de
flujo de datos
Figura 11-6: Fase de revisión y retrospectiva—Diagrama de flujo de datos.

SBOK, página 266
Lanzamiento
Fase de Scrum - Lanzamiento
Figura 12-2: Resumen del lanzamiento (Esenciales). SBOK, página 264

• Los entregables aceptados se entregan o

se transmiten.
• La conclusión satisfactoria del sprint se
documenta en un acuerdo formal de
entregables funcionales (Working
Deliverables Agreement)
Figura 12-3: Enviar entregables—Entradas, herramientas y salidas

Figura 12-4: Envío de entregables—Diagrama de flujo de datos

Los stakeholders organizacionales y los

miembros del Equipo Principal de Scrum se
reúnen para hacer una retrospectiva del
proyecto.
Identificar, documentar e internalizar las
lecciones aprendidas.
Las lecciones llevan a la documentaciones de
mejoras accionables acordadas para ser
implementadas en futuros proyectos.
Figura 12-5: Retrospectiva del proyecto—Entrada, herramientas y salidas

Figura 12-6: Retrospectiva del proyecto—Diagrama de flujo de datos

Fase de Lanzamiento – Diagrama de flujo de datos
Figura 12-7: Fase de lanzamiento—Diagrama de flujo de datos.

SBOK, página 275
Procesos de Scrum
Procesos de Scrum - Resumen
Tabla 1-1: Resumen de los procesos fundamentales de Scrum.

SBOK, página 16
Escalamiento de
SCRUM
Escalamiento de Scrum en grandes proyectos
Figura 13-2: Descripción general de Escalamiento de Scrum en grandes proyectos (esenciales). SBOK, p. 279
El Escalamiento de Scrum se analiza a detalle en la Guía SBOK como parte de otros cursos de certificación
avanzada.
Crear componentes de grandes proyectos
Figura 13-3: Crear componentes de grandes proyectos—Entradas, herramientas y salidas

Crear componentes de grandes proyectos
Figura 13-4: Crear componentes de grandes proyectos—Diagrama de flujo de datos

Realizar y coordinar sprints
Figura 13-5: Realizar y coordinar sprints—Entradas, herramientas y salidas

Realizar y coordinar sprints
Figura 13-6: Realizar y coordinar sprints—Diagrama de flujo de datos

Preparar el lanzamiento de grandes proyectos
Figura 13-7: Preparar el lanzamiento de grandes proyectos—Entradas, herramientas y

salidas
Preparar el lanzamiento de grandes proyectos
Figura 13-8: Preparar el lanzamiento de grandes proyectos—Diagrama de flujo de datos

Escalamiento de Scrum para la empresa
Figura 14-2: Descripción del Escalamiento de Scrum para la empresa. SBOK, p. 307
El Escalamiento de Scrum se analiza a detalle en la Guía SBOK como parte de otros cursos de
certificación avanzada.
Figura 14-2: Descripción del Escalamiento de Scrum para la empresa. SBOK, p. 307
El Escalamiento de Scrum se analiza a detalle en la Guía SBOK como parte de otros cursos de
certificación avanzada.
Crear componentes de programa o portafolio
Figura 14-3: Crear componentes de programa o portafolio—Entradas, herramientas y salidas

Crear componentes de programa o portafolio
Figura 14-4: Crear componentes de programa o portafolio—Diagrama de flujo de datos

Revisar y actualizar el Scrum Guidance Body
Figura 14-5: Revisar y actualizar el Scrum Guidance Body—Entradas, herramientas y salidas

Revisar y actualizar el Scrum Guidance Body
Figura 14-6: Revisar y actualizar el Scrum Guidance Body—Diagrama de flujo de datos

Coordinar componentes del programa o portafolio
Figura 14-2: Coordinar componentes del programa o portafolio—Diagrama de flujo de datos

Figura 14-11: Reunión de Scrum de Scrums (SoS)

Retrospectiva de los lanzamientos del programa o portafolio
Figura 14-12: Retrospectiva de los lanzamientos del programa o portafolio—Entradas, herramientas y salidas
Retrospectiva de los lanzamientos del programa o portafolio
Figura 14-13: Retrospectiva de los lanzamientos del programa o portafolio—Diagrama de flujo de datos

Hoy Presentaciones Scrum Master

Cargado por

Copyright:

Formatos disponibles

Hoy Presentaciones Scrum Master

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Hoy Presentaciones Scrum Master

Cargado por

Copyright:

Formatos disponibles

K

Prof. M.Sc. (c) Manuel Sigüeñas, SCRUMstudy™ Certified Trainer

Se basa en el Cuerpo de conocimiento de

Acerca de Amplia aceptación en la industria

La reducción de prueba (testing) y costos de experimentación (simulación y automatización).

El valor del cliente se entrega en el punto de venta, no en el punto de planificación.

La necesidad de un método adaptable de desarrollo en vez de los métodos tradicionales y predecibles.

• Individuos e interacciones sobre procesos y herramientas.

“Aunque valoramos los elementos de la derecha, valoramos más los de la

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

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

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto – organizada.

Costo Tiempo Calidad Limitantes

• Un proyecto de Scrum implica un esfuerzo colaborativo para crear un

• Scrum es uno de los métodos ágiles más populares. Es

Figura 1-1 Flujo de Scrum para un sprint

PERSPECTIVA HACIA EL CAMBIO ADAPTABILIDAD SOSTENIBILIDAD

MEDIDA DEL DESEMPLEO VALOR DEL NEGOCIO CONFORMIDAD CON EL PLAN

•El control de proceso empírico y la entrega

•Todos los emisores de información, tales como

•Los procesos de Realizar el Daily Standup y

•Los entregables mejoran progresivamente

•El proceso iterativo permite la entrega

•Los procesos de Scrum están diseñados para

•El proceso de Crear el backlog priorizado del

•La asignación de un tiempo específico (Time-

•Los procesos de Realizar Daily Standup y

•La colaboración y la co-ubicación de equipos

•El proceso de Crear el Backlog Priorizado del

•El énfasis en el valor del negocio y contar con un

•Los procesos de Realizar Daily Standup y

•El proceso de Comprometer historias de

•Un framework colaborativo permite que los

•Los procesos de Retrospectiva del sprint y

Figura 1-3: Principios de Scrum. SBOK, página 9

Los principios de Scrum son la base en la que

¿Cuáles son las tres

La transparencia permite que todas las facetas de cualquier proceso de

Figura 2-1: Transparencia en Scrum. SBOK, página 25

La inspección en Scrum se representa mediante lo siguiente:

Figura 2-2: Inspección de Scrum. SBOK, página 26

La adaptación se da cuando el equipo principal de Scrum y los

Figura 2-3: Adaptación en Scrum. SBOK, página 27

Figura 2-3: Retos de la gestión de proyectos, página 28

En Scrum se cree que los empleados se auto-motivan y buscan aceptar

El estilo preferido de liderazgo en Scrum es el

Figura 2-5: Objetivos de un equipo de auto-organizado. SBOK, página 30

• La colaboración en Scrum se refiere a que el Equipo Principal de

Dimensiones centrales del trabajo colaborativo

Figura 2 6: Beneficios de la colaboración en proyectos Scrum. SBOK, página 32

Importancia de la co-ubicación en la colaboración

• Importantes beneficios de la co-ubicación.

• Las preguntas se contestan rápidamente.

Interacciones cara a cara.

Sala de decisiones o War Rooms

El framework de Scrum se guía por la finalidad de ofrecer el máximo

Scrum utiliza la priorización basada en valor (Value-based

La priorización la lleva a cabo el Product Owner cuando

Al priorizar las historias de usuario en el Backlog Priorizado del