Scrum-V2 0

M1 : AGILE SCRUM
• Mg. Ing. Mariano Altuna
Mg. Ing. Mariano Altuna

Introducción a AGILE
¿Qué es agile?
¿Qué es scrum?

¿ qué es agile?
moda metodología correr mas

rápido

¿ qué es agile?
El ADN de
las empresas
Cultura Organizacional
¿ qué es agile?
Alta Dirección
Top Manager

¿Qué es lo que cambian en las
organizaciones con agile?
Pensar
Relacionarse Interactuar
Colaborar
Trabajar
4ta Revolución
Industrial
• Industria y
productos
inteligentes
• IoT, Bigdata, IA
• Hiperconectividad,
Sensores.
Agilidad Estratégica Agilidad de Portfolio Agilidad de Ejecución

Ver oportunidades grandes, Capacidad de una empresa para Cuan rápido eres para ejecutar y
formularlas y llevaras a la poder mover recursos de un tomar feedback temprano de lo
ejecución foco a otro foco mejor que deberías hacer, según las
decisiones tomadas.

¿ Por qué una empresa es más
lenta que otras?
1 2 3
Como se Mindset Uso de
toman Cultura - ágil metodologías
las decisiones ágiles

Gemba significa “El lugar de la
verdad” en donde se agrega valor.
Nos ayuda a ver los resultados Es involucrar y tomar decisiones Gemba hacer que las personas
del lugar de trabajo en el sitio en el sitio donde ocurren las se hagan responsables de sus
donde se agrega valor con los acciones que generan valor día resultados e incrementa el
responsables de cada uno de a día sentido de pertenecia
ellos

Zombie Scrum
No saber el por qué estás haciendo Scrum
“Porque nuestro Agile Coach dijo que esta era una gran idea”
“A nuestro CEO se le prometió un aumento en la productividad del 2000%”
“Todos nuestros competidores lo están usando también”
No por favor, esto no es agilidad!

Somos ágiles porque usamos herramientas SCRUM

AGILE SCRUM
Mindset Proceso

Marco de gestión Ágil
En común Depende del marco
VALORES PRINCIPOS PRÁCTICAS

Organizaciones Organizaciones
tradicionales ágiles
Crisis – Adversidades
Cambios de contexto
Zona de Salen de su
confort zona de confort
Debilidades Abrazan el cambio

¿Cuál es el estado de la agilidad a nivel mundial?

Frameworks mas utilizados

Barreras para adoptar la agilidad
Cultura organizacional en desacuerdo con valor ágil.
Organización general de resistencia al cambio.
Soporte inadecuado de gestión y patrocinio.
Falta de habilidades / experiencia con métodos ágiles.
Procesos y prácticas inconsistentes entre equipos.
Capacitación y educación insuficientes.
Falta de disponibilidad de negocio / cliente / producto.
Persistencia en los métodos de desarrollo tradicionales.

Como se mide el éxito
satisfacción del usuario

valor entregado
velocidad

Empresas ágiles : KODAK - SONY
1975 Primera
cámara digital


1981
Sony Mavica

Empresas ágiles : BLOCKBUSTER - NETFLIX
Reed Hastings

1985 - 2013 agosto de 1997
Septiembre de 2000
Red Hasting se reunió con el CEO de Blockbuster,
John Antioco para asociarse
Quebró - deuda de
900 mlls de euros.
2014 cerró
totalmente

El mundo de las empresas
¡Ninguna existía antes del 2006!
2014 - $ 20,000 mlls.
Change or die!

[ 24/04/2020 - $ 10,0000 x Second ]
2018

Empresa de software, que ofrece servicios de Banca

Cultura de una Organización Ágil
Organizaciones Organizaciones
Tradicionales Modernas
Predictivos Adaptativos

Cultura de una Organización Ágil
Top 5 habilidades blandas requeridas por las empresas el 2019
• Creatividad
• Persuasión
• Colaboración
• Adaptabilidad
• Gestión de Tiempo
Fuente : LinkedIn

Organización Ágil
Consciente

?
Las personas no saben
cual es su trabajo

¿Pueden leer este texto?

¿Cual es su
verdadero
trabajo?

¿Cual es el objetivo de un equipo de futbol?

¿Cual es el trabajo de un defensor?
¿Cual es el trabajo de cualquier jugador?
Contribuir a que el equipo obtenga su objetivo

¿Cuál es el trabajo de un defensor?
Ayudar a que el equipo gane

¿Cual es el verdadero trabajo?
Que el cliente salga satisfecho
Crear las condiciones adecuadas para

que los estudiantes puedan aprender

¿Cual es el verdadero trabajo?

GESTIÓN TRADICIONAL
OBJETIVOS POR AREA

OBJETIVOS POR AREA
TI
SILOS EMPRESARIALES

DEFENSA DELANTEROS
Impedir goles Marcar goles
ganar 5-4 ganar 1-0

perder 0-1 perder 4 - 5

GESTIÓN ÁGIL
OBJETIVOS DE EQUIPO
OBJETIVOS DE EQUIPO
MULTIDISCIPLINARIOS
EMPODERADOS
AUTO-ORGANIZADOS
COMPROMETIDOS
PRODUCTIVOS

Juegos Olímpicos
Estos jovencitos de Barcelona
nos aniquilaron. 1992 cómo
No sabíamos
jugar entre nosotros
- Scottie Pippen -
62 a 54
El propósito
Nuestro verdadero trabajo es contribuir al éxito

de la organización a la cual pertenecemos

Cumplir la misión
creando valor
con valores
comprometido involucrado

Energía de una organización
NO esta entusiasmada 10%

NO da lo mejor de si
Cumplimiento
90%
Compromiso

