Scrum Foundations v1 PDF

Scrum Foundations
Conociendo los principios y prácticas del marco de trabajo más

utilizado para desarrollar productos complejos de alta calidad
© Scaled Agile, Inc.

© Scaled Agile, Inc. 1
Scrum Foundations ®
Scrum Foundations cubre en 15 horas los siguientes temas:
1. Pensamiento Ágil
2. Prácticas de Scrum
3. Planificación y Estimación en Scrum
4. Supervisando Proyectos Scrum
5. Conceptos avanzados de Scrum

Agenda
Sesión 01 (5 horas) Sesión 02 (5 horas) Sesión 03 (5 horas)
Pensamiento Ágil Prácticas de Scrum Supervisando Proyectos

Scrum
1. Importancia de las 1. Roles de Scrum
metodologías ágiles 1. Monitoreo en Scrum
2. Eventos de Scrum
2. Conceptos de Agile y Scrum Conceptos avanzados
3. Artefactos de Scrum
3. Valores y principios
fundamentales 1. Scrum en grandes
Planificación y organizaciones
4. Características de Agile que Estimación
más aportan valor 2. Scrum con equipos distribuidos
1. Planificación en Scrum
5. En qué contextos Scrum se 3. Tipos de contratos en Scrum
aplica mejor 2. Técnicas de Estimación en
Scrum 4. Áreas de trabajo Agile

Lineamientos generales
Horario de clases
Breaks
Teléfonos móviles

Visita las paredes
Visita los posters alrededor de la clase y responde las preguntas que

aparecen en ellos.
© 2016 Scaled Agile, Inc. All Rights Reserved.

Presentémonos
Crea una tarjeta de presentación para una persona que no conozcas

- Nombre
- Rol en el trabajo
- Superpoder
- Deporte favorito
- Con qué animal te identificas
- Qué sustancia llevarías a la luna

Richard Acosta
Agile Coach
Ingeniero de sistemas de profesión.
15 años de experiencia

Experiencia
 Desarrollador en Banco de la Nación
Experiencia en banca, logística,
 Project Manager para Migraciones telecomunicaciones y gobierno
 Service Manager para el MRE
electrónico.
 Scrum Master, Agile Coach en
empresas trasnacionales
Actualmente en Avantica escalando
Certificaciones
ágil en grandes organizaciones.
 SAFe Advanced Scrum Master
 SAFe Program Consultant
 Scrum.org Professional Scrum Master
 Certified Scrum Developer
 PMP
7
 © Scaled Agile, Inc.
ITIL Foundations, OSA, PPO, RCV
Lección 1
Pensamiento Ágil

© Scaled Agile, Inc. 4.8
8
Objetivos de aprendizaje
1.1 Comprender la necesidad de Agile
1.2 Conocer los conceptos, valores y principios fundamentales
1.3 Entender en qué contexto se aplica mejor Scrum

1.1 Comprender la necesidad de Agile
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 10
Ejercicio – ¿cuáles son nuestros problemas actuales?
En pares, revisa la siguiente diapositiva

Identifica los problemas que reconoces en tu empresa y quisieras
resolver
Agrega otros que hayas identificado y no aparezcan en la lista
Analiza cuál es el origen de estos problemas y alternativas de solución

¿Cuáles son nuestros problemas actuales?
Entregas Muy poca Problemas

con visibilidad descubiertos
retraso del avance muy tarde
Dependencias Compromiso
Crecimiento con un diseño
fueron masivo de la
subestimadas inadecuado
complejidad
No hay forma de
Baja moral [Ingresa aquí
mejorar
sistemáticamente el tuyo]

La gestión según Taylor (Ingeniería Industrial, 1900’s)

La gestión del desarrollo de software según Royce (1970)
The Rise And Fall Of Waterfall

https://www.youtube.com/watch?v=X1c2--sP3o0

Un cambio de paradigma
Paradigma
Es empleado para indicar un patrón, modelo, ejemplo o arquetipo.

GESTIÓN TRADICIONAL DE GESTIÓN DE PROYECTOS

PROYECTOS AGILE
Foco en la satisfacción del cliente y la
Foco en planes y artefactos
interacción
Acción correctiva al cambio Acción adaptativa al cambio
Planificación realizada al inicio Planificación incremental
Entrega basada en alcance Entrega basada en tiempo
Top-Down control para equipos Equipos auto-organizados
Métodos muy pesados Métodos y prácticas sencillas
Métodos no orientados al valor al cliente Métricas enfocadas en el valor al cliente


¿Por qué las empresas adoptan Agile?
https://www.projectsmart.co.uk/white-papers/chaos-report.pdf

¿Por qué las empresas adoptan Agile?
https://explore.versionone.com/state-of-agile

Retorno de la inversión: Waterfall vs. Agile

1.2 Conocer los conceptos, valores y principios
fundamentales
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 21
Agile
Es una cultura
Definida por 4 valores
Guiada por 12 principios
Aplicada a través de un sinnúmero de prácticas
© 2017 Scaled
Scaled Agile,Agile,
Inc. Inc. All Rights Reserved. 22
Agile Scrum
Es una cultura Es un framework
© 2017 Scaled
Scaled Agile,Agile,
© 2017 Scaled
Scaled Agile,Agile,
© 2017 Scaled
Scaled Agile,Agile,
Agile Scrum
Es una cultura basada en la Es un framework para la
entrega continua de valor, a gestión del desarrollo de
través de incrementos de productos complejos
producto, que permiten
generar feedback y aumentar
el retorno de la inversión
© 2017 Scaled
Scaled Agile,Agile,
https://explore.versionone.com/state-of-agile

