Scrum, tal como se define en la Guía SBOK™, aplica a los siguientes:

• Portafolios, programas y/o proyectos en cualquier industria

• Productos, servicios o cualquier otro resultado que se les entregarán a los interesados
• Proyectos de cualquier tamaño y complejidad

Un proyecto Scrum consiste en un esfuerzo de colaboración para crear un nuevo producto.

Scrum garantiza transparencia en la comunicación y crea un ambiente de responsabilidad colectiva y de
progreso continuo

SEIS PRINCIPIOS:
 Control del proceso empírico: basado en la experiencia, se emplea cuando no hay algo definido.
Basado en Transparencia (artefactos, reuniones, radiadores de información), Inspección y
Adaptación.
 Auto-organización: compromiso y responsabilidad.
 Colaboración: conocimiento, articulación y apropiación. “Creación de valor compartido”.
Equipo Colocado (co-ubicado) / Equipo distribuido geográficamente
 Priorización basada en valor: máximo valor de negocio, desde el principio del proyecto hasta su fin.
Considerar: Valor, Riesgo o incertidumbre y Dependencias
 Time-boxing: restricción limitante, “ritmo sostenible”. Evita la mejora excesiva.
Ventajas: desarrollo eficiente, menos gastos generales, alta velocidad, evita mejora excesiva.
Reunión de Planificación del sprint:
1. Def. objetivo: definen la meta del sprint (equipo se compromete con las h.u)
2. Identificac. Y estimación: las h.u. y las tareas estimadas se incluyen en el Backlog P.
 Desarrollo iterativo: énfasis en cómo gestionar mejor los cambios.

Cinco aspectos: Organización, justificación del negocio, calidad, cambio, riesgo

Cinco fases: Inicio, planificación y estimación, implementación, revisión y retrospectiva, lanzamiento

Backlog Priorizado del Producto:

Lo desarrollo el Product Owner. Lista requerimientos del negocio y del proyecto por orden de importancia

HISTORIA SCRUM:
 A mediados de la década de los 80s, Hirotaka Takeuchi y Ikujiro Nonaka -> unidad para alcanzar un
objetivo común. Enfoque holístico o “rugby”, “mover al Scrum campo abajo”.
 1995 en Austin, Texas. Ken Schwaber y Jeff Sutherland desarrollaron el concepto de Scrum y su
aplicabilidad al desarrollo de software

ESCALABILIDAD:
Para ser eficaces, los equipos Scrum idealmente deben tener de seis a diez miembros

Los principios, aspectos y procesos interactúan entre sí y son de igual importancia

Scrum es un framework y no pretende ser prescriptivo, lo cual significa que hay espacio para la flexibilidad
en su aplicación.

ASPECTOS

1. ORGANIZACIÓN (Roles y responsabilidades)

Roles centrales:
  Product Owner: requisitos del cliente y de mantener la justificación del negocio para el proyecto.
Product Owner es responsable de asegurar que el Equipo Scrum entregue valor.
Asegurar los recursos financieros del proyecto al inicio y durante su transcurso
 Scrum Master: guía, facilita y enseña las prácticas de Scrum
 Equipo Scrum: entender los requisitos especificados por el Product Owner
Disponib., compromiso.
Roles no centrales:
 Stakeholder: clientes, usuarios y patrocinadores,
 Scrum Guidance Body (SGB): “Cuerpo de asesoramiento” documentos y/o un grupo de expertos,
calidad, las regulaciones gubernamentales, la seguridad y otros parámetros claves de la
organización. El SGB guía a P.O, S.M y E.S. No toma decisiones relacionadas al proyecto
 Vendedores

Larry Spears identifica diez rasgos que cada líder servicial eficaz debe poseer: (S.M y P.O.)
Escuchar, empatía, recuperación (curación), toma de conciencia, persuasión, conceptualización,
prospectiva (previsión), administración, compromiso con el crecimiento de los demás, desarrollo de la
comunidad.

2. JUSTIFICACIÓN DEL NEGOCIO: Product O. es el responsable principal de la justificación del negocio

Factores p determinar la justificación del negocio: Razonam., necesidades, beneficios, costo de oportunidad,
riesgos mayores, escalas de tiempo (duración), costos de proyecto.
 Técnicas de Justificación de negocio:
Estimación del valor del proyecto:
 Retorno sobre la inversión (RSI): ingresos netos esperados
 Valor presente neto (VPN) : valor neto actual de un futuro beneficio económico
 Tasa interna de retorno (TIR): tasa de descuento sobre una inversión

Planificar para el valor: Mapa de flujo de valor, Priorización basada en el valor para el cliente
Clasificación relativa de priorización: Es un método eficaz para determinar las historias deseadas para cada
iteración o lanzamiento del producto o servicio
Mapeo de Historias: técnica para proporcionar un esquema visual del producto y sus componentes clave. Ruta
del producto y lanzamientos.

Justificación continua de valor: evaluar si aún existe la justificación o viabilidad en la ejecución del proyecto

 Análisis del valor ganado (AVG): analiza el verdadero rendimiento del proyecto en comparación al rendimiento
planeado en un punto previsto. El AVG generalmente se lleva a cabo al final de cada sprint.
 Diagrama de flujo acumulativo (DFA): Se utiliza generalmente para brindar un estado de mayor nivel de la
totalidad del proyecto. Sirve para Identificación de obstáculos y embotellamiento en los procesos

Confirmar la realización de beneficios: Prototipos, simulaciones y demostraciones, son técnicas comúnmente

utilizadas para confirmar el valor. (IKIWISI). Los beneficios de los proyectos Scrum se materializan durante los
procesos de Demostrar y validar el sprint, Retrospectiva del sprint, Enviar entregables y Retrospectiva del
proyecto.

3. CALIDAD:
Capacidad de los entregables para cumplir con los criterios de aceptación. El desarrollo, pruebas y
documentación se completan como parte del mismo sprint

Alcance:
Ritmo sostenible: el esfuerzo realizado en el actual sprint sea similar al esfuerzo realizado en el sprint anterior.

Criterio de Terminado

4. CAMBIO
Lograr la Flexibilidad: transparencia, inspección y adaptación.
a. Desarrollo iterativo: Los stakeholders presentar solicitudes de cambio en cualquier momento
b. Time-box: permite la identificación si se necesita cambiar algún proceso o método
Time-boxes proporciona la estructura necesaria para los proyectos Scrum
Time-box contribuye al logro de altos niveles de productividad
Mediante el Time-boxing la proyección de tiempo y esfuerzo es más precisa
c. Equipos interfuncionales y auto-organizados: enfocarse en los objetivos del sprint.
La auto-organización garantiza que el equipo Scrum decida por sí mismo la forma de hacer el trabajo
 Adaparse a cambios y administrar trabajos en caso de problemas.
d. Priorización basada en valor del cliente: un cambio a uno ya existente, esto se evalúa
durante el proceso de Refinar el Backlog Priorizado del Producto
e. Integración continua: asegura que se esté trabajando solamente en la última función de la versión

Excepción para modificar el alcance de un sprint:

Si el Equipo Scrum determina que se ha sobrestimado en gran medida el esfuerzo durante el sprint

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); y, b) que es muy difícil, si no es que imposible, que los stakeholders definan todos
los requisitos al inicio del proyecto.

Impacto del cambio en la duración del sprint:

A + req. Estables mayor duración de Sprint.
El cambio esperado no es el único factor que se utiliza para determinar la duración del sprint. Otros factores:
• El tiempo real para realizar su trabajo (entorno corporativo necesita un tiempo específico para realizar tareas)
• La fecha prevista para su lanzamiento
• Cualquier otro factor que determine el Product Owner o el Scrum Master como: La complejidad de las
Historias

El cambio en la duración del sprint no debe decidirse a la ligera o de manera periódica (un sprint de tres
semanas, luego uno de dos semanas y el siguiente de cuatro semanas, etc.)
La duración del sprint debe ser consistente, para que el equipo pueda elegir adecuadamente el número de
historias a realizar en el próx. Sprint.

Gestión de Cambios en el refinam. del Backlog P. Producto. (Grooming):

El P.O dedique una cantidad considerable de tiempo en cada sprint para refinar el backlog.
Asegura que la refinación de los requisitos y sus historias de usuario se hagan antes de planificación del sprint.
La reunión de revisión del Backlog P.P. es una reunión formal durante el proceso de refinamiento de dicho
backlog
Cualquier elemento del Backlog P. P. está siempre abierto para la re-estimación hasta que el Sprint Backlog sea
finalizado en el proceso de Crear el Sprint Backlog.