Tu compromiso o tu vida!
Para comprometernos realmente con algo tenemos que participar de la descisión
- Stephen Corvey – Los 7 hábitos de la gente altamente efectiva

Empresas : Compromiso a la fuerza
Lo mejor de una persona solo sale del alma
No se compra / No se vende

ORGANIZACIÓN – CONSCIENTE
• Asumiendo responsabilidades
• Justificandonos

ORGANIZACIÓN – CONSCIENTE
¿Por qué llegan tarde?

SOY INOCENTE
Si no soy parte del problema No puedo ser parte de la solución

Salen de vacaciones en un mes difícil
RRHH exige que tienen que salir
Problema
Problema
VICTIMAS PROTAGONISTAS

Protagonista o Víctima
Cuando levantas una pesa, te refieres a ti como “fuerte”

Cuando no logras levantarla, llamas a la pesa “pesada”

¿Para que Ágil?
Equivocarse Rápido Aprender Rápido

(Cumplimiento Normaltivo)

4 VALORES Y 12 PRINCIPIOS

Manifiesto Ágil
Valores
1
Individuos e Procesos y
interacciones Herramientas
Si su negocio no requiere nada de creatividad ni de innovación y le basta con

un proceso bien estructurado, puede que Scrum no sea para usted.

Manifiesto Ágil
Valores
2
Entrega temprana de «valor» Permiten la transferencia del

conocimiento
Time to market Resalta que la documenación

es menos importantes que el
resultado que aporta valor.
Software
Entrega de Documentación
Funcionando
Funcionalidad Extensiva
Si la organización y los equipos se comunican a través de documentos, se corre el peligro de

que dicha documentación se utilice de forma defensiva entre departamentos o personas.

Manifiesto Ágil
Valores
3
Colaboración con Negociación

El Cliente Contractual
Para el agilismo, la colaboración estrecha con el cliente es vital.

Por ello se realizan contratos muy genéricos, donde el cliente compra tiempo.

Manifiesto Ágil
Valores
4
Para aprovechar oportunidades :

• Posicionarse mejor frente a
los competidores.
• Maximizar el retorno de la
inversión.
Respuesta Seguir
Ante el cambio Un plan
Sea el banco Digital Bank Acme. Fija un plan para incorporar al móvil y a su aplicación web las siguientes
funcionalidades: ver saldo en cuentas, ver movimiento en cuentas, realizar transferencias, crear una cuenta
nueva, contratar un seguro de automóvil. (T: 1 año)
A los 2 meses de comenzar, Competitor Bank saca una funcionalidad que es muy bien recibida por sus clientes: el
pago a través del móvil y la desactivación instantánea de tarjetas desde el móvil, para evitar desfalcos ante la
pérdida de una tarjeta.

Manifiesto Ágil
Valores

Agile en un mundo VUCA
Es estar sujetos a cambios frecuentes,

rápidos y significativos.
Es un componente en la cual los acontecimientos

y los resultados son impredecibles.
Implica una multiplicidad de factores, algunos de los

cuales pueden estar enmarañadamente interconectados.
Se manifiesta en una falta de claridad y la dificultad

de entender exactamente cuál es la situación.

Una organización prosperará si su ritmo
de aprendizaje (agilidad) es igual o mayor
al ritmo de los cambios en el entorno VUCA

Manifiesto Ágil - Principios
Modelos mentales
Principio 1: Nuestra mayor prioridad es satisfacer Satisfacer al cliente entregándole

valor cuanto antes.
al cliente mediante la entrega temprana y
continuada de software con valor.
Feedback - Aprendizaje
Principio 2: Aceptamos que los requisitos Aceptar el cambio en los requisitos, sea
cambien, incluso en etapas tardías del cual sea el momento en el que vengan.
desarrollo. Los procesos Ágiles aprovechan el
cambio para proporcionar ventaja competitiva al
cliente.
Cambios en cualquier etapa
Principio 3: Entregamos software funcional

Entregar valor frecuentemente.
frecuentemente, entre dos semanas y dos meses,
con preferencia por periodos de tiempo lo más
corto posibles.
Iterativo e incremental

Modelos mentales
Trabajar codo con codo con el cliente.

Principio 4: Los responsables de negocio y los
desarrolladores trabajamos juntos de forma
cotidiana durante todo el proyecto
PO – Development Team
Principio 5: Los proyectos se desarrollan en torno

Trabajar con equipos motivados.
a individuos motivados. Hay que darles el
entorno y el apoyo que necesitan, y confiarles la
ejecución del trabajo.
Un equipo motivado entra en

un ciclo virtuoso de mejora continua
Principio 6: El método más eficiente y efectivo de Buscar el cara a cara para comunicarnos
comunicar información al equipo de desarrollo y
entre sus miembros es la conversación cara a cara
Comunicación con eficacia.
Seguros de que todos entienden

Modelos mentales
Medir el progreso por lo entregado

Principio 7: El software funcionando es la
principal medida progreso.
Criterios de aceptación
que aporten valor al negocio
Principio 8: Los procesos Ágiles promueven el Mantener un ritmo de trabajo sostenible

desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces
de mantener un ritmo constante de forma
indefinida.
Si encontramos un ritmo de trabajo sostenible,

seremos productivos indefinidamente
Principio 9: La atención continua a la excelencia Intentar ser muy bueno en lo que hacemos
técnica y al buen diseño mejora la Agilidad
Un equipo comprometido y con miembros de gran

talento realiza el mismo trabajo en la mitad de tiempo