El Manifiesto Agile
Estamos descubriendo formas mejores de desarrollar

software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:
• Individuos e interacciones sobre procesos y herramientas

• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan
Agile Manifesto for Sofware Development

https://www.youtube.com/watch?v=rf8Gi2RLKWQ&list=FL_Oewk4FPLn6pF0Z4rs7o5g

Esto es, aunque valoramos
los elementos de la
derecha,
valoramos más los de la
izquierda.

Completa el Manifiesto Ágil
En pares, completa el Manifiesto para el Desarrollo Ágil de Software
sobre
sobre
sobre
sobre

Agile Manifesto – Principios
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-organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más

efectivo para a continuación ajustar y perfeccionar su comportamiento
en consecuencia.
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, con 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, y 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.

Ejercicio – Crea un poster Agile
En equipos de 5, selecciona 4 principios y crea un poster que

contenga:
- Una imagen que describa el principio,
- Una oración con tus propias palabras del principio

1. El software funcionando es la medida principal de progreso.
2. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y
usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
3. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
4. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
5. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
6. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación
ajustar y perfeccionar su comportamiento en consecuencia.
7. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de
software con valor.
8. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos
Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
9. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
10. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana
durante todo el proyecto.
11. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y
el apoyo que necesitan, y confiarles la ejecución del trabajo.
12. 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.
Los orígenes de Scrum
Toyota Production Primera aparición Es anterior al

System del término Scrum manifiesto ágil
Scrum es fuertemente Predominante en los El manifiesto fue

influenciado por el TPS procesos de empresas escrito en el 2001,
de Taiichi Ohno punteras japonesas pero Scrum aparece
(Honda, Toyota) en los 1990s
Empirismo
El conocimiento viene principalmente de la experiencia.
- Wikipedia (Empiricism)
© 2017 Scaled
Scaled Agile,Agile,
Scrum asume un control empírico
Decisiones impulsadas Indicadores con

por el empirismo referencia al pasado
En base a la experiencia que se Los indicadores se basan en
vaya ganando en cada paso, se métricas históricas, y no se
obtendrá el conocimiento asume que se puede
suficiente para dar el siguiente. determinar qué ocurrirá en el
futuro
Las 3 bases del empirismo
Inspección Adaptación Transparencia

Inspección
Inspecciona tanto el proceso como el proyecto
Busca variaciones
Alcanza el equilibrio correcto

Adaptación
Reduce lo que no funciona, incrementa lo que sí
Introduce cambios en el momento correcto
Adapta el proceso para que sirva al proyecto

Transparencia
Visualiza tu ritmo y tu progreso
Fomenta la apertura entre los miembros del

equipo
Comparte un status claro a los demás equipos

Scrum no va a resolver
tus problemas
Scrum te va a habilitar
para que tú puedas
resolverlos
Scrum es un Framework, no un Proceso
Proceso Framework
Guía paso a paso Definición de aspectos clave
Repetible de proyecto a proyecto No es prescriptivo
Framework Tu Tu
Scrum Entorno Proceso
¿Y la ingeniería de software?
Scrum no prescribe ninguna

práctica de ingeniería
su foco es enteramente los

principios de gestión de
proyectos

¿Y la ingeniería de software?
Scrum no prescribe ninguna

práctica de ingeniería
su foco es enteramente los

Su
principios de gestión de
proyectos
la mayoría de los equipos de

alto rendimiento adoptan XP
junto con Scrum
Scrum propone una entrega incremental e iterativa
Pequeños incrementos de un proyecto Se obtiene retroalimentación clara

se entregan uno a uno hasta que todo después de cada incremento y se
el proyecto esté completo incorpora en el siguiente incremento

Una entrega incremental e iterativa:

Sprint
Incremento de Revisado al
Bloque de tiempo producto finalizar el
(iteración) potencialmente timebox
entregable
definido entre 1 y 4 el equipo se incorpora
semanas preselecciona el feedback al
lote de trabajo e siguiente sprint
intenta completarlo

Incrementos por funcionalidades vs. incrementos por sprints
Incrementos por Funcionalidades Incrementos por Sprints

Las funcionalidades no tienen un El feedback ocurre de forma más regular
tamaño consistente
Se incita a los interesados a dar feedback
El feedback viene desigualmente más frecuentemente
Puede no recibirse feedback de todas Más fácil de coordinar

las funcionalidades

Tamaño del Sprint
Sprints cortos Sprints largos

Planeamiento más sencillo pero más Planeamiento menos frecuente pero
frecuente más difícil
Mayor posibilidad de reducir riesgos Mayor probabilidad de riesgos

Tamaño del Sprint
Los sprints mejoran la predictibilidad, ya

que ofrecen mecanismos de inspección y
adaptación del proceso.

1.3 Entender en qué contexto se aplica mejor
Scrum
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 53
Coraje
Sinceridad
Enfoque
Compromiso Respeto
Ejercicio: Acelerando la entrega de valor
 Tu proyecto tiene 3 funcionalidades. Cada una ha sido

estimada en 1 mes por el equipo y entrega 1 unidad de
valor.
 Grafica la entrega de valor para los escenarios de

implementación en serie y en simultáneo/paralelo
- Asume un costo de 20% por cambio de tarea en el 2do

escenario.
- Pista: Grafica primero el caso en serie

Escenarios ideales para Scrum
Muy Adecuado No recomendado
Gran cantidad de complejidad Prioridades cambian a diario
Plazos y fechas de entrega Composición del equipo cambia a

