Este documento proporciona una introducción al marco ágil Scrum. Explica que Scrum es una metodología ágil para la gestión de proyectos que se basa en iteraciones cortas llamadas "sprints". Describe los principales roles en Scrum como el Propietario del Producto, el Scrum Master y el Equipo, y las prácticas clave como la planificación y revisión de sprints. También cubre conceptos como el Product Backlog y los incrementos de producto.

1. Introducción al marco ágil: Scrum.
Dinámicaconlagestióndeproyectos.

2. Indice
Temario
(1)
Introducción. ¿Cómo surge?. Metodologías ágiles.
Lean SDLC. ¿Cuando un método es ágil?. Diferencias
entre metodologías.
(4)
Prácticas para la gestión del proyecto y del producto.
(2)
Introducción a SCRUM.
Principios. Características.
(5)
Conclusiones. Plataforma requerida. Fortalezas de
SCRUM. Reflexiones.
(3)
Practica SCRUM
Propietario del Producto. El Scrum Master. El Equipo.
Interdependencias de los roles. Historias de usuario.
Product Backlog. Sprint. Planificación del Sprint.
Estimación de póquer. Ejecución del Sprint. Fin del
sprint: Sprint review. Sprint retrospective. Daily Scrum
(Comenzar / Parar / Continuar). Incremento
(6)
Caso practico

3. • Requerimientos fuera de control
• No cumplimiento de los tiempos planificados (desvíos)
• Estimaciones deficientes
• Re trabajo excesivo
• Baja calidad
• Costos excedidos
• Insatisfacción del Cliente
• Insatisfacción de los profesionales participantes
¿Cómo surge?

5. Metodologías ágiles
Lean
Principios
Prince2, Pmbok
Gestión de proyectos
Scrum
XP/TDD/FDD
Gestión de SDLC
Ingeniería
Kanban
Gestión de operaciones
Plataforma
IT, CI/CD

6. Lean SDLC
• Visión sistémica, enfoque organizativo.
• Desde la concepción del producto hasta su entrega al
consumidor / usuario final y obtención de valor.
• Foco en minimizar el tiempo que se tarda en proporcionar
valor.
• Gestión de la demanda + JIT
• Capacidad productiva, Kanban
• Organización de la empresa
• Rapidez, flexibilidad, flujo

7. • Principios
– Respetar a las personas, porque el equipo es quien conoce cómo mejorar el proceso en que
trabaja.
– Eliminar los desperdicios que se producen en el proceso, todo aquello que no produce valor
añadido en el producto.
– Aplazar el compromiso, retardar las decisiones hasta que se disponga de toda la información o
no se pueda esperar más.
– Crear conocimiento, tener feedback regular con el cliente para alinearse con sus expectativas.
– Hacer entregas rápidas, para permitir que el cliente pueda
aprovechar antes los beneficios que le aporta el proyecto.
– Desarrollar con calidad interna, de manera que el producto
pueda ir creciendo con una velocidad sostenida.
– Optimizar la totalidad del proceso, mejorar el proceso de
creación del producto, desde la idea hasta su entrega

8. ¿Cuando un método es ágil?
• Simple pero duro. No se basa en el seguimiento de un plan
sino en la adaptación continua a la evolución del proyecto.
El desarrollo de software es:
– Incremental
• liberaciones pequeñas y ciclos rápidos.
– Cooperativo
• clientes y desarrolladores trabajando juntos.
– Simple y Directo
• el método es fácil de aprender y modificar.
– Adaptativo
• es posible realizar cambios de último momento.

9. Diferencias entre metodologías
Metodologías Ágiles
• Basadas en heurísticas
provenientes de prácticas de
producción de código
• Especialmente preparados
para cambios durante el
proyecto
• Impuestas internamente (por
el equipo)
• Proceso mucho más
controlado, con numerosas
políticas/normas
• No existe contrato tradicional
o al menos es bastante flexible
Metodologías tradicionales
• Basadas en normas
provenientes de estándares
• Seguidos por el entorno de
desarrollo
• Cierta resistencia a los
cambios
• Impuestas externamente
• Proceso menos controlado,
con pocos principios
• Existe un contrato prefijado

10. • El cliente interactúa con el
equipo de desarrollo
• Grupos pequeños (<10
integrantes) y trabajando en el
mismo sitio
• Pocos artefactos
• Pocos roles
• Menos énfasis en la
arquitectura del software
• El cliente es parte del equipo
de desarrollo mediante
reuniones
• Grupos grandes y
posiblemente distribuidos
• Más artefactos
• Más roles
• La arquitectura del software
es esencial y se expresa
mediante modelos
Metodologías Ágiles Metodologías tradicionales

11. Simple
Complejo
Anarquía
Tecnología
Requisitos
Lejos de
Acuerdo
Cerca de
Acuerdo
Cerca
de
Certeza
Lejos
de
Certeza
• Entornos en los cuales es mas conveniente el enfoque agil

12. Introducción a SCRUM
• La palabra SCRUM procede del vocabulario del rugby y significa melé; es
decir, que los compañeros del equipo se amontonan, forman una piña y
empujan todos en la misma dirección.
• SCRUM es una estrategia de gestión donde se aplican de manera regular
un conjunto de prácticas para mejorar el trabajo colaborativo y obtener el
mejor resultado posible en la gestión de un proyecto software.

14. • Scrum es un proceso ágil que nos permite centrarnos
en ofrecer el más alto valor de negocio en el menor
tiempo.
• Nos permite rápidamente y en repetidas ocasiones
inspeccionar software real de trabajo (cada dos
semanas o un mes).
• El negocio fija las prioridades. Los equipos se auto-
organizan a fin de determinar la mejor manera de
entregar las funcionalidades de más alta prioridad.
• Cada dos semanas o un mes, cualquiera puede ver el
software real funcionando y decidir si liberarlo o seguir
mejorandolo en otro sprint.
Scrum en 100 palabras

15. • El Manifesto Ágil – una declaración de valores. Aunque los elementos a la derecha tienen
valor, nosotros valoramos por encima de ellos los que están a la izquierda.
Fuente: www.agilemanifesto.org
Individuos e
iteraciones
Sobre Procesos y herramientas
Software funcionando Sobre Documentacion
extensiva
Colaboracion con el
cliente
Sobre Negociación contractual
Respuesta ante el
cambio
Sobre Seguir un plan