Modelos mentales
Minimizar el desperdicio y el
Principio 10: La simplicidad, o el arte de trabajo que no aporta valor
maximizar la cantidad de trabajo no realizado, es
esencial.
No perder el tiempo en tareas que no aportan valor
Principio 11: Las mejores arquitecturas, requisitos Permitir que el equipo se auto-
organice para obtener los mejores
y diseños emergen de equipos auto-organizados.
resultados
El lider indica la visión y equipo se
Auto-organiza, basado en confianza y empoderamiento
Principio 12: A intervalos regulares el equipo Reflexionar sobre nuestros éxitos

reflexiona sobre cómo ser más efectivo para a y fracasos.
continuación ajustar y perfeccionar su
comportamiento en consecuencia.
Periódicamente el equipo se reúne

para reflexionar sobre cómo puede mejorar.

¿ Qué es agile ?
AGILE ES UN DESCRITO POR DEFINIDO POR MANIFESTADO A TRAVÉS DE

MINDSET 4 VALORES 12 PRINCIPIOS ILIMITADO NUMERO DE PRACTICAS
MINDSET VALORES PRINCIPIOS PRACTICAS
SER HACER

¿ Qué es agile ?

SCRUM PMI
Project Management Institute

¿Qué es un proyecto?
Un proyecto es una planificación, que consiste en un conjunto de actividades a realizar
de manera articulada entre sí, con el fin de producir determinados bienes o servicios
capaces de satisfacer necesidades o resolver problemas, dentro de los límites de un
presupuesto y de un periodo de tiempo dados.
De conformidad con el Project Management Institute, "un proyecto es un esfuerzo

temporal que se lleva a cabo para crear un producto, servicio o resultado único.
PMI SCRUM
Project Management Institute Framework para gestion de productos
¿Scrum-Agile sirve para proyectos?

¿ Planificación agile ?
Planificación tradicional
• Se toman decisiones por adelantado – genera riesgos • Se sigue un Plan rigido
Planificación agile
• No se toma decisiones por adelantado – minimiza riesgos • Se planifica en ciclos cortos, buscando feedback
• Se pregunta : ¿Necesamos hacer (todo) esto ahora? • Se sigue un plan flexible

¿ Planificación agile ?

Perspectiva waterfall vs agile
FIJO
ESTIMADO
waterfall agile
Riesgo alto hasta el final Riesgo disminuye en cada etapa

¿ Cuál es mejor ?
¿A qué proyectos se puede adaptar Waterfall?

• Proyectos en los que trabajas con otras
organizaciones.
• Proyectos con un alcance, tiempo y presupuesto
fijos.
• Proyectos bien definidos y sin incertibumbre.
• Proyectos con un cliente ausente.
¿A qué proyectos se puede adaptar Agile?

• Proyectos en los que su organización es
responsable de todo el proceso.
• Proyectos con posibilidades de cambiar los
requisitos.
• Proyectos indefinidos, complejos con alta
inicertidumbre.
• Proyectos con un cliente involucrado.

¿Quienes conforman un equipo scrum?

Tribus – Chapter – Squad - Guild

Tribus – Chapter – Squad - Guild
QA Chapter

El camino a la Empresa Cognitiva
Transformación Empresa Cognitiva

Innovación
Digital 2019 en adelante
• Estado mental • Centrado en el Cliente • Basado en Plataformas

• Experimentación • Design Thinking • Impulsado por Datos
• Con Propósito • Agile • IA
• Hybrid Cloud y DevOps • Agile y nuevas aptitudes

Pareto en los proyectos
80% 20%
es lo menos usado es lo mas usado
Fuente Standish Group – Chaos Report 2002

Scrum - Rugby
ROLES de un equipo Scrum
Users
Internos/Externos
Stakeholders
Product Scrum Development

Owner Master Team

Producto Owner Responsabilidades
• Encamina el éxito del producto
• Crea la visión del producto
• Crea, actualiza y prioriza el Product Backlog
• Colabora con el equipo
• Negocia con los usuarios y clientes
• Participa en las reuniones del Sprint
Representante del negocio dentro del equipo

Product Owner
¿Qué caracteristicas tiene dentro del equipo?

Product Owner
¿Qué hace para que se cumpla el objetivo?

Product Owner
La autoridad del PO sobre el Backlog
Expresar Ordenar las HU del PB Optimizar el valor del Asegurarse de que el PB Asegurarse que el
claramente los para alcanzar las metas y trabajo que desempeña sea visible, transparente DT entienda las HU
puntos las misiones de una el DT del producto y claro para todos, y del PB al nivel
mejor manera mostrar el siguiente necesario
trabajo de equipo Scrum

Scrum Master Responsabilidades
• Remueve los impedimentos
• Sirve al Product Owner y al equipo
• Protege al equipo
• Entrena al P.O y al equipo
 Scrum y principos de agilismo
• Buscar obtener el maximo rendimiento

del equipo
• Guía al equipo
• Actuar como un agente de cambio

Facilitador, Mentor, Coach, Consultor

Scrum Master
¿Qué hace para que se cumpla el objetivo?

Scrum Master
Liderazgo sin autoridad

Development Team Responsabilidades
• Se auto-organiza y compromete como equipo
• Entregar un incremento del producto
• Administra el Sprint Backlog y rastrea el

progreso del Sprint
• Participa en las reuniones del Sprint

(Planeación, Revisión, Diaria y Retrospectiva)
Auto-organizado y empoderado.
Decide como debe hacer las tareas

Development Team
Autoridad
El equipo tiene poder para :
• Tomar cualquier decisión requerida para alcanzar el éxito.
• Solicitar cualquier recurso que necesite (incluyendo entrenamiento

adicional)

Development Team
¿Qué hacen para que se cumpla el objetivo?

¿Cuales son los
Artefactos de Scrum?
Product Backlog
Sprint Backlog
Incremento

Artefactos de Scrum