agresivos menudo
Alto nivel de riesgo No se fomenta la transparencia

Para más información:
© 2017 Scaled
Scaled Agile,Agile,
© 2017 Scaled
Scaled Agile,Agile,
¿Preguntas?

Scrum Foundations

Lección 2
Prácticas de Scrum

62
2.1 Comprender los roles en Scrum y sus responsabilidades
2.2 Entender las características de los eventos en Scrum
2.3 Reconocer los artefactos de Scrum y la Definición de Terminado

2.1 Comprender los roles en Scrum y sus
responsabilidades
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 64
El Rol del Product Owner

El Rol del Scrum Master

El Rol del Equipo Scrum

El Rol del Manager en Scrum

Ejercicio: Agrega tus propias notas

Otros roles en Scrum
Roles especialistas como por ejemplo:
- Gestores de bases de datos, personal de sistemas –

devops, arquitectos de software.
Pueden no estar asociados a alguien del equipo.
Participación en sprints concretos como parte del equipo.
Conocimiento compartido para que el equipo gane estás

aptitudes y se tenga menos dependencia de estos perfiles.
Reduciendo el costo transaccional

https://www.youtube.com/watch?v=UlIGI3laGAo
Ejercicio: Selecciona el rol adecuado entre SM, PO, DEV
1. Estima el tamaño de los elementos en el Product Backlog

2. Participa en el Sprint Planning
3. Actualiza el Release Burnup Chart
4. Asegura que el equipo siga las prácticas de Scrum
5. Actualiza el Sprint Backlog cuando las tareas están hechas (terminadas)
6. Asegura remover los impedimentos
7. Gestiona el presupuesto y el ROI del producto
8. Asigna tareas a los miembros del equipo
9. Acepta la entrega del Sprint
10. Deben atender el Daily Scrum
11. Comunica el status del Release a los Stakeholders
12. Actualiza el Sprint Burndown Chart
13. Educa la organización en Scrum
14. Decide cuánto puede entregarse en el Sprint
15. Asegura que cada historia cumpla con la Definición de Hecho

Discusión
¿Qué paso con el rol del PM en Agile?

¿Es posible combinar 2 roles en Scrum?
¿Pueder ser el PM o el SM el gerente de línea?
¿Puedes tener Team Leads en Scrum?
¿Donde encajan los arquitectos en Scrum?
¿Qué hacen los gerentes en Scrum?

2.2 Entender las características de los eventos en
Scrum
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 73
Características de los Sprints
Un sprint es un bloque de tiempo (1-4 semanas) donde se genera el

incremento de un producto “HECHO” potencialmente entregable.
Cada nuevo sprint comienza a continuación del siguiente.
Los sprints mejoran la predictibilidad, ya que ofrecen mecanismos de

inspección y adaptación del proceso.

Un sprint contiene:
Planificación de Sprint – Sprint planning.
Scrum diarios – Daily Scrum.
El trabajo de desarrollo para generar el incremento de producto.
Revisión de Sprint – Sprint Review.
Retrospectiva de Sprint.

Un sprint contiene:
Planificación de Sprint – Sprint planning.
Scrum diarios – Daily Scrum.
El trabajo de desarrollo para generar el incremento de producto.
Revisión de Sprint – Sprint Review.
Retrospectiva de Sprint.

En el trascurso del sprint:

– Evitaremos introducir cambios.
– No alteraremos la composición del equipo que está desarrollando
el producto.
– La calidad debe estar acorde a los criterios de aceptación y a la
definición de hecho.
– El alcance puede ser clarificado y renegociado con el PO.

Cancelación de un Sprint
Sólo el Dueño de Producto puede hacerlo.

– Causas:
▪ Objetivo de sprint obsoleto.
▪ Cambio en las condiciones de mercado
▪ Cambio en la dirección de la compañía.
– ¿Se puede generar un incremento potencialmente entregable?
– El resto de elementos del backlog de producto se vuelven a estimar y se
prepara el siguiente Sprint.

Ejercicio: Dibuja un Sprint
En pares, dibuja la radiografía de un Sprint

Daily Scrum
Objetivo
– Sincronización
– Actualización del Objetivo del Sprint
Mismo lugar, misma hora
Timeboxed = 15 minutos máximo.
Scrum Master se encarga de que la reunión ocurra y de que sólo

participen aquellos miembros del equipo.
El equipo de desarrollo lleva a cabo la reunión.

Daily Scrum
Cada miembro del equipo debe responder a 3 preguntas:

– ¿Qué se ha logrado desde la última daily para acercarnos al objetivo?
– ¿Qué se hará antes de la próxima reunión para acercarnos al
objetivo?
– ¿Qué problemas se han encontrado que no nos permiten acercarnos
al objetivo?
A menudo, si surge algún impedimento, los miembros del equipo

relacionados con el mismo se vuelven a reunir a la consecución de la
daily para tratarlo.

Daily Scrum
¿Qué aporta esta reunión?

▪ Mejora la comunicación.
▪ Elimina la necesidad de mantener otras reuniones.
▪ Elimina impedimentos.
▪ Ayudan a que los miembros del equipo tomen decisiones rápidas en
conjunto.
▪ Se comparte conocimiento.

