Introducción Scrum

Agenda
● Manifiesto ágil ● MVP
● Principios ● Historias de usuario
● Pilares ● Las 3 “C”
● Valores de un equipo Scrum ● Criterio INVEST
● Elementos de Scrum (“3-5-3”) ● Estimación
● Roles ● Definition of ready
● Ceremonias ● Definition of done
● Artefactos
 Personas e interacciones sobre procesos y herramientas: Por supuesto que los
procesos ayudan al trabajo. Las herramientas mejoran la eficiencia, pero hay tareas
que requieren talento y necesitan personas que lo aporten y trabajen con una
actitud adecuada. La defensa de los procesos lleva a afirmar que con ellos se
pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es

Manifiesto ágil
que este principio no es cierto cuando se necesita creatividad e innovación.

Producto funcionando sobre documentación extensiva: El manifiesto ágil no da

por inútil la documentación, sólo la de la documentación innecesaria. Los
documentos son soporte de hechos, permiten la transferencia del conocimiento,
registran información histórica, y en muchas cuestiones legales o normativas son
obligatorios, pero su relevancia debe ser mucho menor que el producto final. La
comunicación a través de documentos no ofrece la riqueza y generación de valor
que logra la comunicación directa entre las personas, y a través de la interacción
con prototipos del producto.
.
Colaboración con el cliente sobre negociación contractual: El objetivo de un
proyecto ágil no es controlar la ejecución conforme a procesos y cumplimiento de
planes, sino proporcionar el mayor valor posible al producto. Resulta por tanto
más adecuada una relación de implicación y colaboración continua con el cliente,
más que una contractual de delimitación de responsabilidades.

Respuesta al cambio sobre seguir un plan: Para desarrollar productos de

requisitos inestables, que tienen como factor inherente el cambio y la evolución
rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la
de seguimiento y aseguramiento de planes. Los principales valores de la gestión
ágil son la anticipación y la adaptación, diferentes a los de la gestión de proyectos
ortodoxa: planificación y control que evite desviaciones del plan.
 Principios
Nuestra mayor prioridad es satisfacer al
cliente mediante la entrega temprana y
continua de software con valor.
Aceptamos que los requisitos cambien,
incluso en etapas tardías del desarrollo.
Los procesos Ágiles aprovechan el cambio
para proporcionar ventaja competitiva al
cliente.
Entregamos software funcional
frecuentemente, entre dos semanas y
dos meses, con preferencia al periodo de
tiempo más corto posible.
Los responsables de negocio y los
desarrolladores trabajamos juntos
de forma cotidiana durante todo el
proyecto.

Los proyectos se desarrollan en
torno a individuos motivados. Hay
que darles el entorno y el apoyo
que necesitan, y confiarles la
ejecución del trabajo.
El método más eficiente y
efectivo de comunicar
información al equipo de
desarrollo y entre sus miembros
es la conversación cara a cara.
El software funcionando es la medida
principal de progreso.
Los procesos Ágiles promueven el
desarrollo sostenible. Los
promotores, desarrolladores y
usuarios debemos ser capaces de
mantener un ritmo constante de
forma indefinida.

A intervalos regulares el equipo reflexiona

La atención continua a la La simplicidad, o el arte de Las mejores arquitecturas, sobre cómo ser más efectivo para a
excelencia técnica y al buen maximizar la cantidad de trabajo requisitos y diseños emergen continuación ajustar y perfeccionar su
diseño mejora la Agilidad. no realizado, es esencial. de equipos auto-organizados. comportamiento en consecuencia.
Pilares
Transparencia: Para poder tomar las mejores decisiones necesitamos
que todos los aspectos claves del proceso y del progreso (con respecto al
producto que estamos construyendo) sean visibles por todos.
No debe haber información difícil de acceder, decisiones difíciles de
explicar. Todo debe de estar al “alcance de la mano”.

Inspección: En Scrum se promueven revisiones permanentes de los

Artefactos y del progreso para identificar y corregir las variaciones.

Adaptación: Es la ejecución de aquellos cambios que permitan

implementar mejoras para la siguiente fase de desarrollo y el cumplimiento
de los objetivos proyectados, mientras se reducen las fallas.
Valores de un equipo Scrum
Coraje: Tanto el equipo Scrum y los
Stakeholders asumen retos y toman el coraje de
hacerlo de la manera correcta (no hay atajos a la
calidad posible)

Foco: Todo el equipo Scrum esta enfocado en

realizar el trabajo en un Sprint

Compromiso: El equipo scrum se compromete

a lograr ciertos objetivos de la creación del
producto

Respeto: Todos nos respetamos y nos

reconocemos como personas con capacidad e
independencia

Apertura: Estamos todos abiertos a aceptar

feedback para mejorar
Elementos de Scrum (“3-5-3”)
 Product Owner
Es la persona responsable de maximizar el valor del
producto resultante del trabajo del equipo de desarrollo,

Roles asegurándose de proveer una visión de lo que desea

construir a todo el equipo.

Scrum Master
Es la persona responsable de promover y enseñar los
principios y valores de scrum a través de un tipo de
liderazgo servicial.

Equipo de desarrollo
Es un conjunto de personas multidisciplinarias,
autoorganizadas y multifuncionales que comparten un
mismo objetivo, tienen una responsabilidad compartida y
son capaces de entregar un incremento de producto al final
de cada sprint.
 Revisión del sprint (4)