16. – Al individuo y las interacciones del equipo de desarrollo sobre el
proceso y las herramientas.
• Es más importante construir un buen equipo.
– Desarrollar software que funciona más que conseguir una buena
documentación.
• No producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante.
– La colaboración con el cliente más que la negociación de un contrato.
• Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración
entre ambos será la que marque la marcha del proyecto y asegure su éxito.
– Responder a los cambios más que seguir estrictamente un plan.
• Se debe ser hábil en responder a los cambios y a los fracasos, la planificación no debe ser estricta sino flexible y
abierta.

17. • Scrum es un proceso iterativo e incremental que puede ser utilizado para
desarrollar cualquier producto o administrar cualquier trabajo. Sus
principales atributos son:
– Un enfoque orientado a que los equipos desarrollen productos de manera
iterativa e incremental cuando los requerimientos cambian de manera rápida
– Un proceso que controla el caos de conflictos de intereses y necesidades
– Una manera de mejorar las comunicaciones y maximizar la cooperación
– Una manera de maximizar la productividad
– Escalable a múltiples proyectos y la organización
– Una forma que todos se sientan bien con su trabajo,
entendiendo que cada uno con sus contribuciones
hizo lo mejor que podía hacer

18. En lugar de hacer todo
de una cosa a la vez ...
...los equipos Scrum
hacen un poco de todo
todo el tiempo
Requisitos Diseño Código Test
• Desarrollo secuencial vs. superpuesto

19. Principios
• Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de
software con valor.
• Aceptamos requisitos cambiantes, incluso en etapas avanzadas.
• Entregamos software frecuentemente.
• Los responsables de negocio y los desarrolladores deben trabajar juntos permanentemente.
• Construimos proyectos con profesionales motivados.
• Conversación cara a cara.
• Software que funciona es la principal medida de progreso.
• Los procesos ágiles promueven el desarrollo sostenible.
• La atención continua a la excelencia técnica y los buenos diseños
mejoran la agilidad.
• Simplicidad es esencial.
• Las mejores arquitecturas, requisitos y diseños surgen de
equipos que se auto-organizan.
• A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo.

20. Características
• Equipos auto-organizados
• El producto progresa en una serie de “sprints” que duran un mes
• Los requerimientos se encuentran en el “product backlog” reunidos en una lista
• No contiene practicas de ingeniería pre-descriptas
• Utiliza reglas generales para crear un ambiente ágil para la liberación de los proyectos
• Usado para proyectos complejos con requerimientos cambiantes
• Basado en un control de proceso empírico
• No hay prácticas de ingeniería prescritas
• Metodología de trabajo ágil
• Diseñada para acortar el ciclo de desarrollo
• Conseguir una mejor aproximación entre las funcionalidades del software y los requerimientos del cliente
• Evitar la burocracia innecesaria
• Mayor versatilidad frente a los cambios
• Comenzar el trabajo lo más rápidamente posible
• Manejo más eficiente de los requerimientos cambiantes en un proyecto
• Mejorar la comunicación entre el cliente y el equipo desarrollador
• No dice Qué hacer sino Cómo hay que hacer las cosas

21. • Trazabilidad
– Establece de forma precisa e inequívoca el seguimiento de un producto y/o servicio
durante todo su ciclo de vida.
– Formado por un conjunto de acciones, medidas y procedimientos técnicos que permite
identificar y registrar cada requerimiento de manera que se pueda seguir su ciclo de vidas
tanto para atrás, desde su origen, como hacia delante, en la entrega del producto.
– Toda la documentación, códigos y guiones de prueba deberán apuntar a su fuente de
origen para permitir saber en todo momento el origen, la implementación y las pruebas
que se hagan a cualquier requerimiento
– Bidireccional: A partir de un requisito se llega al código que lo implementa y a partir de
un determinado código saber el o los requisitos a los que corresponde.
– Vertical: Garantiza que todos los requerimientos serán diseñados y que todos los diseños
serán codificados y probados.
– Horizontal: Permite detectar si hay conflictos entre requerimientos, diseño, lógica de
codificación y/o casos de prueba

22. Practica SCRUM
• Scrum es una a practica de desarrollo muy simple, no se basa en el
seguimiento de un plan, sino en la adaptación continua a las circunstancias
de la evolución del proyecto.
Es un modo de
desarrollo de
carácter adaptable
más que predictivo.
Orientado a las
personas más que a
los procesos.
Emplea la
estructura de
desarrollo ágil
incremental basada
en iteraciones y
revisiones.

23. Cancel
Gift wrap
Return
Sprint
2-4 semanas
Objetivo del Sprint
Sprint
Backlog
Incremento del producto
potencialmente entregable
Product
Backlog
Daily Scrum
24 horas
Responsable del producto:
“Product Owner”
Responsables del
desarrollo: “Scrum Team”
Responsable del
funcionamiento de Scrum:
“ScrumMaster”
Roles
•Planificación del Sprint
•Seguimiento del Sprint
•Revisión del Sprint
•Scrum diario
Reuniones
•Product Backlog
•Sprint Backlog
•Incremento
•Graficos “Burndown”
Artefactos
Incremento en
el Producto

25. Propietario del Producto
• Persona conocedora del entorno de negocio del cliente y de la visión del producto.
Representa a todos los interesados en el producto final. Sus responsabilidades son:
– Define las funcionalidades del producto
– Decide sobre las fechas y contenidos de los releases
– Es responsable por la rentabilidad del producto (ROI)
– Prioriza funcionalidades de acuerdo al valor del mercado/negocio
– Ajusta funcionalidades y prioridades en cada iteración si es necesario
– Acepta o rechaza los resultados del trabajo del equipo
– Financiación del proyecto
– Define funcionalidad requerida
– Retorno de la inversión del proyecto
– Lanzamiento del proyecto
– Representa a la gestión del proyecto
– Toma las decisiones de priorización
– Representa a todos los interesados en el producto final

26. El Scrum Master
• Sus responsabilidades son:
– Responsable de promover los valores y prácticas de Scrum
– Se asegura de que el equipo es completamente funcional y productivo
– Permite la estrecha cooperación en todos los roles y funciones
– Escudo del equipo de interferencias externas
– Garantiza el funcionamiento de los procesos y metodologías que se emplean. Formación y entrenamiento
de procesos.
– Incorporación de Scrum en la cultura del equipo
– Garantía de cumplimiento de roles y responsabilidades
– Remueve impedimentos. Facilitador.
– Es un role flexible:
• Dirección de la empresa, con el conocimiento de gestión y desarrollo ágil y facilitando los recursos necesarios
• Responsables del Departamento
• Responsables del área de gestión de proyectos