Ejercicio: Sobreviviendo a la Daily Scrum
1. Habla únicamente mirando a los ojos al ScrumMaster (ignorando al resto a menos que te haga
una pregunta)
2. Llega tarde
3. Impedimento oculto: Menciona un impedimento pero no seas obvio acerca del mismo.
4. PO que secuestra la reunión. Comienza diciendo "Yo solo soy un observador" y luego reporta de
actividades que no interesen al equipo.
5. PO excesivamente silencioso. Como PO solo di "Paso" cuando alguien te pregunte algo.
6. Haz una pregunta con el fin de clarificar un tema justo cuando sea turno de otra persona.
7. Divaga hasta que te mencionen que hagas lo contrario
8. Trata de desviar la reunión
9. Trata de resolver el problema de otro
10. Comienza© Scaled
una discusión paralela
Agile, Inc.
84
Sprint Review
Objetivo:
– Inspeccionar el incremento de producto.
– Adaptar el backlog de producto con el feedback de los stakeholders.
– Fomentar la colaboración más allá del equipo de desarrollo.
Timeboxed = 4 horas máximo para Sprints de 1 mes.
Entregable de la reunión:
– Backlog de Producto revisado.
– Posibles incidencias.
– Información sobre las opiniones de los stakeholders.
Sprint Review
Formato de la reunión:
– El PO indica qué se ha hecho y que no.
– El equipo de desarrollo habla sobre impedimentos y sus soluciones y qué
fue bien en el sprint.
– El equipo de desarrollo enseña el incremento de producto.
– El PO habla de la Pila de Producto y de cómo el sprint afecta a las fechas
del proyecto.
– Todos los asistentes colaboran para que la reunión ofrezca información a la
próxima reunión de planificación.
Ejemplo de Sprint Review

https://www.youtube.com/watch?v=Ve
© Scaled Agile, Inc. tyHT-rZx0&t=303s 86
Sprint Retrospective
Objetivo:
– Inspección del proceso llevado por el equipo y del propio equipo.
– Plan de mejoras para incorporar en el siguiente sprint.
Última reunión del Sprint.
Timeboxed = 3 horas para sprints de 1 mes.
Ejemplo de Sprint Retrospective

https://www.youtube.com/watch?v=IU
© Scaled Agile, Inc. tPjJDBs6I 87
Sprint Retrospective
Reunión más importante de Scrum.
El SM adaptará la estructura para el beneficio del equipo.
ESTRUCTURA básica:
– Presentación
– Recopilación de datos.
– Análisis.
– Generación de mejoras.
– Cierre Ejemplo de Sprint Retrospective
https://www.youtube.com/watch?v=IU
© Scaled Agile, Inc. tPjJDBs6I 88
Ejercicio: Eventos de Scrum
En pares, completa la siguiente información:
Nombre del Evento en el Cuándo ocurre (Antes, Duración del timebox

orden que ocurre durante, después) (asume un Sprint de 1 mes)
Sprint

2.3 Reconocer los artefactos de Scrum y la
Definición de Terminado
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 90
Características del backlog
¿Qué es?
– Lista ordenada de PBI (Product Backlog Items) que
representa al producto.
El Dueño de Producto es el último responsable del

backlog de producto.
Es un artefacto VIVO.
Para un producto, sólo habrá un backlog de producto,

por muchos equipos que haya.

Product Backlog Item
¿Qué es?
– Historia de usuario, épica, historia no funcional, caso de
uso, incidencia, requisito, mejora, corrección.
¿Qué información deben contener?

– ID
– Descripción
– Priorización
– Estimación (si se tiene)
Definición de Listo (DoR)
¿Qué es?
– Conjunto de hechos que se tienen que dar para que un PBI del backlog se
pueda incorporar en un sprint.
A tener en cuenta:
– Historia de usuario definida.
– Criterios de aceptación listos.
– Dependencias identificadas.
– Tamaño definido por el equipo.
El equipo de desarrollo sabe como probar y demostrar esa
funcionalidad.
Refinamiento del Backlog
▪ Actividad continuada, pero a veces es necesario un

evento.
▪ Si necesitamos un evento = 10% de la capacidad del
equipo.
▪ Consiste en añadir detalle y ordenación al PB.
▪ Asistentes → PO, SM y Equipo de desarrollo.
▪ Consiste en una revisión de los elementos que van a
entrar en el siguiente sprint.
▪ Entregable: PB revisado con el equipo de desarrollo.

Cómo escribir buenos requerimientos
▪ En Agile, solemos emplear historias de usuario para la

definición de requisitos.
▪ ¿Qué es una historia de usuario?
▪ Funcionalidad que aporta valor al cliente.
▪ Se almacenan en el Product Backlog.
▪ Recomendaciones para escribirlas:
▪ Centradas en el usuario y no en la tecnología.
▪ Charla en el ascensor (menos de 30 seg).
▪ Seleccionar el tamaño adecuado: Máximo 2 días.

Composición de una historia de usuario
▪ Id
▪ Nombre
▪ Descripción
▪ “Como <rol de usuario>
▪ Quiero <función del sistema>
▪ Para <valor de negocio>
▪ Prioridad.
▪ Estimación.
▪ Conversación: Son conversaciones que explican las necesidades del usuario al
desarrollador. Granularidad muy fina.
▪ Pruebas: ¿Cómo vamos a probar nuestro software?
▪ Notas: Personas de contacto, teléfono, email…
Discusión: Historias técnicas
Los requisitos no funcionales no suelen ser de valor para el cliente.

En pares, conversen sobre cómo manejar la prioridad de historias
técnicas frente al PO y a los stakeholders de negocio.
Ejemplos:
- Instalación de un servidor.
- Configuración de repositorio de código.
- Refactorizar capa de acceso a base de datos.