PRODUCT BACKLOG
¿Qué es un PRODUCT BACKLOG?
El Product Backlog NO ES una simple lista de tareas
“El Product Backlog es una lista de todo el trabajo

pendiente, ordenado por prioridad”.

PRODUCT BACKLOG
¿Para qué sirve el PRODUCT BACKLOG?
• Sirve para tener una perspectiva de todo lo que se quiere hacer y tener claras las
prioridades del cliente.
• Ayuda a que el equipo sea más autodisciplinado y respete las prioridades del
cliente.
• También permite que el cliente pueda introducir cambios durante la vida del
proyecto.
• Ayuda a manejar la incertidumbre durante el proyecto porque empuja a

describir con más detalle las historias más importantes..
• Es más ligero que un documento de requisitos exhaustivo.

PRODUCT BACKLOG
Priorización
• Todas las entradas del Backlog deben estar ordenadas en base a su prioridad.
• La priorización es responsabilidad del Product Owner, aunque puede contar con la ayuda del
resto del equipo Scrum.
• Factores que se tienen en cuenta para priorizar los ítems son:
o valor que aporta al cliente/negocio, tamaño, coste, dificultad o riesgo.
• El Product Owner puede decidir qué trabajo se debe hacer a continuación.

PRODUCT BACKLOG
Todas las entradas son estimadas
• Todas las entradas dentro del Product

Backlog deben estimarse con puntos
de historia
• Esta estimación se utilizar para

priorizar las entradas del Backlog y
planear las entregas (releases).

PRODUCT BACKLOG
Documento Vivo
• El Product Backlog en Scrum se modifica durante todo

el proyecto.
• Si es necesario se pueden agregar nuevas

funcionalidades y requisitos.
• Las entradas existentes pueden modificarse, definirse

con más detalle o incluso eliminarse.
• Las funcionalidades y requisitos (alcance) no están

completamente definidos desde el principio.
• Permite detectar errores en su etapa más temprana y

por tanto minimizar los riesgos

PRODUCT BACKLOG
¿Quienes Participan?: El equipo Scrum

PRODUCT BACKLOG

PRODUCT BACKLOG
Ejemplo Práctico
Objetivo : Se requiere crear un sistema que permita el registro de clases de un estudiante de la Universidad
Debe validarse
Debe mostrar Debe mostrar
en el ingreso
las materias las horarios
que el
de acuerdo a disponibles
estudiante
la carrera y el para cada
este
semestre materia
matriculado
PO
Debe permitir
Debe mostrar Debe permitir
cancelar el
las cupos el registro en
registro
disponibles el horario
previamente
para el horario deseado
realizado
Debe verificar Debe tener

Debe
que no se una
adaptarse a la
cruce los visualización ……………..
imagen de la
horarios entre previa del
Universidad
materias horario
Crear el Product Backlog
Objetivo
Se requiere organizar una boda, y se necesita determinar
cuales serian las actividades a considerar
Construya el Priorizarlas las actividades

Product Backlog del ProductBacklog

¿Qué es un
SPRINT BACKLOG?

SPRINT BACKLOG
¿Qué es un SPRINT BACKLOG?
PRODUCT
BACKLOG

SPRINT BACKLOG
¿Qué es un SPRINT BACKLOG?

Ejemplos de Tareas
Como cliente quiero ir al cine para pasar un Como deportista quiero jugar basket con mis
momento de entretenimiento amigos para siempre mantenerme en buena forma
Seleccionar el cine Coordinar el lugar
Seleccionar la película Coordinar fecha y hora
Seleccionar la hora Llamar a los que van a jugar
Comprar entradas (Virtual, Presencial) Hacer el contrato de alquiler de cancha
Transporte al cine Realizar el pago
Comprar canchita Confirmar a los amigos que participarán
Como Cliente comercial quiero una reunion de trabajo para definir los
puntos a considerar en el proyecto
Definir el lugar
Definir la hora
Elaborar los temas a tratar en la reunión
Contactar con las personas interesadas para la reunión
Recibir la confirmacion de asistencia de todos los interesados

Ejemplos de Tareas
Como usuario quiero poder logearme a la aplicación para utilizar las

funcionalidades del servicio
Crear diseño de las pantallas
Crear las bases de datos de usuarios
Validar la seguridad en las conexiones
Desarrollar el modulo de validacion de usuarios
Realizar pruebas de usuario
Realizar pruebas integrales
Solicitar la publicación de la aplicación
Validar en ambiente de producción la funcionalidad

¿Qué es el
INCREMENTO?

EL INCREMENTO
Sólo lo que esta completamente terminado agrega valor
Entregar algo, que el cliente no puede

usar, es como no haber entregado NADA.
Es mejor hacer algo pequeño, pero

TERMINADO
¿Comprarían Uds. este auto?

EL INCREMENTO

EL INCREMENTO
Historia de Usuario
Planeación
¿Terminado? No!
Redacción
¿Terminado? No! Sólo lo que esta totalmente
Aclarar dudas
terminado agrega valor
¿Terminado? No!
Desarrollo
¿Terminado? No!
Pruebas
¿Terminado? No!
Ajustes
¿Terminado? SI !!!!!!
DOD – Definition of DONE

Definición mínima de
TERMINADO
Incremento Entregable
¿Qué es
un SPRINT?

EL SPRINT
El SPRINT es un TIMEBOXED
Producto

EL SPRINT
El SPRINT es un TIMEBOXED

EL SPRINT
El SPRINT es:
Iterativo El producto se va entregando un sucesiva iteraciones.
Cada iteración se llama SPRINT.
Incremental El producto no se entrega completo.

Cada SPRINT añade algo mas de valor al sprint anterior.

EL SPRINT
El SPRINT es:
Iterativo e incremental