27. El Equipo
• Responsable de transformar la pila del sprint en un incremento de la
funcionalidad del software. Sus características son:
– Equipo multidisciplinar que cubre todas las habilidades necesarias para generar el
resultado
– Se auto-gestiona y auto-organiza
– Dispone de atribuciones suficientes para toma de decisiones sobre cómo realizar su
trabajo
– Típicamente de 5 a 9 personas
– Los miembros deben ser preferentemente full-time.
– Los equipos son Auto – gestionado y Auto – organizado
– Solo puede haber cambio de miembros entre los
sprints
– Transforman los requerimientos en funcionalidad en
cada incremento

28. Interdependencias de los roles
Interesados PO PM SM Equipo
>> Asegura que el proyecto cumple objetivos
>> Administra al equipo Auto-organizado
>> Administra el alcance y el presupuesto
>> Administra la comunicación entre involucrados
>> Gestiona riesgos y elimina obstáculos
>> Administra el proceso
>> Gestiona la visión Mejora continua
>> Investigación de mercado. Visión, Voz del Cliente
<< Asegura que el proyecto logra los objetivos
<< Negocia el trabajo con el equipo
<< Gestiona el alcance, cronograma, y presupuesto
<< Gestiona la comunicación con los interesados
>> Visualiza y distribuye información
>> Remueve impedimentos

29. • Otros roles:
– Propietario de la arquitectura: es el encargado de realizar las decisiones de la arquitectura para el
equipo.
– Especialista: en la mayoría d equipos agiles no existe especialistas, sin embargo en
– proyectos a gran escala es necesario de conocimientos específicos.
– Experto de dominio: es parte del equipo de trabajo del propietario del producto, el cual ayudara a
definir los requerimientos del sistema.
– Expertos técnicos: Son parte del equipo de manera temporal, los cuales ayudan a superar problemas
con altas dificultades, así mismo transfieren parte de sus habilidades a los desarrolladores.
– Tester independiente: En algunas ocasiones se utilizan equipos de pruebas independientes, para
ayudar a validar el trabajo realizado a lo largo del ciclo de vida.
– Integrador: es en el cargado de adaptar y construir todo el sistema desde los diversos subsistemas.

30. Historias de usuario
Historia de
Usuario (2)
Como <Tipo de
Usuario>, Quiero,
<Hacer algo>,
Para <Propósito>
Personas (1)
Personas, Usuarios
o consumidores
finales,
Interesados,
Patrocinadores,
Equipo de
desarrollo, Equipo
de soporte
Contexto (4)
Necesidad origen, Escenarios de uso de la historia, Dominio del
negocio, qué áreas del negocio usan o se impactan por la historia,
Reglas del negocio que afectan la historia, Épica origen. No todas las
historias provienen de una épica en particular pero si es así, es bueno
conocerla, Alcance de la historia
Definición de Preparado (5)
Que se debe cumplir para que la
historia se pueda construir?
Definición de Terminado (6)
Condiciones de Terminado
especificas a la historia
Criterios de
Aceptación (3)
Resultado Esperado (7)
Solución esperada, Que se
quiere cumplir con la
Historia?, Valor a ganar
Métricas (8)
Puntos, Esfuerzo, Numero de
iteraciones, Valor, Ganado, Calidad,
Progreso, Numero de usuarios
Retroalimentación (9)
Nivel o Grado de Satisfacción de las
personas, Nivel de Felicidad del usuario
Impacto generado, Qué hacer para mejorar
Importancia (10)
Desde el punto de vista del negocio. Definido por Dueño de Producto.
Categoría (12)
Categorización básica de la historia.
Estimación (11)
Valoración inicial del Equipo del esfuerzo necesario para implementar la historia, comparada con otras historias.

31. • El acrónimo INVEST para describir las características de una buena historia:
– Independiente: las historias pueden completarse en cualquier orden.
– Negociable: los detalles de la historia son co-creados por los programadores y los clientes
durante el desarrollo.
– Valiosa: la funcionalidad es valiosa para los clientes o los usuarios del software.
– Estimable: los pgoramadores pueden encontrar una estimación razonable para construir la
historia.
– Pequeña: las historias deberían construirse en poco tiempo, generalmente alrededor de
"días/persona". Se tienen que poder construir muchas historias en una iteración.
– Testeable: se debe poder escribir pruebas que verifiquen que el software de la historia
funcione adecuadamente.
• Una forma habitual de escribir las historias es "Como <rol>.... Quiero
<característica>... Para <valor>". La parte del "Como..." se refiere a la persona que
quiere la historia. La parte "Quiero..." describe la funcionalidad de la historia, y la
parte "Para..." describe el motivo por el cual se pide esa funcionalidad.

32. • Técnicas de priorización de historias de usuario:
– MoSCoW se basa únicamente en dividir las funcionalidades en cuatro grupos en función de su
prioridad. Es conveniente que el número de funcionalidades esté equilibrado en cada grupo.
MoSCoW es un pseudo-acrónimo formado por las cuatro categorías en las que se tienen que dividir
todas las funcionalidades:
• Must Have (Imprescindibles): son funcionalidades que deben ser incluidas antes de que el producto pueda ser
puesto en producción. En el contexto de gestión lean, se denomina Mínimo Producto Viable (MVP por sus
siglas en inglés) a aquel que contiene únicamente este conjunto de características. Sin alguna de ellas, el
producto no tendría sentido.
• Should Have (Importantes): son funcionalidades importantes y de gran valor para el usuario pero que no
impiden poner el proyecto en marcha si no se tienen. Obviamente, son las siguientes en la lista de prioridad y
deberían incluirse justo después de haber finalizado el Mínimo Producto Viable.
• Could Have o (Buenas): son funcionalidades que sería deseable tener y podrían incluirse en caso de que
hubiese recursos para ello. No obstante, en caso de que sea necesario, se podrían descartar.
• Won’t Have o (Excluidas): son funcionalidades que el cliente ha solicitado inicialmente pero que se descartan
por falta de recursos (tiempo, dinero, etc). Como la priorización debe realizarse de forma iterativa a lo largo del
proyecto, algunas de estas funcionalidades pueden considerarse en el futuro.