Modelo INVEST
Una buena historia de usuario deberá satisfacer 6 condiciones:
– Independent: No dependencias.
– Negotiable: contenido de la historia se genera a partir de la conversación.
– Valuable: para el usuario final o el cliente.
– Estimable: se debe poder determinar su tamaño.
– Small: Duración no superior a 1 semana con 2-3 personas desarrollándola.
– Testable: NO se desarrolla aquello que no se puede probar

División de Historias
Normalmente el backlog estará

compuesto por épicas o características.
Una épica es simplemente una historia

de usuario demasiado genérica.
Para poder comprobar si la historia de

usuario puede entrar en un sprint y para
su mejor manejo en el sprint deberá ser
dividida.

Patrones de descomposición




Comprensión compartida de “Hecho” (Done)
“Done” significa que está en “Done” significa que he

producción y mis clientes lo terminado su desarrollo y está
pueden usar listo para pruebas

Definición de Hecho de una Historia de Usuario
Una historia de usuario estará completa cuando se satisfacen sus

criterios de aceptación.
Permiten orientar los test que se van a crear.
Formato:
– Dada una página web con comentarios
– Cuando pulso el botón de añadir comentarios
– Entonces aparece un área de texto para introducir mi comentario.

Definición de Hecho del Sprint
Conjunto de condiciones entendidas, acordadas y establecidas para

dar por finalizada una funcionalidad en el contexto del incremento de
producto.
Suelen ser restricciones organizacionales o del mercado, más allá de la

propia funcionalidad.
El contexto de un criterio de aceptación está en la propia historia de

usuario, pero cuando varias historias deben incorporarse en un
incremento aplicamos la Definición de Hecho.

Definición de Hecho del Sprint
Ejemplo: Definición de Hecho para un incremento de producto

– Pasar las validaciones del departamento de QA de la empresa.
– Pasar las pruebas de usuario en el entorno integrado.
– Cobertura de código a través de los test de un 80%.
– Performance de máximo 3 segundos por transacción
– Incluso de tags para Google Analytics

Evolución de la “Definición de Hecho”

Mayor valor de negocio Reducir riesgo Más transparencia
recuperar los costos antes crear un producto que está comunica el verdadero
o disminuir la inversión listo para liberarse en estado del proyecto a los
general cualquier momento interesados

Ejercicio: Construye tu propio Scrum
En equipos de 4, recorta la página del manual y construye tu propio

Scrum

Lección 3
Planificación y Estimación en
Scrum

112
3.1 Comprender los niveles de planificación en Scrum
3.2 Entender las ceremonias y la importancia de la reunión diaria
3.3 Conocer las técnicas de estimación

3.1 Comprender los niveles de planificación en
Scrum
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 114
Planificación ligera y flexible en Agile
▪ En Scrum evitamos la planificación inicial completa para generar

diferentes momentos para podernos adaptar:
▪ Daily stand up: Adaptación diaria.
▪ Planning meeting: Adaptación por sprint.
▪ Release meeting: Adaptación por entrega.
▪ Si el alcance y las condiciones del proyecto no se alteran, podríamos
trabajar con waterfall. Sin embargo, ¿hay algún proyecto de software
que no requiera adaptación?

Responder al cambio sobre seguir un plan
▪ Podemos controlar y detectar riesgos que puedan impactar sobre

nuestro software.
▪ En la retrospectiva, responder al cambio es parte de la cultura. ¿De qué
nos sirve haber solucionado problemas si no podemos adaptarnos para
que no vuelvan a suceder? ¿Qué ocurriría si fuéramos capaces de
detectarlos con tiempo?

Planificación en múltiples niveles

3.2 Entender las ceremonias y la importancia de la
reunión diaria
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 119
Visión del producto
Características:
– Describe cuál es el objetivo general del producto.

– Punto de referencia del equipo Scrum al completo y de los
stakeholders.
– Esencia de lo que vamos a crear.
Ejemplo: La visión de John Deere

http://tinyurl.com/p5uloc5

▪ Una buena visión debe responder a:

▪ ¿Quién va a comprar/usar el producto?
▪ ¿Qué necesidades del cliente resuelve?
▪ ¿Cuáles necesidades y atributos del producto son críticos?
▪ ¿Cómo se compara con su competencia? ¿Ventajas competitivas?
▪ ¿Cuál es el calendario y presupuesto para desarrollar y lanzar el
producto?

▪ Elevator Statement:
▪ Para (cliente objetivo).
▪ Que (tiene una determinada necesidad).
▪ El (nombre producto) es un (categoría del producto).
▪ Que (beneficios, razón principal para comprarlo).
▪ A diferencia de (competencia).
▪ Nuestro producto tiene (razones de diferenciación).

▪ Elevator Statement:
▪ Para niños de hasta 12 años
▪ Que tienen problemas con el trigo
▪ CHOCOSPECIAL es una marca de cereales sin trigo
▪ Que ofrece una nueva forma de desayunar
▪ A diferencia de chocapic, chocos
▪ Nuestro producto tiene el mismo sabor que la competencia con menos
grasas y no genera pesadez de estómago.

Ejercicio: Innovación
En grupos de 3 personas, siguiendo la estructura presentada, generar

un elevator statement sobre un producto de tu invención que pueda
revolucionar el mercado.

Product Roadmap
▪ Es una definición de las entregas del producto para que podamos

adaptarnos a las necesidades del mercado e intentar obtener su
máximo.
▪ También deberemos determinar con alta granularidad la funcionalidad
que se introducirá en cada release a efectos de poder estimar y
priorizar.
▪ Principalmente la realizará el Product Owner sincronizado con otros PO
dentro de la organización.