EL SPRINT
¿Cuánto dura un SPRINT?

EL SPRINT
¿Cómo se cumple con el objetivo del SPRINT?
Para que el equipo pueda cumplir con su compromiso el Sprint

necesita ser “bloqueado” o protegido:
• No se realizan cambios que puedan afectar al Objetivo del

Sprint (Sprint Goal);
• El alcance puede ser clarificado y renegociado entre el PO y el

DEV-Team a medida que se va aprendiendo más.
¿Qué pasa si el Sprint no está protegido y el equipo no logra enfocarse?
¿Quién puede dar por terminado el Sprint?

EL MVP

EL MVP

Tablero KAN BAN

Tablero Kanban
Este sistema fue inventado por el señor Taiichi Ohno, de Toyota.

Tablero Kanban
Tablero SCRUM - Kanban

Tablero Kanban
Tablero SCRUM - Kanban
Se puede incluir un buffer para tareas impredecibles

SPRINT BACKLOG
Kanban del Equipo de Desarrollo

SPRINT BACKLOG
Kanban de Equipo Scrum
TO DO IN PROGRESS DONE
Crear el login
a mi portal
Poder
registrar de
usuarios
Crear el login
a mi portal
Kanban del Equipo de Desarrollo
TO DO DISEÑO DESARROLLO TESTING SERVER DONE
Crear base de Diseño Script de
datos Pantalla Consulta
Configurar
Server
Accesos al
equipo
Diferencias entre Scrumban y KanBan
SCRUMBAN KANBAN
Existen los roles No existen roles.
Se trabaja con iteraciones de

Es un trabajo continuo y no maneja ciclos.
tiempo fijo (Sprints)
Limita el WIP por iteración Limitan ese WIP según el estado del flujo de trabajo
Exige equipos multidisciplinares Permiten los equipos formados por especialistas.
No se permiten cambiar las tareas del Sprint Si puede modificar la tarea hasta que entra en flujo
La pila del producto o servicio, tiene que tener al menos el Al tener un ritmo de trabajo continuo, se arrastra no tiene un
tamaño de un Sprint limite en la pila del producto o servicio
Se necesita una pila del producto priorizada No se necesita priorización.
Los tableros se van a resetear al final de cada Sprint Usa un flujo FIFO, se archiva al finalizar

HISTORIAS DE
USUARIO

HISTORIAS DE USUARIO

HISTORIAS DE
USUARIO
• Una HU es un requerimiento del producto.
• Una HU tiene un valor agregado visible para el cliente.
• Cuando se implementa una HU, se desarrolla una

nueva característica que el cliente puede usar.
• No es una descripción detallada.
• Usar una nota pequeña para mejorar el espacio.
• Esto no es una HU: “La aplicación debió ser

programada en Java”.


Modelo
INVEST
Independiente: Se pueden completar en cualquier orden.
Negociable: Los detalles de la historia son co-creados con los clientes y el team.
Valiosa: La funcionalidad es valiosa para los clientes.
Estimable: Debe tener una estimación razonable para construir la historia.
Pequeña: Las historias deberían construirse en poco tiempo.
Testeable: Se debe poder verificar que la historia funcione adecuadamente.

Como conductor
Como Cliente
Quiero poder localizar en el mapa a las
Quiero afiliar mi tarjeta de crédito
personas que tiene una emergencia
Para realizar pagos automáticos
Para poder ayudarlas

Las EPICAS
• Son HU de alta complejidad.
• Elaborarla requiere un esfuerzo muy grande y no

puede ser cubierta en un Sprint.
• Debido a su gran tamaño es difícil de estimar y lo

mejor es descomponerla en historias.
• Implementar una épica suele llevar dos o más

sprints.
Ejemplos de Épicas.
Como usuario, Como usuario

Quiero poder comprar un boleto de avión usando Quiero poder registrarme y tener una cuenta de
mi tarjeta de crédito o llevarla pre-cargadas en la usuario
aplicación Para poder acceder a mi información de usuario y
Para poder recibir un comprobante de la de los servicios que uso.
operación
¿Incertidumbre en la historia de usuario?
CASO : El cliente empresarial puede pagar sus

vuelos usando tarjeta de crédito o débito.
• Si no se ha trabajado con algo así antes ¿Qué hacemos?
A. Evitar el trabajo y moverlo para después

B. Estimar la mayor complejidad posible
C. Estimar 2 historias de usuario : Investigar cómo
hacer la historia y hacerla (spike-un mismo sprint)

Técnicas para identificar historias de usuario
• Entrevistas a usuarios • Observación
• Cuestionarios • Talleres de creación de historias de usuario

Talleres de creación de historias de usuario
• Muy recomendada
• Enfocarse en cantidad, no en calidad
• Cualquier idea es válida: descabellada ahora,

brillante después.
• Participación de todos

Talleres de creación de historias de usuario
Mi historia de usuario es mejooooorrrr

El Product Owner : La voz del Cliente
El PO : Define que historias se deben

hacer para generar valor (negociación)
• No el director de TI
• No el líder de proyectos

Objetivo : Se requiere crear un sistema que permita el Ejemplo Práctico
registro de clases de un estudiante de la Universidad
Debe validarse
Debe mostrar Debe mostrar
en el ingreso
las materias las horarios
que el
de acuerdo a disponibles
estudiante
la carrera y el para cada
este
semestre materia
matriculado
PO
Debe permitir
Debe mostrar Debe permitir
cancelar el
las cupos el registro en
registro
disponibles el horario
previamente
para el horario deseado
realizado
Debe verificar Debe tener

Debe
que no se una
adaptarse a la
cruce los visualización ……………..
imagen de la
horarios entre previa del
Universidad
materias horario