33. – Theme Scoring es una técnica que permite determinar la prioridad de las funcionalidades como una combinación de
diferentes criterios, a los que se puede dar diferente importancia. A cada historia de usuario se le asigna un peso de 1
a 5 en cada una de las características. Para ello, por cada característica se elige una historia de usuario de referencia,
que tenga un valor medio de 3. A las demás historias de usuario se les asigna el peso en cada característica en
comparación con la historia de usuario de referencia. La estimación de una característica por comparación es siempre
mucho más sencilla y rápida que la estimación de una medida absoluta.
– WSJF es una técnica que prioriza en función del valor, coste y riesgo equitativamente y de forma sencilla. Consiste en
sumar el valor al usuario, el valor de tiempo (necesidad de un plan B) y la reducción del riesgo que aporta la historia y
dividirlo por el tiempo que llevaría realizarla. Es un algoritmo optimizado económicamente para la priorización y
programación del trabajo en un ambiente en el que el coste de la demora y la duración de los elementos de trabajo
varían.
• WSJF = (Valor de Negocio/Usuario + Valor del Tiempo + Reducción de Riesgo & Valor de Oportunidad) / Tamaño
del trabajo

34. • Donde los anteriores significan…
– Valor de Negocio/Usuario: Es el valor que da la empresa o el usuario. Aquí también hay que incluir los
costes de penalización si los hubiera así como los ingresos. Para darle un valor podemos escoger una
escala de 1,2,3,5,8,13, siendo 1 lo más bajo y 10 lo más alto.
– Valor de tiempo: En esta medida, lo que intentamos medir es la necesidad de un “plan B” por si las
cosas salen mal, ya sea por la pérdida de contratos, clientes o ingresos. Podemos usar la misma escala
de antes, en la que 1 sea una necesidad baja de este plan b, y el 13 una necesidad total el tenerlo.
– Reducción de Riesgo & Valor de Oportunidad: En esta parte damos un valor a la necesidad de la
empresa de reducir riesgos o el potencial de las nuevas oportunidades de negocio que se derivan del
trabajo actual. Como antes, usaremos la misma escala.
– Tamaño del trabajo: Estimación del tiempo necesario para poner una nueva característica o función del
producto en producción. Podemos usar como antes la misma escala, o tomar una que sea en semanas,
por ejemplo.
– El resultado que nos de la fórmula con los datos anteriores nos prioriza las tareas, pasando a hacer
primero las de un valor más alto.

35. Product Backlog
• Listado con los requisitos del sistema. Una lista de todos los trabajos deseados en el proyecto
– Priorizadas
– Documento "vivo"
– Accesible a todos los roles
– Todos pueden contribuir y aportar elementos
– El propietario del producto es su responsable:
• Representa los intereses del cliente dentro de la empresa.
• Es el nexo entre el cliente y el equipo.
• Tiene la visión global del producto buscado.
• Es el encargado de armar y priorizar el Product Backlog (Lista priorizada de
requerimientos).
• Cada tema tiene valor para el usuarios o el cliente (desde el punto de vista del
negocio)
• Repriorizada al comienzo de cada Sprint
• Es dinámico.
• Mientras exista un producto, el Product Backlog también existe.

36. Pila de producto
-- Requisitos priorizados.
-- Listado con los requisitos
del sistema.
Selección de la
Pila de producto
(Product Backlog)
-- Funcionalidades
Pila del sprint Nueva
funcionalidad
• Product Owner
(modificar cuidando la
inversión).
• Stakeholders (usuario,
soporte técnico,
administradores,etc )

37. Sprint
• Cada iteración se llama sprint y se realiza una revisión de los requisitos con todas las personas
involucradas en el proyecto
• Dentro de cada sprint, SCRUM gestiona la evolución del proyecto mediante reuniones breves
de seguimiento en las que se revisa el trabajo realizado desde el hito anterior y los planes para
el hito siguiente
• Las reuniones de seguimiento de cada sprint deben ser diarias
• La duración típica es 2–4 semanas o a lo sumo un mes calendario
• La duración constante conduce a un mejor ritmo
• El producto es diseñado, codificado y probado en el Sprint
• No hay cambios en un sprint. Planee la duración del sprint en
torno a cuánto tiempo usted puede comprometerse a
mantener los cambios fuera del sprint.
• El objetivo del Sprint. Una breve declaración de cual será el
foco del trabajo durante el sprint.

38. Planificación del Sprint
• El equipo selecciona los temas a partir del Product Backlog que pueden
comprometerse a completar
• Los Sprints duran, idealmente, menos de un mes.
• Se seleccionan los requerimientos del Product Backlog que entrarán en el sprint.
• Se hace un listado de todas las tareas necesarias para terminar el sprint backlog,
indicando el esfuerzo de cada una.
• Se asignan responsables a las tareas
• El diseño de Alto Nivel es considerado

39. Sprint Planning meeting
Priorización
• Analizar y evaluar el Product
Backlog
• Seleccionar el objetivo del
Sprint
Planificación
• Decidir como alcanzar el
objetivo del Sprint (diseño)
• Crear el Sprint Backlog (tareas)
en base a los temas del
Product Backlog (user stories /
features)
• Estimar Sprint Backlog en
horas
Objetivo
del Sprint
Sprint
Backlog
Condiciones
del Negocio
Capacidad
del Equipo
Product
Backlog
Tecnología
Producto
Actual

40. • Primera reunión (Las primeras cuatro horas se dedican al Product Owner):
– Se establece la meta del Sprint
– Se identifica la funcionalidad que se va a construir en el Sprint
• Segunda reunión (Las segundas cuatro horas el equipo planea su propio Sprint):
– Se identifican y estiman las tareas para satisfacer
– Se crea un Sprint Backlog
– Las tareas son distribuidas por decisión de los miembros del equipo
– Los miembros del equipo se comprometen a cumplir con la meta del Sprint
• Entradas:
– Backlog del producto actualizado
– Retorno del ultimo Sprint
– Rendimiento del equipo en los Sprints anteriores
• Salida:
– Pila del sprint (Sprint Backlog)

41. • Pila del sprint (Sprint Backlog)
– Trabajo o tareas determinadas por el equipo para realizar en un sprint
y lograr al final del mismo un incremento de la funcionalidad.
– Se recomienda que las tareas reflejadas tengan una duración
comprendida entre las 4 y las 16 horas de trabajo.
– Las de mayor duración deben intentar descomponerse en sub-tareas
de ese rango de tiempo.

42. • Gestión del Sprint Backlog
– Los individuos eligen las tareas
– El trabajo nunca es asignado
– La estimación del trabajo restante es actualizada diariamente
– Cualquier miembro del equipo puede añadir, borrar o cambiar
el Sprint Backlog
– El trabajo para el Sprint emerge
– Si el trabajo no está claro, definir un tema del Sprint Backlog
con una mayor cantidad de tiempo y subdividirla luego.
– Actualizar el trabajo restante a medida de que más se conoce