Revisar el trabajo realizado. Repasar temas que no han podido ser
finalizados y cuales fueron sus principales obstáculos.
Se puede convocar a stakeholders, con el objetivo de mostrar los
Refinamiento (3) resultados del sprint y recibir feedback

Ceremonias Alimentar el Product Backlog.

Anticipación y planeación de futuros
sprints. Lograr una visión del trabajo
a realizar en ~ 2-3 sprints.
Retrospectiva (5)
Reflexión final del sprint para identificar puntos de mejora.
“Mantener lo bueno, deshacerse de lo malo"

Incremento Lanzamiento de
SPRINT potencial incremento

Timebox de trabajo
Sprint planning (1) definido
Acordar con el PO lo que se
construirá en el Sprint.
Finalizada la ceremonia, queda
conformado el Sprint Backlog

Daily / sincro (2)

24 hs Revisión diaria de como viene el Sprint.
(Temas trabajados, principales impedimentos, etc)
 Product Backlog
Compuesto por todas las características del producto
que queremos construir y encuentra priorizado por valor

Artefactos de negocio. Es un artefacto “vivo”.

Sprint Backlog
Se compone luego de cada Sprint Planning.
Contiene las características comprometidas para el Sprint.
No debe ser modificable durante el Sprint.

Incremento de Producto
Es la suma de todas las características del producto
comprometidas en el Sprint pero funcionando e integradas a
los incrementos de producto pasados.
Se presenta en la Sprint Review y se inspecciona para
obtener feedback. Para esto, debe estar terminado,
funcionando y potencialmente entregable
MVP
● Es una versión parcial de un producto orientada a
descubrir rápidamente qué pide el cliente, empleando para
Minimum Viable Product ello el menor esfuerzo posible
(mínimo producto viable) ● Es la versión mínima de un nuevo producto, la cual permite
recoger una gran cantidad de feedback

OBJETIVOS

● Evitar la creación de un producto que nadie quiere.

● Maximizar el aprendizaje respecto a los clientes por cada
peso invertido (es decir, que la empresa no se quede sin
recursos económicos).
● Conseguir pruebas y evidencias antes de que sea
demasiado tarde para el emprendedor.
 ● Son descripciones, siempre muy cortas y esquemáticas,
que resumen la necesidad concreta de un usuario al utilizar

Historias de usuario un producto o servicio, así como la solución que la

satisface.

● Suelen escribirse de la siguiente manera:

COMO [tipo de usuario] -> ¿quién?
QUIERO [necesidad] -> ¿qué?
PARA [beneficio esperado] -> ¿para qué?
:
● Representan pequeños incrementos de funcionalidad,
deben poder ser finalizadas en pocos días

Mejores prácticas

● 3C’s
● INVEST
 CONFIRMATION Toda historia de usuario debe tener
una conversación con el Product Owner. Una
comunicación cara a cara que intercambia no solo
información sino también pensamientos, opiniones y
sentimientos

Las 3 “C”
CARD Toda historia de usuario debe poder
describirse en una ficha de papel pequeña.
Si una Historia de Usuario no puede
describirse en ese tamaño, es una señal de
que estamos traspasando las fronteras y
comunicando demasiada información que
debería compartirse cara a cara.

CONVERSATION Toda historia de usuario

debe estar lo suficientemente explicada
para que el equipo de desarrollo sepa qué
es lo que debe construir y qué es lo que el
Product Owner espera. Esto se conoce
también como Criterios de Aceptación.
 La historia de usuario debe
permanecer independiente y no
depender de otras, ya que las
dependencias comprometen la
Criterio INVEST planificación.

El contenido de las historias de

usuario es adaptable mientras no
se hayan incluido en el sprint.
La historia de usuario debe
aportar valor al cliente.

Es importante que la historia tenga el

tamaño adecuado para poder estimar
el esfuerzo que nos va a llevar
implementarla.
La historia de usuario debe
poder finalizarse en un
sprint.

Se espera que el Product Owner no

solo pueda describir la funcionalidad
que necesita, sino que también logre
verificarla.
 ● Estimamos para saber con cuentas “cosas” (HdU)
se puede comprometer un equipo durante un Sprint
Estimación ● Estimamos en Esfuerzo (utilizando una unidad de
medida llamada Story Points)

● Story Points: “Unidad de estimación para expresar el

esfuerzo relativo que le implica a un equipo llevar
una HdU a Done”
● Cuando hablamos de ”relativo”, queremos decir que
los valores asignados por sí solos no significan nada,
lo que importa es la relación con los demás.

Por ejemplo,
“una historia de 3 puntos implica tres veces más
esfuerzo que una historia de 1 punto”.
Definition of ready Es el conjunto de características que una Historia de Usuario
debe cumplir para que el Equipo de Desarrollo pueda
comprometerse a su entrega, es decir, incluirla en un Sprint
Backlog.

Una típica definición de listo podría ser:

• La Historia de Usuario debe ser INVEST
• Todos sus pre-requisitos están resueltos (ej: dependencias con
otros Equipos)
Definition of done Es el conjunto de características que una Historia de Usuario debe
cumplir para que el equipo de desarrollo pueda determinar si ha
terminado de trabajar en ella.

Un típico criterio de “Terminado” podría ser:

• Todos los criterios de aceptación funcionan correctamente
• Todos los archivos fuentes están en el repositorio de código fuente y el
build se ejecutó exitosamente
• En el caso de Product Owners muy exigentes: El PO dio su visto bueno
de la funcionalidad construida antes de llegar a la Review Meeting.
¡Muchas gracias!