Objetivo : Se requiere crear un sistema que permita el Ejemplo Práctico
registro de clases de un estudiante de la Universidad
Debe permitir
Debecancelar
mostrarel
Debe registro
validarse Debe
las materias
en el ingreso
previamente adaptarse a la HU01 - Imagen del Sistema
de acuerdo a
que elrealizado imagen de la
la carrera y el
estudiante Universidad Como : Usuario del sistema
semestre
este
matriculado Quiero : Visualizar que el sistema se identifique con la
imagen de la Universidad
Debe mostrar
las permitir
horarios Para : Lograr pertenencia hacia la Universidad
Debe
Debe disponibles
mostrar
el registro en
para cada
laselcupos Condiciones :
horario
materia
disponibles • Colores amarillo y verde deben predominar (ver
deseado
para el horario mapa de colores)
• En la ventana de ingreso debe estar el lema de la

Universidad
Debe verificar • El encabezado debe ser similar al de la pagina (ver

Debe tener
que no se portal)
una
cruce los
visualización ……………..
horarios entre • El login del usuario debe ser visible en todo
previa del
materias momento
horario

Objetivo : Priorizar el Product Backlog Ejemplo Práctico
1
HU01 – Imagen del Sistema
2
HU04 – Horarios del sistema
3
Product Backlog
HU05 – Cruce de horarios

4
HU02 – Inscribir Materia
Como estudiante
Quiero : Registrar la materia en el

horario ………
Debe permitir
Debecancelar
mostrarel
Debe registro
validarse
las materias
en el ingreso
previamente
de acuerdo a
que elrealizado
la carrera y el
estudiante
semestre
este
matriculado
Criterios de Aceptación
• Convertir lo subjetivo en objetivo
• Definidos por el PO
• Únicos por historia de usuario

Criterios de Aceptación - Estructura
Dado (Given) : un escenario
Cuando (When): Sucede un evento
Entonces (Then) : el resultado

Criterios de Aceptación - Ejemplo
User Story : Como cliente quiero consultar el catálogo de perros en

adopción, para poder encontrar el que deseo.
Dado (Escenario)
Que el cliente esta logueado
Y cuenta con conexión a internet
Y hay perros en adopción actualmente
Cuando (Evento)
El usuario acceda al menú catálogo
Entonces (Resultado)
• Asegurar que se muestre los perros que aún no han sido adoptados
• Asegurar que se muestre 10 perros por pagina
• Asegurar que la paginación funcione correctamente

Criterios de Aceptación - Ejemplo
Historia de usuario
Como comprador del sitio web
Quiero poder pagar con una Tarjeta de Crédito
Para poder confirmar inmediatamente mi compra
Criterios de aceptación:
• Aceptar Visa, Dinners, Master Card
• Validar la fecha de expiración y el CVV
• Validar la dirección de facturación
• Generar mensaje de satisfacción y fallo luego del procesamiento
Historia de usuario
Como contador
Quiero que los reportes automatizados se ejecuten al final del mes
Para que los reportes estén listos al llegar a la oficina
Criterios de aceptación:
• Si hay un error con la generación del reporte, el sistema necesita notificar a
soporte de producción con un ticket
• El reporte necesita ser generado como PDF y autoimpreso
• El sistema debería enviar el reporte solo a la impresora configurada
• Si la impresora tiene error (falta papel, trabado, etc.) el usuario debería arreglarlo

Desarrolle el Ejercicio de
Criterios de Aceptación

Estimación - Historia en PUNTOS
• Se basa en experiencia de equipo, tanto complejidad como tamaño
• El tamaño se calcula en PUNTOS de historia, NO en tiempo
POR QUÉ?
550 Km
PUNTOS
Estimación - Analogía
¿Cuál es la complejidad necesaria para barrer el piso 1 de esta casa?
Espacio Puntos
Habitación 1 3
Habitación 2 3
Baño 1 1
Sala / Comedor 8
Cocina 5

Estimación - Planning Poker
Estimación basada en consenso

0 : Tarea demasiado fácil
5 : Algo de trabajo
13 : Medianamente complejo
40 : Complejo
100 : Modo Chuck Norris
Cuando la tarea es mayor a 40, puede ser una EPICA

Estimación - Planning Poker

Estimación - Planning Poker - Proceso
El PO explica El DevTeam debate El DevTeam vota los puntos de

la tarea sobre la complejidad historia que van a asignar, sin
mostrar la carta.
Se repite el proceso de
votación hasta que todos
están alineados y llegan a un
consenso
Todos a la vez muestran las cartas. Unos coincidiran, unos menos

Asi se evita que el valor de uno puntos y otros más puntos.
influya en la decisión de otro Optimistas y Pesimistas explican
sus razones del porqué.

¿Por qué no se estima bien una historia de usuario?
• Developers no se tiene suficiente conocimiento del negocio.
• Developers no tiene suficiente dominio técnico (SPIKE).
• La historia de usuario es muy grande.
• No consideran requerimientos no funcionales y el performance.
 (SRV, BDs, medir tiempos de respuesta, pruebas

de estrés, etc.)

Planning Poker
Estimar las siguientes actividades con esta escala de números de Fibonacci 1, 2, 3, 5, 8,

13, 21, etc. asumiendo que la tarea de referencia es lavarse los dientes con 2 puntos.

Estimación – Consideraciones en Tareas
• Muy simple : 1 hora
• Simple : 8 horas
• Medianamente compleja: 24 horas
• Complejo : 40 o más horas
Tablero de tareas Scrum


HORAS
PUNTOS

Estimación – ¿ Qué es la velocidad?
Cantidad de puntos a resolver en un sprint
Sprint 1 :
• HU 1 : 5 Puntos
• HU 2 : 8 Puntos
• HU 3 : 13 Puntos
Velocidad del sprint planeada : 26 Puntos
 Se puede mantener la velocidad.
 Se puede hacer más PUNTOS de lo planeado, entonces adopta una