Reunión eficaz de revisión de B.P.P (refinamiento)

Limitar el número de stakeholders que participan. Todos los miembros del Equipo Scrum.
Una eficaz sesión de grooming debe resultar en los elementos claramente definidos en el Backlog P.P.
No tienen a un time-box.
El refinamiento del Backlog Priorizado del Producto es una actividad continua del Product Owner.

Gestión de Cambios durante Sprint Review:

Product Owner acepta o rechaza las historias de usuario (correspondientes a las solicitudes de cambio
aprobadas)
Scrum Master garantizar que los requisitos y criterios de aceptación no se modifiquen durante la reunión de
revisión del sprint

Cambio en portafolios *
No se recomienda hacer cambios entre (intervalo) dos reuniones Portfolio Backlog
Las reuniones del Backlog P. P. del Portfolio (reuniones del Portafolio Backlog), deben llevarse a cabo en
intervalos de 4 a 12 meses.

Cambios en programas*
 1. Si el cambio es menor, el Program P. O. debe contar con la aprobación de los stakeholders
correspondientes.
2. Si el cambio es importante, las actividades del programa, proyectos y sprints relacionados deben detenerse
3. Las reuniones del Backlog P. P. del programa (reuniones del Program Backlog), deben llevarse a cabo, de
preferencia, en intervalos de dos a seis meses.

Cada vez que el Product Owner o el Equipo Scrum reconoce un problema o defecto o identifica un elemento del
Backlog Priorizado del Producto que deba modificarse, sustituirse o añadirse, el cambio se realiza en el Backlog
Priorizado del Producto. Del mismo modo, la alta gerencia, el Product Owner o el(los) stakeholder(s) puede(n)
añadir solicitudes de cambio a dicho backlog.
Esto les da a los stakeholders la capacidad para responder a los cambios en el ambiente externo,

5. RIESGO
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.

Minimizar riesgos por medio de Scrum: prácticas que facilitan la gestión efectiva del riesgo.
 La FLEXIBILIDAD al ENTORNO EMPRESARIAL: adición o modificación de los requisitos
 La RETROALIMENTACIÓN constante a las EXPECTATIVAS.
 La PROPIEDAD DEL EQUIPO reduce la ESTIMACIÓN de riesgo: Hace estimaciones y se hace responsable del sprint
backlog.
 La TRANSPARENCIA reduce el riesgo de NO DETECCIÓN
  La ENTREGA ITERATIVA reduce el riesgo de INVERSIÓN

o Lista de verificación de riesgos , Lista corta de riesgos

(Estructura de distribución de riesgos)

EVALUACIÓN DE RIESGOS:
Reunión de riesgos: invitar a los stakeholders relevantes a dicha reunión
Árboles de probabilidad: calcular el impacto general de la ocurrencia de riesgos
Análisis de Pareto: clasificación de riesgos por magnitud, impacto probable en un proyecto
Matriz o red de Prob. e Impacto: impacto potencia en los objetivos del proyecto. Califica con base a su probabilidad
de ocurrencia e impacto en una escala objetiva
Valor monetario esperado: el impacto monetario por la probabilidad de riesgo. Análisis de costo-beneficio

COMUNICACIÓN DE RIESGOS:
El Equipo Scrum pudiera también discutir con el Scrum Master los riesgos específicos relacionados a
sus tareas durante los Daily Standups.
Riesgos en portafolios y programas
1. Si existe un riesgo muy grave y el programa o el portafolio comunican que tendrá un impacto en un proyecto
individual, el Equipo Scrum tenga que detenerse y volver a planificar el actual sprint para atender el riesgo.
FASES
A. INICIO:
1. Crear la Visión del proyecto: se identifica al Product Owner
2. Identificar Scrum Master y Stakeholder(s): El P.O. ayuda a finalizar la elección del S.M
3. Formar equipo: el Product Owner es el responsable principal de la selección de los miembros del
Equipo en colaboración con el Scrum Master.

-> P. Owner, Scrum Master, Visión del proy.