43. Estimación de póquer
• La estimación no la realiza el cliente / Product Owner, por que no es él quien se va
a “ensuciar las manos” y luchar por cumplir con fechas.
• Todo el equipo realiza la estimación para:
– Reforzar el compromiso de todo el equipo respecto a las fechas que dan al cliente.
– Reforzar el compromiso de cada miembro del equipo respecto al resto.
– Hacer que todo el mundo se sienta oído.
• Estimar usando una unidad:
– Días ideales: los días necesarios para que el equipo
pueda completar un objetivo, sin considerar
interrupciones. Para pasar a días reales hay que aplicar
un factor de corrección que puede ir del 60 % al 70 %
de dedicación real al proyecto. Asimismo, habrá que
tener en cuenta un margen para imprevistos.

44. – Puntos de historia de usuario: la complejidad que tiene cada historia de usuario. Un equipo en un
proyecto determinado es capaz de completar un número semi-regular de puntos de historia cada
iteración (“velocidad”).
• Es una práctica ágil, para conducir las reuniones en las que se estima el esfuerzo y la duración
de tareas. El modelo consta de 8 cartas: ½, 1, 2, 3, 5, 6, 7 e infinito.
• El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la
estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo
estimado.
• Cuando se considera que éste es mayor de x horas ideales (el tamaño máximo considerado
por el equipo para una tarea), se levanta la carta “infinito”. Las tareas que exceden el tamaño
máximo deben descomponerse en sub tareas de menor tamaño
• Cada equipo u organización puede utilizar un juego de cartas con las numeraciones
adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se
va a estimar.

45. • Procedimiento
– Cada participante de la reunión tiene un juego de cartas.
– Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que
se va a estimar) el cliente, moderador o propietario del producto expone la descripción
empleando un tiempo máximo.
– Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las
posibles preguntas del equipo.
– Cada participarte selecciona la carta, o cartas que representan su estimación, y las
separa del resto, boca abajo.
– Cuando todos han hecho su selección, se muestran boca arriba.
– Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido, la tarea
debe dividirse en sub-tareas de menor tamaño.

46. – Si las estimaciones resultan muy dispares, quien asume la responsabilidad de gestionar
la reunión, con su criterio de gestión, y basándose en las características del proyecto,
equipo, reunión, nº de elementos pendientes de evaluar, puede optar por:
• Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por
qué crees que es necesario tan poco tiempo? Tras escuchar las razones, repetir la estimación.
• Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado
pendientes.
• Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las
funcionalidades resultantes.
• Tomar la estimación menor, mayor, o la media.
• Este protocolo de moderación, evita en la reunión los atascos de análisis circulares en ping-pong entre diversas
opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora
de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin discusiones,
y además resulta divertido y dinamiza la reunión.
• Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por
las razones que sean, no se puede precisar una estimación. También es posible incluir otra
carta con alguna imagen alusiva, para indicar que se necesita un descanso

47. Ejecución del Sprint
• Periodo fijo de tiempo durante el cual el equipo desarrolla un
incremento de funcionalidad (no mas de 30 dias)
• No se aceptan cambios a los requerimientos acordados.
• El producto es diseñado, codificado, probado durante el Sprint.
• Solo el Scrum Master puede cancelar el Sprint cuando:
– La tecnologia no funciona
– Las circunstancias del negocio cambiaron
– El equipo tuvo interferencias
• Las iteracciones cortas permiten reducir los riesgos

48. • Es el periodo de tiempo durante el que se desarrolla un incremento de
funcionalidad. Constituye el núcleo de Scrum, que divide de esta forma el
desarrollo de un proyecto en un conjunto de pequeñas “carreras”.
• Duración máxima: 30 días.
• Durante el sprint no se puede modificar el trabajo que se ha acordado en el
Backlog.
• Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo puede hacer el
Scrum Master si decide que no es viable por alguna de las razones siguientes:
– La tecnología acordada no funciona.
– Las circunstancias del negocio han cambiado.
– El equipo ha tenido interferencias.
• Diariamente se realiza una reunión diaria llamada Daily Scrum, y al final del Sprint,
se realiza una reunión de revisión de Sprint, llamada Sprint Review

49. Fin del sprint: Sprint review
• Reunión donde se presenta al product owner y a los implicados todas las funcionalidades implementadas.
• Normalmente adopta la forma de una demo de las nuevas características o la arquitectura subyacente
– Informal
– Duracion de 4 horas. Regla de 2 hs preparación.
– No usar diapositivas
– Todo el equipo participa
– Se invita a todo el mundo
• El Product owner trata con los asistentes y con el team las posibles modificaciones en la pila de producto.
• Al final de la reunión se interroga individualmente a todos los asistentes para
recabar impresiones, sugerencias de cambio y mejora, y su relevancia.
• Después del Sprint review y antes de la proxima Sprint planning meeting,
el ScrumMaster convoca a una Sprint retrospective del Sprint con el Team.

50. • Objetivo:
– Presentar el Product Owner y demas involucrados del proyecto el trabajo realizado (incremento del
producto) durante el Sprint.
• Participan:
– Equipo, Scrum Master, Product Owner, todas las personas involucradas en el proyecto.
• Reglas:
– El Equipo no invierte mas de una hora en preparar el Sprint Review
– Las funcionalidades no finalizadas completamente no se presentan
– Los miembros del equipo presentan las funcionalidades
– Las demostraciones se realizn en el equipamiento de los miembros del equipo
– Al finalizar la reunion se piden opiniones a los participantes, los cuales pueden sugerir cambios y mejoras.
• Al finalizar:
– El Product Owner decide si la funcionalidad presentada cumple con los objetivos del Sprint
– Se actualiza y vuelve a priorizar el Product Backlog
– El Scrum Master anuncia el lugar y la fecha de la proxima revision del Sprint.

51. Sprint retrospective
• Periódicamente, se echa un vistazo a lo que funciona y lo que no.
• Normalmente 30 a 90 minutos
• Se realiza luego de cada sprint
• Todo el equipo participa: ScrumMaster, Product owner, Equipo,
Posiblemente clientes y otros
• El ScrumMaster hace que el Team revise, su proceso de desarrollo
Scrum, para hacerlo más eficaz y eficiente para el próximo Sprint.
• El ScrumMaster no proporciona respuestas, sino que ayuda al equipo a
encontrar la mejor forma de trabajar con Scrum.
• En conjunto, Sprint planning meeting, Daily Scrum, Sprint review, y el
Sprint retrospective, constituyen la inspección empírica y prácticas de la
adaptación del Scrum.

