Bienvenidos
Scrum Master
PATRONES
CORE DE SCRUM
3 ROLES 5 EVENTOS 3 ARTEFACTOS
http://scrumbook.org/
5 EVENTOS
SPRINT
El Sprint corresponde al bloque de tiempo
(entre 1 a 8 semanas) durante el cual se crea
un incremento de producto “Terminado”,
utilizable y potencialmente desplegable.
Cada nuevo Sprint comienza inmediatamente
después de la finalización del Sprint previo.
EVENTOS
1 a 8 semanas
SPRINT PLANNING
Descripción: El trabajo a realizar durante el Sprint se planifica en la
Sprint Planning. Este plan se crea mediante el trabajo colaborativo del
Equipo Scrum completo.
Que me llevo: Definir qué puede entregarse en el Incremento resultante
del Sprint que comienza y cómo se conseguirá hacer el trabajo
necesario para entregar el Incremento.
Objetivo del evento: Definición del objetivo y predicción del sprint
(Pronóstico).
Cuando ocurre: Al inicio del sprint
Cuánto demora: 8 horas máximo(sprint 1 mes)
EVENTOS Quienes participan: Equipo scrum
DAILY MEETING
Descripción: Reunión que busca sincronizar las actividades y el plan del
equipo de desarrollo para las siguientes 24 horas.
Que me llevo: Una actualización de lo que el equipo está haciendo para
lograr el objetivo del sprint.
Visibilizar los impedimentos que no se hayan conversado por otra vía.
Objetivo del evento: Que el equipo realice una planeación diaria en pro
de conseguir el objetivo del Sprint.
Cuando ocurre: Diariamente
Cuánto demora: 15 minutos máximo.
EVENTOS Quienes participan: Development Team como mínimo.
SPRINT REVIEW
Descripción: Es una reunión informal, no de seguimiento, donde
mediante la presentación del incremento, se busca facilitar la
retroalimentación y la colaboración.
Que me llevo: Feedback de los stakeholders
Objetivo del evento:
1.Inspeccionar el incremento.
2.Recolectar el feedback obtenido en la reunión para adaptar el
Product Backlog si fuese necesario.
3.Facilitar la retroalimentación de información y fomentar la
colaboración.
Cuando ocurre: Al finalizar el sprint
Cuánto demora: 4 horas máximo(sprint 1 mes)
EVENTOS Quienes participan: Equipo scrum, stakeholders.
SPRINT RETROSPECTIVE
Descripción: La Retrospectiva del Sprint es una oportunidad para el
Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de
mejoras que sean abordadas durante el siguiente Sprint
El Scrum Master se asegura de que la reunión sea positiva y
productiva.
Que me llevo: Plan de acción de mejoras.
Objetivo del evento:
1.Inspeccionar/Reflexionar el proceso realizado en el sprint.
2.Generar un plan de mejora para el siguiente sprint.
Cuando ocurre: Al finalizar del sprint
Cuánto demora: 3 horas máximo (sprint 1 mes)
EVENTOS Quienes participan: Equipo scrum
REFINAMIENTO
Descripción: Presentar las próximas Product Backlog Items
(PBIs) al equipo que van a entrar tanto para el siguiente sprint
como para los 2 o tres próximos y discutir aspectos sobre ellos,
como los insumos, riesgos y dependencias.
Que me llevo: PBIs refinados. Entendimiento de los PBIs a
tomar en los próximos sprints.
Objetivo del evento: Generar entendimiento de los PBIs del
Product Backlog por parte del equipo scrum y refinarlas según
corresponda.
Cuando ocurre: Durante el Sprint.
Cuánto demora: No más del 10% de la capacidad del equipo
EVENTOS Quienes participan: Equipo scrum
3 ARTEFACTOS
PRODUCT BACKLOG
El Product Backlog contiene un listado de ítems (Product Backlog
Items, PBIs) o características del producto a construir.
El Product Owner es el responsable del listado de características
del producto, incluyendo, disponibilidad y ordenación.
ARTEFACTOS
Los ítems están organizados
por prioridad, en la parte
superior se encuentran los más
prioritarios.
SPRINT BACKLOG
Es el conjunto de elementos del Product Backlog seleccionados para el
Sprint.
Es un PRONÓSTICO hecho por el Equipo de Desarrollo acerca de qué
funcionalidad formará parte del próximo Incremento y del trabajo
necesario para entregar esa funcionalidad en un Incremento
“Terminado”.
Para asegurar el mejoramiento continuo, la Lista de Pendientes del
Sprint incluye al menos una mejora de procesos de alta prioridad
identificada en la Retrospectiva inmediatamente anterior.
ARTEFACTOS
INCREMENTO DE PRODUCTO
El Incremento es la suma de todos los
elementos de la Lista de Producto
completados durante un Sprint y el valor
de los incrementos de todos los Sprints
anteriores. El incremento debe estar en
condiciones de utilizarse sin importar si el
Dueño de Producto decide liberarlo o no.
ARTEFACTOS
DEFINITION OF READY *
DoR Corresponde al conjunto de
características que debe cumplir un PBI
para que el equipo de desarrollo pueda
comprometerse en su entrega, es decir,
incluirla en un Sprint Backlog
ARTEFACTOS
DEFINITION OF DONE*
DoD Cuando un elemento de la Lista de Producto o
un Incremento se describe como “Terminado”, todo
el mundo debe entender lo que significa
“Terminado”.
Aunque esto varía significativamente para cada
Equipo Scrum, los miembros del Equipo deben tener
un entendimiento compartido de lo que significa que
el trabajo esté completado, para asegurar la
transparencia
ARTEFACTOS
¿Qué son las User Stories?
Historias de usuario
y cada funcionalidad tiene que Bien, la historia es esta:
No puedo entregarte todas O me haces todas las
tener lo que llamamos “historia
estas funcionalidades en la funcionalidades que pido o
de usuario”
primera versión arruinaré tu vida!
En agilidad las historias de usuario son el reemplazo escrito de los
requerimientos de usuario, se escriben en el lenguaje propio de
los usuarios y describen que debería “construir” y “entregar” el
equipo de desarrollo.
Son una invitación a una conversación y no una descripción
extensiva.
(Valoramos las personas y sus interacciones por sobre los procesos y
las herramientas, el software funcionando por sobre la
documentación extensiva)
Buenas historias de usuario
Las 3C
Card
Conversation
Confirmation
Las HU deben ser cortas, caber en una tarjeta de
fichero. Contiene el título, la descripción y los
criterios de aceptación.
Debe contener:
● Título corto HU
Card
● Descripción
● Criterios de aceptación
¿Título corto?
Título corto: Verbo + complemento
Eliminar usuario Detalles de usuario
inactivo
Carro de compras
Cambiar contraseña
Configuración de
Publicar post usuario
Formato de descripción ¿Qué preguntas responder?
¿Quién? Como . Rol
¿Qué? Quiero . Necesidad
¿Para qué? Para . Valor
Algunos ejemplos de descripción
Como usuario registrado Como visitante web
Quiero cambiar mi contraseña Quiero suscribirme a la lista
de difusión
Para mantener mi cuenta
segura Para recibir novedades por
email
Como usuario móvil Como administrador
Quiero grabar todos mis datos Quiero desactivar un usuario
en la nube
Para prevenir accesos no
Para acceder desde otros autorizados de ex empleados
dispositivos
Una historia de usuario no es un reemplazo de un
documento de requisitos, es un disparador para
tener una conversación con las personas
pertinentes, cuando sea necesario, sobre los
requisitos. De hecho, la idea es tener una
colaboración continua con el cliente a través de
conversaciones.
Conversation
Finalmente, la historia de usuario ayuda al equipo
a discutir con el propietario del producto cómo
determinar cuándo una característica / pieza de
trabajo está completa.
Para la confirmación se utilizan generalmente
Confirmation criterios de aceptación.
Concepto INVEST
INVEST
Independent
Negotiable
Valuable
Estimable
Small sized
Testable
¿Qué es un criterio de aceptación (CA)?
Son enunciados que se describen desde el
punto de vista del usuario/product owner
cuándo una historia se puede considerar hecha
y correctamente implementada.
DoD Vs CA
Definición de terminado (DoD) Criterios de aceptación (CA)
Sirve para desambiguar el entendimiento de Sirve para clarificar requerimientos del negocio
que debe hacerse antes de declarar cualquier / condiciones que se deben cumplir para
PBI hecho y completo satisfacer al usuario en un requerimiento dado
Se aplica por igual a todos los PBI Aplica a un único PBI
Pertenece al equipo, es entendido y acordado Es propiedad del Product Owner, el equipo de
por todo el equipo Scrum desarrollo lo entiende
No cambia frecuentemente, no debería cambiar Son negociables entre el Product Owner y el
durante el Sprint equipo de desarrollo
Cumplir con el DoD debe implicar cumplir con Su cumplimiento no implica cumplir con el DoD
el CA
Definición de épica
Una épica es una historia de usuario muy grande. No en
términos de descripción, sino en términos de
implementación. Una épica es una historia que puede llevar
más de un sprint para completar. Puede darse porque:
● Una historia puede estar a un nivel muy alto y necesita
más información.
● Simplemente que la historia terminó siendo más grande
ÉPICA
de lo que inicialmente se pensó, y por lo tanto no se
puede completar en un sprint.
Estimación de historias
El principal objetivo de este tipo de
estimación, es utilizar técnicas de
asociación donde prima lo subjetivo
en un entorno en el que un grupo de
personas deberán ponerse de
acuerdo frente a algo específico y
complejo.
Se estima con respecto al Pivote
Quién debe estimar
•
En el modelo de estimación por esfuerzo no es el Cliente
o el Product Owner quienes estiman en solitario, la
estimación la debe hacer quien se va a “meter en
faena”, es decir quienes definen el cómo lo hacen...y lo
hacen (Dev Team).
•
De esta forma conseguimos: Reforzar la responsabilidad
de todo el equipo respecto a los compromisos adquiridos,
hacemos que todos se sientan escuchados y que podemos
aterrizar la estimación a algo más acertado.
Técnicas de estimación
Planning poker
Es una tecnica que permite hacer una estimación inicial
rápida y segura del proyecto, puesto que todos los
miembros del equipo comparten en “cada mano” sus
diferentes informaciones y expresan su opinión.
Cada número significa un peso /complejidad / esfuerzo
necesarios para completar una historia de usuario.
La numeración de las cartas está basada en la sucesión de
Fibonacci, en la que la distancia entre los números crece a
medida que estos se hacen mayores.
Tallas de camiseta
Ejemplo