** Selección del equipo Scrum: son las habilidades interpersonales de cada miembro del equipo lo que
determinará el éxito de los equipos auto-organizados.
** Capacitación: El Scrum Master debe atender problemas como son la baja moral o la falta de
coordinación dentro del equipo. El Product Owner proporcionar capacitación a los miembros cuando se
determine que faltan habilidades o conocimiento.
<- Equipo Scrum
<- Substitutos: se recomienda tener substitutos de miembros del equipo.
<- plan de colaboración: en Scrum se evita toda la documentación innecesaria.
 4. Desarrollar épicas: Sirve como base la Declaración de visión del proyecto. Las épicas se basan en los
requerimientos de negocio. Las épicas deben desarrollarse tomando en cuenta los términos y condiciones
del tipo de contrato que se utilice.
 Contratos Aplicables:
Entrega incremental: El cliente puede optar por detener su desarrollo o solicitar modificaciones.
Joint Venture: ambas partes se benefician
Desarrollo en fases: fondos cada mes o trimestre después de un lanzamiento satisfactorio.
Incentivos y sanciones: proveedor será recompensado económ. si los productos se entregan a tiempo,
pero incurrirá en sanciones económicas si la entrega se realiza tarde.
** Reuniones del grupo de usuarios: Stakeholders relevantes. Ayuda a la formulación de los criterios de
aceptación. Disminuye la falta de claridad de expectativas y exigencias.
** Taller de H.U: Las facilita el S.M. Discutir y aclarar todos los elementos de un producto
**Reuniones del grupo de enfoque: ofrecer sus opiniones, percepciones sobre un producto, servicio o
resultado desead, se hacen preguntas. Conducen a un producto de mejor calidad. Cuando los miembros
del grupo tienen diferentes opiniones o puntos de vista, crean ideas innovadoras, resolver problemas y
dar sugerencias para mejorar.
<- Las épicas son historias de usuario grandes sin refinar
<- Prototipos (personas): personajes ficticios altamente detallados que representan a los usuarios
<- Riesgos identificados

5. Crear el Backlog Priorizado del Producto: se refinan y crean las épicas. Se establecen los criterios de
terminado
** Métodos de priorización de las H.U: Comparación por pares: Una H.U se compara con otra y se elige cuál de las
dos es más importante.
** Métodos de estimación de H.U:
<- Backlog P.P (épicas): Backlog Priorizado del Producto del riesgo ajustado, ya que incluye riesgos identificados

6. Realizar la planificación del lanzamiento: El equipo principal Scrum revisa las H.U para desarrollar un
cronograma. Se determina la duración del sprint.
**Sesión de planificación de lanzamiento: Equipo Scrum cuente con una visión general de los lanzamientos
<- duración del sprint: lo deciden el P.O y equipo Scrum.

B. PLANIFICACIÓN Y ESTIMACIÓN:
7. Crear historias de usuario: se crean las H.U y los criterios de aceptación de las H.U. Las H.U
generalmente las escribe el Product
8. Estimar historias de usuario: P.O. aclara las H.U para que el S.M y equipo estimen esfuerzos.
9. Comprometer historias de usuario: El resultado de este proceso serían las H.U comprometidas para
un sprint.
10. Identificar tareas: las historias de usuario comprometidas se desglosan en tareas
11. Estimar tareas: El resultado: lista de tareas con esfuerzo estimado. (Eq. Principal Scrum)
**Reunión de Plan. De Sprint: Los miembros del Equipo Scrum utilizan la lista de tareas para estimar la duración y el
esfuerzo para las historias de usuario que serán completadas en el sprint.
12. Crear Sprint Backlog: Equipo principal Scrum elabora un Sprint Backlog (tareas a ser completadas)

C. IMPLEMENTACIÓN:

13. Crear Entregables:

->Impediment Log*: obstáculo o barrera que reduce la productividad del Equipo Scrum.
El Scrum Master debe registrar formalmente los impedimentos en un Impediment Log y se pueden
analizar durante las Daily Standups
D. REVISIÓN Y RETROSPECTIVA:

Puede incluir la reunión de Scrum de Scrums. Algunos ejemplos de requerimientos no funcionales son:
tiempos de respuesta, limitaciones en la capacidad y problemas en materia de seguridad.

E. LANZAMIENTO

SCRUM PARA GRANDES PROYECTOS

Realizar y coordinar sprints:
** Scrum de Scrums