nueva velocidad.

Estimación – Consistencia de velocidad
Iteraciones cortas : 2 – 4 semanas

• Buscar mantener la consistencia (en lo posible)
• Evitar iteraciones de más de 5 semanas
• De ser necesario ajustar el ritmo a una iteración de menor longitud

La multitarea
¿Es buena?
Creencia : Los que hacen multitarea son mas eficientes
Realidad: La multitarea genera trabajo de menor calidad y mayor agotamiento
Genera mucho desperdicio y hace perder dinero

La multitarea
A1 A2 A3 = A
• No genera valor Producto A
• Aumenta el time to market Producto B B1 B2 B3 = B
• No hay aprendizaje temprano del usuario

Producto C C1 C2 C3 = C
Estrategia Tradicional: “¡Todo es importante! ¡Haz todo al mismo tiempo!”
A1 B1 C1 A2 B2 C2 A3 B3 C3
Enero Febrero Marzo Abril Mayo Junio Julio
A B C
Estrategia Ágil: “¡Prioriza y concéntrate!” Pérdida de tiempo debido al

A A A B B B C C C
1 2 3 1 2 3 1 2 3
mal trabajo en multitareas
Enero Febrero Marzo Abril Mayo Junio Julio
A B C

La multitarea
Multitareas entre proyectos

La multitarea
La multitarea puede dañar las habilidades La multitarea perjudica tu rendimiento

sociales. académico.
Stanford University University of Vermont
multitarea pone tu cerebro en sobrecarga. La multitarea te interrumpe más.

University of California University of California
Los correos electrónicos y los textos La multitarea reduce su coeficiente intelectual,

dificultan el pensamiento de alto nivel. similar a fumar marihuana o quedarse despierto
microsoft toda la noche. IQ cae a la de un niño de 8 años.
University of London

Ceremonias de SCRUM

Ceremonias Scrum
Sprint Planning

Sprint Planning
PO presenta y
explica las tareas a
realizar
 El SM facilita la reunión, pero no estima.

 El PO esta presenta para resolver dudas, pero tampoco estima.
Ceremonias Scrum
Sprint Planning
Recomendación:
El panel debe ser visual
Sprint backlog

Ceremonias Scrum
Sprint Planning
• El equipo de desarrollo • Al inicio de cada Sprint • Product Backlog • ¿Qué? Meta del Sprint
• El Product Owner • Duración: 8 horas para • El último incremento del • ¿Cómo? Sprint
• El Scrum Master un Sprint de 1 mes producto Backlog
• Capacidad proyectada del
equipo de desarrollo durante
el Sprint
• Velocidad de desempeño
anterior del equipo de
desarrollo

Ceremonias Scrum
Sprint Planning
Qué El PO seleccionar los puntos del Product Backlog

que serán completados en el Sprint (la meta)
Cómo El Product Owner El equipo de desarrollo

 Define prioridades  Desglosa los puntos del PB en tareas,
 Contesta preguntas asegurando que estas se pueden
 Define cuando esta Terminado terminar en un día ideal (o menos).
 Establece la meta del Sprint basado en la
velocidad histórica.
El Scrum Master
 Facilita y asegura que el marco de
referencia Scrum sea seguido.

Ceremonias Scrum
Daily Scrum

Ceremonias Scrum
Daily Scrum
Reunión diaria, se hace de pie
 Es una reunión de sincronización entre todo el equipo de desarrollo.
 Error : Darle informes al Scrum Master, el SM es lider, no jefe.
 Scrum no tiene JEFES, solo hay ROLES y mucho trabajo en equipo.

Ceremonias Scrum
Daily Scrum
• El equipo de desarrollo • A la misma hora todos Cada miembro del equipo • Un entendimiento común
• El Scrum Master los días, es definida por responde lo siguiente: del trabajo para avanzar
(no es obligatorio) el equipo • ¿Qué hice ayer? hacia la meta.
• Duración: Máximo 15 • ¿Qué haré hoy? • Un Backlog actualizado de
minutos • ¿Veo algún impedimento? los impedimentos.

Ceremonias Scrum
Sprint Review

Ceremonias Scrum
Sprint Review
Reunión donde el Equipo de Desarrollo enseña al PO lo

que ha logrado durante el SPRINT que acaba de finalizar
 El PO da realimentación sobre lo presentado y aclara ideas.
 Este proceso iterativo se realiza en cada SPRINT
 Solo se muestran las historias 100% coompletadas
 El PO confirma que está Terminado

Ceremonias Scrum
Sprint Review
• El equipo de desarrollo • Al final de cada Sprint • Incremento • Incremento del producto

• El Product Owner • Duración: 4 horas para • Product Backlog • Velocidad (¿Qué está
• El Scrum Master un Sprint de 1 mes terminado?)
• Stakeholders • Retroalimentación
(actualización del Product
Backlog)

Ceremonias Scrum
Sprint Review

Ceremonias Scrum

Ceremonias Scrum
Sprint Retrospective

Ceremonias Scrum
Es una de las reuniones más importantes en Scrum, pues

es donde el equipo aprende de los errores y madura
 Reunión para reflexionar qué prácticas han sido exitosas, y que hay
que mantener y qué prácticas pueden mejorarse.
 Este reunión se realiza al final el SPRINT y tras haber tenido la REVIEW
 La mejora continua o kaizen, es lo que permite que el equipo

aprenda y sea cada vez más eficiente, hasta formar un equipo de alto
rendimiento.

Ceremonias Scrum
• El equipo de desarrollo • Después de la revisión • Información de los • ¿Qué salió bien?