52. • Objetivo:
– Identificar que cosas se pueden cambiar para hacer el trabajo mas agradable y productivo en las proximas
iteraciones.
– Se realiza al finalizar el Sprint
• Participan:
– Team, Scrum Master, Product Manager (opcional)
• Reglas:
– Dos preguntas que todos deben responder:
• Que cosas hicimos bien?
• En que cosas podemos mejorar?
– Todo aquello que afecte como el equipo construye se debe debatir.
– Permite al equipo evolucionar continuamente mejorando durante el proyecto.
• Al finalizar:
– Lista de oportunidades de mejora.

53. Daily Scrum (Comenzar / Parar /
Continuar)
• Breve reunión diaria para repasar cada una de las tareas y el trabajo previsto de la jornada.
Dura 15 minutos
• Sólo interviene el equipo de desarrollo
• No para la solución de problemas. No es dar un reporte de estado al Scrum Master, se trata
de compromisos delante de pares
– Todo el mundo está invitado
– Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar
– Ayuda a evitar otras reuniones innecesarias
• Cada miembro responde a tres questiones: Trabajo realizado desde la reunión anterior,
Trabajo que se va a realizar hasta la próxima reunión de seguimiento, Problemas que se
deben solucionar para realizar el trabajo propuesto
• Todo el equipo se reúne y discute lo que les gustaría: Comenzar a hacer, Dejar de hacer,
Continuar haciendo

54. Incremento
• Demostración de los objetivos alcanzados en cada sprint
• Asistencia de todos los roles, “Product Owner” e incluso usuarios
• Sólo el Scrum Master puede abortar un Sprint debido a una de las
siguientes razones:
– La tecnología seleccionada no funciona o es incompatible con los objetivos
definidos
– Han cambiado las circunstancias de negocio
– El Scrum Team ha tenido inferencias

55. Prácticas para la gestión del proyecto
• Revisión de las iteraciones: al final de cada sprint
• Desarrollo incremental: Al final de cada sprint debe haber una parte del
producto operativa que se pueda inspeccionar y evaluar
• Desarrollo evolutivo: No se define la estructura final, la arquitectura o el
diseño final del producto ya que los requisitos son cambiantes. Se utilizan
técnicas de refactorización en las fases de diseño y codificación
• Auto-organización: Los equipos son auto-organizados con márgenes de
decisión suficientes para tomar las decisiones que se consideren oportunas
en los sucesitos sprint
• Colaboración: Se apuesta por una colaboración abierta entre todos los
integrantes según sus conocimientos y capacidades, no según su rol o
puesto.
• Veremos como estructurar un proyecto ágil …

57. • Estudio de viabilidad y de negocio. Las dos primeras fases son secuenciales.
– Estudio de viabilidad:
• Calcular los costes
• Ver si es técnicamente viable
• Asegurarse de que DSDM sea el enfoque adecuado
– Estudio de negocio:
• Modelado del proceso del negocio
• Fuerte colaboración cliente-equipo de desarrollo.
• Iteración funcional del modelo e Iteración de diseño y construcción:
– Iteración funcional del modelo:
• Refinar aspectos funcionales del negocio.
– Iteración de diseño y construcción:
• El producto se vuelve apto para los usuarios.

58. – Las dos fases consisten en ciclos de 4 actividades:
• Identificación
• Planificación
• Producción
• Validación
• Implementación:
– Implementación, entrenamiento, revisión y aceptación de usuarios y revisión del negocio.
– Al final puede ocurrir:
• Falta una parte técnica
– Iteración de diseño y construcción
• Se ha descubierto una nueva funcionalidad
– Estudio del negocio
• Falta una funcionalidad secundaria
– Iteración funcional del modelo
• Todos los requerimientos cumplidos
– Fin

62. Cliente
Equipo
• Control empírico: interactivo e incremental
Hacer entregas cortas y regulares del
producto final (2-4s) para obtener feedback e
irse acercando a las expectativas del cliente.
Participación del cliente,
transparencia para que pueda guiar
de manera regular los resultados del
proyecto.

63. • La planificación ágil parte de
la idea de planificar en
función de objetivos de
negocio en lugar de tareas (a
diferencia de la planificación
tradicional), priorizando los
que aportan más valor, y
esperando a dar detalle a
objetivos y tareas conforme
se va acercando el momento
de construcción de estos
objetivos, cuando la
indeterminación se va
reduciendo, de manera que
se amortiza el esfuerzo de
planificar de manera
detallada.

65. • La planificación ágil toma
como base el control
empírico de la construcción
de producto (inspección y
adaptación)

66. Cliente Entregas de los
objetivos más
importantes
Entrega final
Equipo
• Priorización por valor de negocio
Proporcionar resultados
anticipados (“time to
market”)
Orientar el proyecto a objetivos para el cliente, no a
tareas, priorizando según el valor de negocio vs
esfuerzo y riesgo.

67. • Herramientas: Gráfico Burn-Up. Utilizado por el Product Owner. Muestra: las versiones
previstas de un producto, funcionalidades de cada una de ellas, velocidad estimada, fechas
probables para cada versión, margen de error previsto en las estimaciones, y avance real

68. • Herramientas: Gráfico Burn-Down. Utilizado por el Scrum Team para
seguimiento del trabajo de cada Sprint

69. • Pruebas
– Test Driven Development
• Diseño e implementación de las pruebas antes de programar la funcionalidad
• El programador crea sus propios tests de unidad
– Integración continua (Integración diaria, Disponer de una máquina para integración)
– Tests funcionales (Cliente)
• Semana de 40 horas
– El desarrollo de software es un ejercicio creativo
• hay que estar fresco y descansado
– Sin “héroes”
– Se reduce la rotación de personal
– Mejora la calidad del producto
– Se permiten excepciones, con cuidado
• más de una semana de horas extra: problema

70. • Propiedad colectiva del código
– Cualquier integrante del grupo tiene autoridad para cambiar cualquier parte del código fuente
– Todos son dueños del código
– Siempre se utilizan estándares
– Los tests siempre deben funcionar al 100%
– Se integra con todo el sistema permanentemente
– Manejo de configuración
• Diseño simple, entregas pequeñas
– Se debe mantener el diseño lo mas simple posible (YAGNI): “No vas a necesitarlo”
– Tarjetas CRC
– Design for change vs Design for today
• Características útiles en términos del negocio
• No implementar características que no son necesarias
– Poner en producción lo antes posible
– Unas pocas semanas por entrega