Release Planning
▪ Una release es un conjunto de incrementos de producto que serán

entregados al cliente final.
▪ Una release está definida por:
▪ Una fecha sincronizada dentro de la organización.
▪ Objetivo sobre el que gira la entrega.
▪ Conjunto de características a entregar.
▪ Dependiendo del contexto, el PO puede estar acompañado por otras
personas que le ayuden a definir el plan.

Ejercicio: Release Planning
En grupos de 3 personas, vamos a planear la apertura de un:

- zoológico
- museo de historia natural
- acuario
- parque de diversiones
¿Cuál es el alcance mínimo para la inaguración?
¿En cuantos releases planea salir al mercado?

Sprint Planning
▪ OBJETIVO:
▪ definir un plan que contenga QUÉ se va a entregar en el nuevo incremento de
producto y CÓMO se va a llevar a cabo.
▪ Timeboxed = 8 horas para sprint de 1 mes (reducido con reunión de Refinamiento
de Backlog)
▪ Objetivo del sprint:
▪ visión del sprint
▪ Indica el por qué se está construyendo está funcionalidad en el sprint
▪ El Product Owner deberá ayudar en su definición.
▪ Consta de 2 partes:
▪ ¿Qué formará el incremento?
▪ ¿Cómo se conseguirá completar el incremento?

Sprint Planning
▪ ¿Qué formará el incremento del sprint?

▪ Entrada de la reunión:
▪ Product Backlog
▪ Último incremento de producto
▪ Velocidad del equipo en sprints anteriores.
▪ Capacidad del equipo para este sprint.
▪ Dueño de Producto presenta las funcionalidades por ordenación.
▪ El equipo colabora con el Dueño de producto para aclarar cualquier duda
sobre la funcionalidad.
▪ El equipo va realizando estimaciones sobre las funcionalidades presentadas.
▪ El equipo Scrum al completo decidirá el Objetivo del sprint.
Sprint Planning

▪ Las funcionalidades se descompondrán en unidades de trabajo de 1 día o
menos.
▪ Después de esta descomposición, quizás haya que renegociar.
▪ Asistentes:
▪ El dueño de producto
▪ El equipo de desarrollo.
▪ Scrum Master.
▪ Personas técnicas especialistas

Sprint Planning

▪ El equipo se auto organiza para asignarse la funcionalidad de la forma en la
que mejor puedan alcanzar el objetivo.
▪ ENTREGABLE:
▪ El equipo de desarrollo explica al Dueño de Producto y al Scrum Master
cómo se han organizado para conseguir de completar el incremento
guiándose por el objetivo del sprint.

Daily Planning
▪ El daily planning se abordará en la reunión de daily.
▪ A tener en cuenta:
▪ Cada miembro del equipo debería apuntar todo aquello que le ocurrió el día anterior, a
fin de ir preparado a la daily.
▪ La planificación ocurre durante la daily y justo después de la daily con la creación de
grupos generados.
▪ En los grupos posteriores, se podrá necesitar la ayuda de personas técnicas o del
Dueño de Producto.
▪ Durante la daily, el equipo deberá actualizar sus herramientas de trabajo:
▪ Inclusión de día anterior en burn down chart.
▪ Movimiento de tareas a lo largo del tablero Scrum.
▪ Reasignación de tareas entre los miembros del equipo auto organizado.

Del Product Backlog al Sprint Backlog

3.3 Conocer las técnicas de estimación
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 134
Cómo realizar estimaciones fiables
▪ Una estimación es una aproximación de un parámetro en base a una
muestra de datos.
▪ ¿Qué variables intervienen en la estimación?
▪ El parámetro a evaluar.
▪ Los datos.
▪ ¡¡Las personas que realizan la estimación!!

▪ ¿Cómo conseguir fiabilidad?
▪ Analizando el parámetro sobre el que tomamos la muestra de datos y
reduciendo su variabilidad.
▪ Tomando siempre la muestra de datos de la misma forma o
mejoradas.
▪ Que tomen las decisiones personas que estén en contacto con la
tarea a desarrollar.

▪ La muestra de datos de estimación de un equipo será sus historias de
usuario, y éstas deberán ser comprendidas y explicadas en el sprint
planning.
▪ Las personas deberán familiarizarse con un método de estimación y
sentirse cómodas con él.
▪ Sólo deberían estimar aquellas personas que van a comprometerse a
realizar la tarea.

Principales Principios de la Estimación
▪ ¿Por qué estimamos?
▪ Reduce riesgos.
▪ Reduce incertidumbre.
▪ Apoya la toma de las mejores soluciones.
▪ Establece confianza a través del diálogo.
▪ Expresa información que genera discusiones para alcanzar una
solución a los problemas.
▪ Genera conocimiento compartido entre los miembros del equipo.

Tipos de Estimación

Tipos de Estimación
▪ Ventajas de la estimación relativa:

▪ Nos permite que todos los miembros del equipo se sientan igualmente
involucrados.
▪ No generamos distinción de conocimiento. El conocimiento se
comparte y se piensa en el esfuerzo o tamaño de las historias.
▪ Se obtiene consenso y compromiso en las estimaciones, ya que la
duración de la tarea puede variar por miembro del equipo.

Unidades de medida de tamaño
▪ Días ideales:
▪ Cuánto tiempo te costaría si:
▪ Trabajarás todo el tiempo
▪ Sin interrupciones
▪ Con todo lo necesario disponible
▪ Son fáciles de explicar fuera del equipo, ya que los puntos historia
usan una referencia interna.
▪ Son sencillos cuando no hay experiencia en estimar.