• El Product Owner (*) del Sprint equipos acerca del • Mejoras potenciales
• El Scrum Master • Duración: 3 horas para último Sprint • Plan de mejoras
un Sprint de 1 mes

Ceremonias Scrum

Ceremonias Scrum

Ceremonias Scrum
Resumen de Ceremonias
Para sprint de 4 semanas = 1 mes
Reunión donde el equipo reflexiona Donde el equipo se compromete a lo

sobre qué cosas hay que mejorar y que que va a realizar en el siguiente Sprint
mantener que empieza.
Retrospectiva Planning
(3 horas) (8 horas)
Review Daily
Reunión donde se muestra al PO el
(4 horas) (15 min)
Reunión diaria de sincronización que
resultado, para recibir la
realiza el equipo
realimentación de Negocio y reajustar

Ceremonias Scrum
Resumen de Particiación
PO SM DT STAKEHOLDERS
PLANNING
REVIEW
RETROSPECTIVA
DAILY SCRUM
Obligatorio
Opcional
Prohibido

Tips Adicionales para ceremonias
 Si tienes algo más importante que hacer, ve y hazlo
 No se traen laptops
 Todos opinan
 Si entendiste, ahora explícalo
 El que se pica pierde
 Detalla el Problema, presenta Soluciones
 Deja la posición de Víctima - Olvida el "no es mi chamba"

Burndown Chart

Burndown Chart
50 2 3
5 8
40
Puntos de HU del Sprint
12
20
30
20
10
1 2 3 4 5 6 7 8 9 10
Días del sprint

Burndown Chart
50 12
5 8 2
3
40
20
30
20
DIA 1
10
1 2 3 4 5 6 7 8 9 10
Días del sprint

Burndown Chart
50 12
2 3
8 5
40
20
30
20
DIA 2
10
1 2 3 4 5 6 7 8 9 10
Días del sprint

Burndown Chart
50 12
2 3
8 5
40
20
30
20
DIA 3
10
1 2 3 4 5 6 7 8 9 10
Días del sprint

Burndown Chart
50 12
2 3
8 20 5
40
30
20
DIA 4
10
1 2 3 4 5 6 7 8 9 10
Días del sprint

Burndown Chart
50 3 5
8 2
20 12
40
30
20
DIA 5
10
1 2 3 4 5 6 7 8 9 10
Días del sprint

Burndown Chart
50 3 5
8 2
20 12
40
30
20
DIA 6,7
10
1 2 3 4 5 6 7 8 9 10
Días del sprint

Burndown Chart
50 3 5
2
20 12
40
30
20
DIA 8
10
1 2 3 4 5 6 7 8 9 10
Días del sprint

Burndown Chart
50 3 5
2
20 12
40
30
20
DIA 9
10
1 2 3 4 5 6 7 8 9 10
Días del sprint

Burndown Chart
50 3 5
2
12
40
8
20
30
20
DIA 10
10
1 2 3 4 5 6 7 8 9 10
Días del sprint

Burndown Chart

Burndown Chart

Burndown Chart

Visual User Story Mapping o User Story Mapping
Es una herramienta que ayuda a dimensionar la pila del producto (Product
Backlog) en tiempo (Releases) y funcionalidades (Historias de Usuario)

User Story Mapping
ROL ROL

User Story Mapping - Cliente



Algunas Herramientas Online para construir User Story Mapping
https://www.featuremap.co

http://storiesonboard.com

https://miro.com/

Herramienta KANBAN Virtuales
https://trello.com/

Herramienta Gestionar Proyectos Agile
JIRA - CONFLUENCE

Herramienta Gestionar Proyectos Agile

Ejercicio a desarrollar por equipos
Se desea crear una servicio de reserva de citas medicas en linea,
que me permita pagar con tarjetas de crédito o débito
1. Crear story mapping (Indicar los usuarios)
2. Crear las historias de usuario
3. Definir los sprints
4. Definir el primer Release
5. Crear los criterios de aceptación
6. Estimar las historias con Planning Poker

Gracias Totales

Scrum-V2 0

Cargado por

Copyright:

Formatos disponibles

Scrum-V2 0

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Scrum-V2 0

Cargado por

Copyright:

Formatos disponibles

M1 : AGILE SCRUM

• Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

moda metodología correr mas

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Agilidad Estratégica Agilidad de Portfolio Agilidad de Ejecución

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

No saber el por qué estás haciendo Scrum

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Marco de gestión Ágil

En común Depende del marco

VALORES PRINCIPOS PRÁCTICAS

Mg. Ing. Mariano Altuna

Debilidades Abrazan el cambio

Mg. Ing. Mariano Altuna

Frameworks mas utilizados

Mg. Ing. Mariano Altuna

Barreras para adoptar la agilidad

Cultura organizacional en desacuerdo con valor ágil.

Organización general de resistencia al cambio.

Soporte inadecuado de gestión y patrocinio.

Falta de habilidades / experiencia con métodos ágiles.

Procesos y prácticas inconsistentes entre equipos.

Capacitación y educación insuficientes.

Falta de disponibilidad de negocio / cliente / producto.

Persistencia en los métodos de desarrollo tradicionales.

Mg. Ing. Mariano Altuna

Como se mide el éxito

satisfacción del usuario

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

1985 - 2013 agosto de 1997

Mg. Ing. Mariano Altuna

2014 - $ 20,000 mlls.

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Top 5 habilidades blandas requeridas por las empresas el 2019

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Mg. Ing. Mariano Altuna

Contribuir a que el equipo obtenga su objetivo

Ayudar a que el equipo gane

Mg. Ing. Mariano Altuna

Que el cliente salga satisfecho

Crear las condiciones adecuadas para