71. • Refactorización
– Si el código se está volviendo complicado
• modificar el diseño, volver a uno más simple
– Refactoring: modificar la forma del código sin cambiar su funcionamiento
• Ejemplos: extraer método, renombrar (clase, método, variable, etc.), reemplazar
– Hay herramientas
• C#Refactory (Xtreme Simplicity)
• Conciliar el enfoque ágil y contratos de precio fijo. Es posible ofrecer al Cliente: a) cambio de
alcance dinámico gratis, b) generación de valor y c) riesgo compartido (evitando juego de suma
cero). Simultáneamente, la organización mejora su flujo de caja, contiene sobre costos y el disparo
del alcance.
– Aceptar cambios, de la siguiente forma
• Sobre lo no desarrollado, de lo contrario tiene costo
• Sobre lo no desarrollado, substituir requerimientos registrados por los nuevos, que tengan una
estimación de esfuerzo similar, o de lo contrario tiene costo

72. – Aplicar tarifas diferenciales
• Aplicable por cumplimiento de cronograma: 100%
• Aplicable por incumplimiento de cronograma: 90%
• Aplicable por mejora de cronograma: 115%
– Permitir la cancelación anticipada
• Penalidad del +20% luego de que el 85% del proyecto sea entregado.
• Luego de que avance el proyectos, y se podrá re estimar los sub entregables en base a cambios,
riesgos descubiertos.
– Armado y entrega de paquete por funcionalidad
• Descomponer SOW en sub entregables, y pagar por paquete
• Considerar fijar dos alcances: a) prueba de concepto, al que se le aplica un metodología ágil y
b) desarrollo, el que se realiza de forma también ágil o a través de un contrato fijo.

73. • Dividir las historias
– Datos
– Casos especiales
– Operaciones (ABM “Altas, Bajas y Mantenimiento” o CRUD “Crear, Leer, Actualizar y Borrar”)
– Temas transversales y no funcionales: seguridad, log, manejo de errores, performance, volumen
– Prioridad
• No dividir
– Por debajo de 2/5 días
– En tareas
– Y no agregar trabajo no priorizado…
• Sprint 0, permite identificar los objetivos y reducir la incertidumbre respecto al alcance,
definir viabilidad, o plataforma tecnológica. El objetivo último es obtener una visión clara de:
– Qué queremos implementar, en forma de Product Backlog y prototipos.

74. – Cómo lo queremos implementar, en forma de Arquitectura técnica.
– Y cuánto (tiempo y dinero) aproximadamente nos va a costar llegar a cada una de las posibles fases
principales de la implementación del proyecto.
Dentro de ese Product Backlog es habitual encontrar clasificadas las Épicas en estos tres grupos:
MVP (Producto Mínimo Viable), MMP (Producto Mínimo Comercializable) y Funcionalidades futuras.
Evidentemente, las Épicas de los dos primeros grupos se habrán descompuesto en Historias de Usuario y
se habrá estimado su complejidad lo que ha permitido priorizarlas, apoyadas además por Prototipos y
Propuesta Gráfica (desde el punto de vista de Usabilidad) y por una Arquitectura propuesta e,
incluso, Pruebas de Concepto de aquellos elementos tecnológicos más innovadores.
Pero, dado que en este punto ya se tiene una orientación de alcance (MVP y MMP) lo que permite a
“Negocio” obtener una visión muy aproximada de cuál será el resultado del proyecto, también es posible
minimizar las inquietudes tanto de la Gerencia (orientación en cuanto a Costes y Plazos), como de los
equipos de Tecnología (cuándo se estima que deberán estar disponibles los entornos y equipos que
sustenten el nuevo producto, qué personas formarán el equipo, que recursos harán falta, qué nuevos
productos o frameworks se introducen en el ecosistema a mantener, etc).

75. Prácticas para la gestión del producto
• Técnica para entender y planear una entrega incremental de MVPs. La técnica
organiza ideas y recursos en un modelo que busca entender la finalidad principal
del producto, considerando las jornadas de los usuario para realizar las entregas
incrementales de productos viables. Como un libro de recetas, con una secuencia
de actividades, rápidas y eficaces, la técnica va a permitir que el equipo:
– Describa la visión del producto. El producto Es - No es - Hace - No hace
– Priorize los objetivos del producto. Entendiendo los trade-offs.
– Describa los principales usuarios, sus perfiles y sus necesidades
– Entienda las principales funcionalidades
– Comprenda los niveles de incertidumbre, esfuerzo y valor de
negocio por uncionalidad
– Describa las jornadas más importantes de los usuarios
– Cree un plan de entrega incremental del producto, impulsado
por el concepto de MVP
– Estime el esfuerzo por muestreo
– Calcule los costos y especifique fechas en el cronograma de
entrega
22:34 75

76. • El Canvas MVP
– Es una herramienta para validar ideas de productos. Es un marco visual que ayuda a los
empresarios para alinear y ajustar la estrategia del MVP (Minimum Viable Product, en inglés).
Se divide en siete bloques:
• MVP Visión general – ¿Cuál es la visión de este MVP?
• Métricas para validar el modelo de negocio – ¿Cómo podemos medir los resultados de este MVP?
• Resultado esperado – ¿Qué esperamos como aprendizaje o resultado de este MVP?
• Características – ¿Qué vamos a construir en este MVP? ¿Qué acciones se simplificarán / mejorarán en
este MVP?
• Personas y Plataformas – ¿Para quién es el MVP? ¿En qué plataforma estará disponible?
• Historias – ¿Qué historias se cumplen o mejoran con este MVP?
• Costo y horario – ¿Cuál es el costo y la fecha prevista para la entrega de este MVP?
– Al usar el Canvas MVP, ​​ponemos los dos bucles uno al lado del otro. De “Lean startup”, el
bucle de construir-medir-aprender. Del Design Thinking, el bucle de usuario-journey-acción.
En ambos bucles, la respuesta a qué construir: las funcionalidades del MVP.
22:34 76