Ejercicio: Estimación usando horas ideales
▪ ¿Cuánto te costaría prepararte para tu boda?

Unidades de medida de tamaño
▪ Puntos de historia:
▪ Son una medida pura de tamaño.
▪ Es una medida muy rápida de estimación.
▪ Facilita el ajuste en equipos multidisciplinares.

Técnicas de estimación

Planning Poker

Planning Poker

Ejercicio: Estimación usando Planning Poker
▪ ¿Cuántos puntos tienen los siguientes animales?

▪ León
▪ Mono
▪ Ballena
▪ Periquito
▪ Gato
▪ Petauro del azúcar

Silent Estimation

Ejercicio: Estimación usando Silent Estimation
▪ ¿Cuántos puntos tienen los siguientes animales?

▪ León
▪ Mono
▪ Ballena
▪ Periquito
▪ Gato
▪ Petauro del azúcar

Lección 4
Supervisando Proyectos
Scrum

150
4.1 Comprender la importancia de la monitorización en entornos Agile
4.2 Conocer los principales radiadores de información de Scrum
4.3 Comprender cómo monitorear el progreso del Sprint y del Release

4.1 Comprender la importancia de la monitorización
en entornos Agile
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 152
La importancia de la Monitorización

La importancia de la Monitorización

Principios de la Monitorización
▪ Observación.
▪ Comparación.
▪ Definición de métricas:
▪ ¿Qué vamos a medir?
▪ ¿Cómo lo vamos a medir?
▪ ¿Quién lo medirá?
▪ ¿Qué efectos queremos conseguir?
▪ “Nosotros impactamos lo que medimos” - Efecto Hawthorne.

El software funcionando es la medida principal de progreso”.

Metricas empleadas en Scrum
▪ “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega

temprana y continua de software con valor.” – Valor de negocio
obtenido.
▪ Los miembros del equipo querrán satisfacer al cliente para poder
contribuir al éxito de la organización y sentirse realizados.
▪ Las partes involucradas del proceso verán como su producto va
incrementando su valor, en base a poder probar continuamente
cómo se integran las nuevas características en el producto.

4.2 Conocer los principales radiadores de
información de Scrum
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 158
Gráficos más empleados en Scrum
▪ Los gráficos de quemado (Burn Up/Down Charts) que nos servirán

para monitorizar cuánto llevamos, cuánto nos queda y la velocidad
del equipo.
▪ Niko Niko Calendar que nos permitirá monitorizar el estado de las
personas del proyecto.
▪ Tablero Scrum para la organización de tareas.

Creación de radiadores de información
▪ Un radiador de información es un cartel

colocado en el lugar dónde
desarrollamos nuestro trabajo.
▪ Su información es fácil de entender a
primera vista.
▪ Es información útil para el proyecto.
▪ Evoluciona periódicamente conforme
las condiciones cambian.
▪ Es fácil de mantener.

Creación de radiadores de información

4.3 Comprender cómo monitorear el progreso del
Sprint y del Release
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 162
Burn up y burn down charts

Burn up charts

Burn down charts

Ejercicio: Elabora un Release Burnup Chart
▪ Dibuja un Release burnup para la siguiente situación:

▪ Al inicio del proyecto, el total del trabajo estimado del Product Backlog es de 100 puntos
de historia. Al final del Sprint 1, el equipo ha completado 10 puntos, pero el Product
Backlog ha crecido también 10 puntos por nuevas historias adicionadas. Al final del
Sprint 2, el equipo completa 20 puntos y no se añaden nuevas historias. Al final del
Sprint 3, el equipo completa 15 puntos, la cantidad de trabajo pendiente de hacer en el
Product Backlog es de 85, es decir 20 puntos se agregaron durante el Sprint 3.
Utiizando el Release Burnup, responde las siguientes preguntas:

▪ ¿Cuál es la velocidad promedio del equipo?
▪ ¿A qué tasa el Product Backlog está creciendo (en promedio)?
▪ ¿Cuántos puntos de historia va a completar el equipo en 8 sprints?
▪ ¿Cuántos sprints se van requerir para completar todo el trabajo, asumiendo que la
tendencia continua constante?
Lección 5
Conceptos avanzados de
Scrum

169
5.1 Comprender cómo aplicar Scrum en grandes proyectos
5.2 Reconocer cómo aplicar Scrum en equipos distribuidos
5.3 Entender los distintos tipos de contratos en Scrum

5.1 Comprender cómo aplicar Scrum en grandes
proyectos
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 171
Scrum en grandes proyectos

At a Glance
Freely Available
200,000
SAFe-trained
170
Scaled Agile Partners
SAFe’s knowledge base is freely available at
scaledagileframework.com
professionals in 50 countries
in 110+ countries Configurable
Training SAFe is able to accommodate enterprises of all
A comprehensive sizes and industries
70 % US Fortune 100 enterprises have

SAFe-trained professionals
role-based
curriculum Fastest Growing Method
for successfully SAFe cited as preferred solution for scaling Agile:
2 million Pledged 1%
Scaled Agile stock
implementing SAFe
and skills validation
• 2017 Agile in the Enterprise survey by Gartner Research
• 11th Annual State of Agile Report by VersionOne
Annual visitors to SAFe
equity & employee time through professional
and Scaled Agile websites • 2017 Scaling Agile Report by cPrime
to Pledge 1% campaign certification.
SAFe CASE STUDIES
30 - 75% 25 - 75% 20 - 50% 10 - 50%

Faster Increase in Improvements Increased Employee
Time-to-Market Productivity in Quality Engagement
SAFe tiene 4 configuraciones comenzando con la Esencial

Y finalizando con Full SAFe

SAFe en 5 minutos
Epic Owners
Lean Portfolio Management
Enterprise Architect
Product Management
System Architect Engineer
Release Train Engineer
Agile Release Train
Product Owner
Scrum Master
Scrum Team

SAFe en 5 minutos

SAFe en 5 minutos

Roadmap para su Implementación
scaledagileframework.com/
implementation-roadmap

5.2 Reconocer cómo aplicar Scrum en equipos de
mantenimiento y equipos distribuidos
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 181
Scrum en proyectos de mantenimiento

Scrum en equipos distribuidos

1. Equipos distribuidos parcialmente, dónde alguno o todos de los

integrantes trabaja de forma remota.
a) Virtualización de espacio físico: tablero Scrum, herramientas de
integración continua, gráficos, …
b) Se puede generar en un espacio físico una réplica del espacio
virtual, dónde una persona pueda mantenerlo.
2. Equipos donde sus miembros trabajan remotamente y pertenecen a
diferentes organizaciones.
a) Deberemos fomentar que las empresas generen un contexto común
o marco de actuación.
b) Podríamos ver al equipo generado con una empresa única.

3. Equipos con desfase horario(desde turnos diferentes de trabajo hasta

desfases horarios por estar en otros países)
a) Deberíamos conseguir una ventana de tiempo dónde las personas
puedan interactuar para por lo menos realizar la daily y su posterior
reunión de grupo.
b) Deberíamos evitar el hecho de que a pesar de que haya diferencias
horarias, nadie trabajara solo.
4. Equipos con integrantes deslocalizados con grandes diferencias
culturales.
a) Emplear artefactos que faciliten la comunicación, como hangouts o
skype. Siempre con el máximo nivel de interacción: Cámara, audio a
ser posible.



5.3 Entender los distintos tipos de contratos en
Scrum
©©Scaled
ScaledAgile,
Agile,Inc.
Inc. 188
Contratos y proyectos con precio fijo en Scrum



Ejercicio: Plan de Acción Personal
Identifica tres acciones que puedes antes que termine el mes para
iniciar la implementación de Scrum o mejorar una implementación
existente:
1.
2.
3.

¡Muchas Gracias!

Scrum Foundations v1 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Scrum Foundations v1 PDF

Caricato da

Copyright:

Formati disponibili

Scrum Foundations

Conociendo los principios y prácticas del marco de trabajo más

© Scaled Agile, Inc.

Scrum Foundations cubre en 15 horas los siguientes temas:

3. Planificación y Estimación en Scrum

4. Supervisando Proyectos Scrum

5. Conceptos avanzados de Scrum

© Scaled Agile, Inc. 2

Sesión 01 (5 horas) Sesión 02 (5 horas) Sesión 03 (5 horas)

Pensamiento Ágil Prácticas de Scrum Supervisando Proyectos

© Scaled Agile, Inc. 3

© Scaled Agile, Inc. 4

Visita los posters alrededor de la clase y responde las preguntas que

© 2016 Scaled Agile, Inc. All Rights Reserved.

Crea una tarjeta de presentación para una persona que no conozcas

© 2016 Scaled Agile, Inc. All Rights Reserved.

15 años de experiencia

3. Planificación y Estimación en Scrum

4. Supervisando Proyectos Scrum

5. Conceptos avanzados de Scrum

1.1 Comprender la necesidad de Agile

1.2 Conocer los conceptos, valores y principios fundamentales

1.3 Entender en qué contexto se aplica mejor Scrum

© Scaled Agile, Inc. 9

En pares, revisa la siguiente diapositiva

© 2016 Scaled Agile, Inc. All Rights Reserved.

Entregas Muy poca Problemas

© Scaled Agile, Inc. 12

© Scaled Agile, Inc. 13

The Rise And Fall Of Waterfall

© Scaled Agile, Inc. 14

© Scaled Agile, Inc. 15

GESTIÓN TRADICIONAL DE GESTIÓN DE PROYECTOS

Acción correctiva al cambio Acción adaptativa al cambio

Planificación realizada al inicio Planificación incremental

Entrega basada en alcance Entrega basada en tiempo

Top-Down control para equipos Equipos auto-organizados

Métodos muy pesados Métodos y prácticas sencillas

Métodos no orientados al valor al cliente Métricas enfocadas en el valor al cliente

© Scaled Agile, Inc. 16

© Scaled Agile, Inc. 17

© Scaled Agile, Inc. 18

© Scaled Agile, Inc. 19

© Scaled Agile, Inc. 20

Guiada por 12 principios

Aplicada a través de un sinnúmero de prácticas

© Scaled Agile, Inc. 27

Estamos descubriendo formas mejores de desarrollar

• Individuos e interacciones sobre procesos y herramientas

Agile Manifesto for Sofware Development

© Scaled Agile, Inc. 28

© Scaled Agile, Inc. 29

En pares, completa el Manifiesto para el Desarrollo Ágil de Software

© 2016 Scaled Agile, Inc. All Rights Reserved.

El software funcionando es la medida principal de progreso.

Los procesos Ágiles promueven el desarrollo sostenible. Los

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

La simplicidad, o el arte de maximizar la cantidad de trabajo no

© Scaled Agile, Inc. 31

A intervalos regulares el equipo reflexiona sobre cómo ser más

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega

Aceptamos que los requisitos cambien, incluso en etapas tardías del

Entregamos software funcional frecuentemente, entre dos semanas