77. • Cuando una composición de funcionalidades alcanza una versión simple del producto que podría estar
disponible? Usted debe planear una secuencia de ondas para agrupar las funcionalidades de manera que lo ayude
a organizar la producción, considerando limites de funcionalidad, nivel de riesgo, esfuerzo y valor de negocio.
• El MVP debe de ser factible, usable, valioso. El Canvas MVP, permite validar ideas de productos. Es un marco
visual que relaciona dos bucles. De “Lean startup”, el bucle de construir-medir-aprender. Del Design Thinking, el
bucle de usuario-journey-acción. En ambos bucles, la respuesta a qué construir: las funcionalidades del MVP.
22:34 77
Personas y plataformas
Usuario
Visión de MVP Resultado Esperado
Aprender
Funcionalidad
Jornadas de usuario Métrica (validación hipótesis)
Costo y Cronograma de
Entrega
Medir
Aprende
r
Construir
Usuario
Experiencia
Acción

78. Proceso de desarrollo del producto por etapas
Evaluación de
conceptos
Valida ideas, planifica y
especifica
Desarrollo Evaluación y pruebas Lanzamiento
Prospección.
Investigación
preliminar de cada
uno de los proyectos
o ideas generados en
la fase de
descubrimiento y se
selecciona un
subconjunto de ellos.
Construir el modelo
de negocio.
Mediante una
investigación minuciosa
por parte de los equipos
técnicos y comerciales
definiendo y justificando
el producto desarrollando
el plan de proyecto.
Desarrollo
Establece el
diseño y
desarrollo de
nuevo producto y
el plan de
producción y
lanzamiento al
mercado.
Pruebas y validación.
Se efectúa una
prueba extensa del
nuevo producto en el
mercado, en el
laboratorio, o en la
planta.
Lanzamiento.
Como inicio de la
producción y
comercialización se
establecen revisiones
periódicas de post –
lanzamiento.
Visión Producto e
EPICs
Fundación
técnica/negocio.
Experiencia del usuario.
Priorización de funciones.
Estructura del
proyecto.
MVP
Funciones básicas y
validación UX.
Supuestos validados.
UAT.
MMP
Retorno primario.
Mejoras dirigidas por
la visión del usuario.
Adopción continúa.

79. Infraestructura requerida
• Plataforma para la implementación de tableros KAMBAN, fomentar el
trabajo colaborativo, gestión de incidencias y automatización de QA/QC.

80. • Lugar de trabajo
– Sala amplia (mejor, sin divisiones)
• Centro: pares de programadores
• Periferia: máquinas individuales
– Ventajas del espacio abierto:
• Mayor comunicación
• Agenda dinámica
• Cliente en el sitio
– Interacción continua
– No siempre se consigue
• muy junior, no sirve
• muy senior, no quiere
– Actualmente se pide un “analista”

81. Gestión regular de expectativas del cliente Priorización de requisitos
Resultados anticipados (“time to market”)
Demostración del proyecto en cada Sprint
Priorización de requisitos por valor/coste
Flexibilidad y adaptación Re planificación en el inicio de cada iteración
Retorno de inversión (ROI) Priorización de requisitos
Mitigación de riesgos Desarrollo iterativo e incremental
Productividad de calidad
Mejora continua
Comunicación diaria del equipo
TimeBoxing
Equipo multidisciplinar
Estimación de esfuerzo conjunta
Compromiso del equipo
Demostración de resultados
Alineamiento entre cliente y equipo Reuniones en cada itinerario (Sprint)
Equipo motivado
Equipo autosugestionado
Reuniones diarias y en cada Sprint
Fortalezas de SCRUM

82. Reflexiones
• Highsmith & Cockburn 2001
– “lo que es nuevo en los procesos ágiles no son las prácticas que usan, sino
que reconozcan a las personas como primeros implicados en el éxito de un
proyecto, además de un intenso foco en la efectividad y la manejabilidad.
Esto genera una nueva combinación de valores y principios que definen
una visión ágil del mundo.”
• Hawrysh & Ruprecht 2000
– Una sola metodología no puede funcionar para todo el espectro de
proyectos, en vez de eso el administrador de cada proyecto debería
identificar la naturaleza especifica de cada proyecto y seleccionar la
mejor metodología de desarrollo aplicable.
• McCauley 2001
– Hay una necesidad de ambos métodos [ágiles y orientados a procesos] ya
que no hay un modelo de desarrollo que se ajuste a todos los propósitos
imaginables.

83. Caso practico
• Un cliente se pone en contacto con una empresa que fabrica robots.
• El cliente les realiza el pedido.
Quiero un robot que me
sirva de escolta

84. • El Cliente se reune con el Dueño de producto, que toma nota
de lo que tiene en su cabeza.
Cliente Dueño de Producto

85. • El Duelo de Producto divide el proyecto en historias que son las que
componen la pila de producto.
Dueño de Producto
Pila de Producto

86. • El Scrum Master es un miembro del equipo que tiene el papel de
comunicar y gestionar las necesidades del Dueño de Producto y la pila de
Sprint.
• El Dueño de Producto le entrega la pila de producto para que estimen el
coste de creación del producto.
Dueño de Producto Scrum Manager

87. • El equipo se reune para estimar el coste de cada historia de la
pila de producto.
• En este caso utilizan Planning Poker.
Equipo

88. • El cliente, una vez aprobado el presupuesto, reordena la pila de producto
para que el equipo vaya trabajando según la prioridad del cliente.
Cliente
Menos imporantes
Urgentes

89. • El equipo comienza su trabajo desglosando la primera historia de la pila de
producto, la cual subdividen en tareas menores para crear la pila de sprint.

90. • La pila de sprint tiene como utilidad fraccionar el trabajo de un periodo de
15 días en tareas mas pequeñas, que tarden como mucho dos días.

91. • Estas tareas se colocan en una pila, la cual prioriza el Dueño de Producto,
que ha consultado con el cliente, antes de comenzar el sprint.
Dueño de Producto
Menos imporantes
Urgentes

92. • El equipo comienza el sprint tomando las tareas priorizadas.
• Una vez concluida una se toma la siguiente de la lista.
• Se convoca todos los días una reunión del equipo donde se cuenta las tareas realizadas el día
anterior y cuales se van a realizar ese día.

93. • Una vez finalizado el sprint, el Dueño de Producto le muestra al cliente el
resultado del trabajo realizado.
• El cliente ya tiene el primer contacto con su encargo y además puede
volver a priorizar la pila de producto antes de que comience otro sprint.
Cliente
Dueño de Producto
Buen trabajo

94. • El equipo de trabajo celebra su buen hacer con una reunión de
retrospectiva, donde se analiza lo ocurrido durante el sprint.

95. Muchas gracias!
ArturoPenasRial
arturo.penas@gmail.com