SCRUM

Es una de las Metodologías ágiles de gestión de proyectos.

Manifiesto ágil
Es un set de valores y principios, que están presentes en todas las
metodologías ágiles, en donde los requisitos y las soluciones
evolucionan con el tiempo según la necesidad del proyecto y su
entorno.

12 principios ágiles
1. Nuestra mayor prioridad es satisfacer al cliente mediante la
entrega temprana y continua de productos y servicios
valiosos. ¡La prioridad es el cliente! En metodologías
tradicionales, el cliente no es la prioridad, la prioridad es el
producto, puesto que se interactúa con el cliente cuando se
entregan los requerimientos y cuando se le entrega el producto
ya desarrollado. Las entregas son tardías en las metodologías
tradicionales.
2. Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan el
cambio para proporcionar ventaja competitiva al cliente. El
pensamiento es “Que los cambios realizados serán mejor para
el cliente”.
3. Entregamos resultados para los clientes
frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
4. Los clientes y equipos de trabajo trabajamos juntos de
forma cotidiana durante todo el proyecto. A diferencia de
la metodología tradicional que hay muy poca interacción con el
cliente.
5. Los proyectos se desarrollan en torno a individuos
motivados. Los individuos en el proyecto tienen que estar
motivados, trabajar en un entorno cómodo y recibir el apoyo
que se necesiten, y que se les confíe la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar
información al equipo de trabajo y entre sus miembros
es la conversación CARA A CARA (reuniones, ya sea
presencial o virtual).
7. Los resultados entregados son la medida principal de
progresos (LOS INCREMENTOS)
8. Los procesos ágiles promueven el desarrollo sostenible,
es decir, TODOS DEBEN TRABAJAR A UN MISMO RITMO
CONSTANTE, no puede haber momentos en los que el ritmo
aumente o disminuya. Este principio hace referencia a que el
trabajo en proyectos Ágiles debe ser sostenible a largo
plazo, es decir, no debe depender de esfuerzos extremos como
horas extras constantes, presión excesiva o picos de trabajo
que desgasten al equipo.
9. La atención continua a la excelencia y al buen diseño
mejora la agilidad.
10. La simplicidad, o el arte de maximizar la cantidad
de trabajo no realizado, es esencial. Menos, es más.
Hacer solo lo necesario o lo importante, bien hecho, y dejar el
resto, o lo menos importante, para después (o nunca, si no se
necesita).
Eso es maximizar el trabajo no realizado, y es clave para
mantener la agilidad.
11. Las mejores arquitecturas, requisitos y diseños
emergen de equipos autoorganizados. El equipo que
trabaja en el desarrollo son equipos autogestionados,
autoorganizados, ellos mismos deciden como organizarse,
separarse las tareas, etc.
12. A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.
Regularmente, el equipo se reúne para conversar sobre lo que
ocurrió en cuestiones de desarrollo y equipo.
A TODOS ESTOS PRINCIPIOS ÁGILES SE LE AGREGAN ESTOS 3
PILARES QUE AYUDAN EN ESTA METODOLOGÍA:

TRANSPARENCIA:
Hacer visible la información deliberadamente (Voluntario,
intencionado, hecho a propósito). Es decir, cuanto uno sabe del
trabajo que hay que realizar, que problemas está teniendo, si puede
responder a la tarea asignada, si hay algún problema en el grupo que
me afecte.

INSPECCIÓN:
Poder analizar que ocurre en el desarrollo, los problemas, avances,
etc. La transparencia habilita la inspección. Tanto la evolución del
producto como las mejoras en el proceso de creación deben ser
inspeccionados de forma frecuente.

ADAPTACIÓN:
Gracias a la inspección (La inspección habilita la adaptación) se
descubre que el producto se está desviando de su objetivo o el
proceso está saliendo de ciertos límites tolerables, se deberá tomar
decisiones de adaptación.

TODO ESTO ES O RELACIONADO AL PRODUCTO O AL INDIVIDUO QUE

ESTÁ PARTICIPANDO EN EL DESARROLLO.

VALORES PROPIOS DE LAS PERSONAS

QUE PARTICIPARAN EN EL PROYECTO:
COMPROMISO: El equipo Scrum se compromete a lograr sus objetivos
y apoyarse entre ellos.

FOCO: El foco principal del equipo Scrum está puesto en el trabajo del
Sprint (período de tiempo para realizar algunos requerimientos del
proyecto) actual para lograr el mayor progreso posible hacia el
objetivo. NO SE PIENSA EN EL FUTURO, EN LOS PROBLEMAS QUE SE
PUEDE LLEGAR A TENER EN EL FUTURO.

FRANQUEZA: El equipo Scrum y los interesados muestran franqueza

con respecto al trabajo y a los desafíos.

RESPETO: Los miembros del Equipo Scrum se respetan entre sí como

personas capaces e independientes y son respetados como tales por
las personas con quienes ellos trabajan.

CORAJE: Los miembros del Equipo Scrum tienen el coraje de hacer lo

correcto y de trabajar en problemas difíciles.

De todo esto, si no me acuerdo algo míralo en la clase 2 pero se

entiende, lo que voy a aclarar es el “Value-based Priorization”. Se
refiere a ordenar los requerimientos por prioridad en el producto
backlog, esta priorización la define el cliente, el stakeholder.
Porque el sabe que es lo que necesita, a que requerimientos
les va a dar más valor. TODO ESTO SE LO COMUNICA AL “Product
Owner”.
Product Owner: Es la persona que está conectado con el cliente
para ver qué es lo quiere, el cliente le dice el producto que requiere,
sus necesidades y la priorización de los requerimientos. El Product
Owner escucha al cliente, y cuando se define el listado de
requerimientos (EL PRODUCT BACKLOG) el Product Owner es el que le
proporciona la priorización de requerimientos al Development Team.

Tambien se encarga del Release Management (Manejo de la Entrega).

Básicamente cuando el incremento ya se desarrolló y hay que
entregarlo al stakeholder, el Product Owner es el que realiza la
reunión, la presentación y entrega del mismo.
ScrumMaster: Es el que está custodiando que esta metodología no
pierda su forma. Ya sea porque las personas no trabajan fluidas, o no
se realizan las reuniones, etc.

Development Team: El equipo de desarrollo, no es que solo sean

desarrolladores es el nombre que se le asigna en esta metodología,
puede haber diseñadores, testers, etc. A partir de ese Product
Backlog, ellos mismos analizan como realizarán el trabajo, como se
dividirán las tareas, etc.
Scrum define al proceso de desarrollo en eventos llamados Sprint, es
un seteo, caja, período de tiempo. Dentro de este período ocurren
todos los otros eventos, que veremos a continuación. Los Sprint son
secuenciales, termina uno y rápidamente inicia el siguiente. Todo lo
que pasa dentro de un desarrollo pasa en un Sprint, en uno o en el
siguiente.

Dentro del Sprint hay diferentes eventos, reuniones que nos aseguran
que se cumpla correctamente la metodología de Scrum, estas son:
Sprint Planning: La Planificación del PRÓXIMO SPRINT QUE VA A
INICIAR. Es decir, se realiza al inicio del Sprint que se va a realizar
ahora. (normalmente). Esto se realiza en una reunión CARA A CARA.

Daily Scrum: REUNIÓN DIARIA DURANTE TODO EL PERÍODO DEL

SPRINT. (SI EL SPRINT DURA 2 SEMANAS, SE REALIZA 10 VECES, POR
EJEMPLO). ¿PARA QUE SIRVE ESTA REUNIÓN? Para hablar sobre lo que
se realizó en el día anterior, los problemas que tuvieron en el día
anterior, y lo que se va a realizar en el día actual. Por eso los daily
scrum se realizan normalmente a la mañana.

Sprint Review: Reunión al final del Sprint.

Retrospective: Para pensar la forma de trabajo del equipo, que

cosas se pueden mejorar, que funcionó bien que mal, si hay una
mejor forma de trabajar.

Refinement: Reunión para analizar el Product Backlog, puesto

que los requerimientos son muy generales, son requerimientos muy
MACROS, por lo que el objetivo de esta reunión es refinarlos. Se
redefinen los requerimientos, se detallan más esos requerimientos,
“se hacen más finitos”. De los mismos requerimientos Macros salen
requerimientos más pequeños para alcanzar ese requerimiento
Macro. Además de esto, a los requerimientos MACROS se les
define el tamaño, el esfuerzo que se requiere para su
realización. Para así tener una noción de cuánto tardará en
desarrollar ese requerimiento.

Luego de tener el listado de los requerimientos desglosados, en el

Sprint Planning lo observan y se reparten las tareas.
SPRINT BACKLOG: Del Product Backlog, el stakeholder prioriza sus
requerimientos y el Product Owner lo escucha y lo hace repensar
sobre algunas decisiones si hace falta, de ahí nace el listado de los
requerimientos a desarrollar en el Sprint, es decir nace el Sprint
Backlog. Los requerimientos que van al Sprint Backlog, se quitan del
Product Backlog.

¿SABIENDO ESTO, CUANTAS REUNIONES HAY EN POR EJEMPLO

EN UN SPRINT DE 2 SEMANAS?

1 = Sprint Planning

10 = daily Scrum

1 = Sprint Review

1 = Retrospective

1 = Refinement
En Scrum, los artefactos son los elementos clave que se usan
para planificar, hacer seguimiento y entregar el trabajo.
Representan el trabajo que se está haciendo, el trabajo ya
hecho y el trabajo que falta.
EL PRODUCT BACKLOG A TRAVÉS DEL TIEMPO, COMO EVOLUCIONA,
SE VA DETALLANDO LOS REQUERIMIENTOS QUE SE NECESITA, EN
BASE A LAS NECESIDADES DEL STAKEHOLDER QUE CHARLÓ CON EL
PRODUCT OWNER.

Es decir, A LO LARGO DEL TIEMPO, los requerimientos necesarios para

cumplir las necesidades del stakeholder pasan de ser menos
detallados (menos específicos) a ser más detallados (más
específicos). Los requerimientos se desglosan hasta un punto en el
que se cree que se pueden llegar a desarrollar en un Sprint. Si la
tarea dura más que un Sprint, esa tarea debería ser DESAGREGADA
(SEPARADA) en dos tareas, por ejemplo. Hay requerimientos que
nunca se refinan ya sea porque no se tomaron más en cuenta o capaz
cambien, por ejemplo, el de la última fila.

ACLARACIÓN: el refinamiento es, DETALLAR LOS REQUERIMIENTOS

QUE SE NECESITAN + DARLES UNA PONDERACIÓN, DARLES UN
TAMAÑO A LOS REQUERIMIENTOS.
METODOLOGÍA DE DOCUMENTACIÓN (USER
STORIES)

En esta metodología de DOCUMENTACIÓN, el requerimiento MACRO

se denominará una EPIC (o Epopeya).

Cuando ese requerimiento se empieza a desglosar (se le hace “doble

clic”) se empieza a hablar de FEATURE O THEME.

Cuando a ese FEATURE O THEME, se le hace “doble clic” se empieza a

hablar de tareas SPRINTABLE (tarea que puede ser implementable en
un Sprint). Obviamente esta tarea está compuesta de varias tareas
que hay que realizar.

Tanto las EPIC, FEATURE O LAS SPRINTABLE (que las vamos a declarar
como User Stories), tienen la misma forma de documentarse. Por
medio de una TARJETA (CARD).
Lo que se está analizando ahora es como van a estar documentados
los requerimientos para cuando llegue la hora de distribuirse las
tareas.
Este requerimiento es EPIC, es muy MACRO. Al hacer doble clic
saldrán tareas de tipo THEME:

A este mismo, se le puede hacer doble clic, para poder ver todas las
user stories (Sprintable) que se necesitan para poder realizar
correctamente este requerimiento.

Entonces:
De los Epic, desagregamos y pasamos a los Feature o Theme,
desagregamos y pasamos a los User Story.

EJEMPLO MAS CLARO:

Los Criterios de Aceptación son los que controlaran el funcionamiento
correcto del desarrollo. Que no se acepte tales cosas, que el material
tenga que ser de un tipo en específico. TODAS LAS TARJETAS
DEBERIAN TENER CRITERIOS DE ACEPTACIÓN, PARA AYUDAR AL
DESARROLLADOR Y TAMBIEN AL TESTER PARA QUE PUEDA TESTEAR
CORRECTAMENTE ESA FUNCIONALIDAD.
En esta tarjeta nos está faltando información ¿Cuál ES EL ALGORITMO
DEL DR.X?

Esa información faltante se agrega abajo como una nota, esta nota se
la denomina “CONVERSATION”. En esta sección se pueden anotar
directamente la información o poner la fuente donde encontrar esa
información. ESTA SECCIÓN NO ES OBLIGATORIA.
CUANDO SE REALIZAN USER STORY, HAY QUE PENSAR COMO SE
GENERAN. Hay que pensar características que deben tener para que
estén correctamente hechas.

Para eso EXISTE “INVEST”

Independiente: Cada User Story no tiene que depender de otra, si

ocurre eso está mal generada

Negociable: Puede ser cambiable por el cliente.

Valioso: Tiene que entregar valor al cliente.

Estimable: Se tiene que saber cuanto tiempo va a tomar

desarrrollarlo

Pequeño

Probable: Que sea Testeable.

RESUMEN DE LO VISTO

En esta imagen se habla de las 3 C´S, CARD – CONVERSATION –

CONFIRMATION (CRITERIOS DE CONFIRMACIÓN, DE ACEPTACIÓN, ES
LO MISMO).

Y también se habla de las características que deberían tener los

Criterios de aceptación.

Específicos - Medibles – Logrables – Orientado a un resultado – Que

esté seteado en un período de tiempo para cumplirla.

RECORDAR…
DUDA

En la metodología Scrum, los eventos ocurren de manera cíclica

dentro de cada Sprint. A continuación, te indico el orden
cronológico típico de los eventos dentro de un Sprint:

✅ 1. Sprint Planning (Planificación del Sprint)

 ¿Cuándo ocurre? Al inicio del Sprint.

 ¿Para qué sirve? El equipo define qué se va a hacer

(objetivo del Sprint) y cómo se va a hacer.

 Duración: Máx. 8 horas para Sprints de 1 mes

(proporcionalmente menos si el Sprint es más corto).

✅ 2. Daily Scrum (Scrum Diario)

 ¿Cuándo ocurre? Todos los días del Sprint, en el mismo

horario y lugar.

 ¿Para qué sirve? Para que el equipo sincronice actividades,

comparta avances, obstáculos y planifique las próximas 24
horas.

 Duración: 15 minutos.

✅ 3. Refinement (Refinamiento del Backlog)

 ¿Cuándo ocurre? Varias veces durante el Sprint, no tiene un

momento fijo, pero suele hacerse 1 o 2 veces por semana.

 ¿Para qué sirve? Se revisan y detallan los ítems del Product

Backlog para que estén listos para futuros Sprints.

 Duración: Flexible (no debe superar el 10% del tiempo del

Sprint).

✅ 4. Sprint Review (Revisión del Sprint)

 ¿Cuándo ocurre? Al final del Sprint.

 ¿Para qué sirve? Se muestra lo que se logró, se recoge

feedback de los stakeholders y se adaptan futuros Backlogs.

 Duración: Máx. 4 horas para Sprints de 1 mes.

✅ 5. Sprint Retrospective (Retrospectiva del Sprint)

 ¿Cuándo ocurre? Justo después de la Sprint Review, y antes

del siguiente Sprint Planning.

 ¿Para qué sirve? El equipo reflexiona sobre cómo trabajó y

propone mejoras para el próximo Sprint.

 Duración: Máx. 3 horas para Sprints de 1 mes.

📌 En resumen, el orden cronológico sería:

1. Sprint Planning

2. (Durante todo el Sprint): Daily Scrum

3. (Durante el Sprint): Refinement

4. Sprint Review

5. Sprint Retrospective
🔄 Sprint Review vs. Sprint
Retrospective
✅ Sprint Review (Revisión del Sprint)

 Tipo de evento: Evento colaborativo con stakeholders.

 Participan:

o Equipo Scrum completo (Developers, Scrum Master,

Product Owner)

o Stakeholders (clientes, usuarios, interesados externos)

 ¿Para qué sirve?

o Mostrar el incremento del producto (lo que se

completó).

o Obtener feedback externo.

o Adaptar el Product Backlog si es necesario.

 Es más externo, orientado al producto.

✅ Sprint Retrospective (Retrospectiva del Sprint)

 Tipo de evento: Evento interno del equipo Scrum.

 Participan:

o Solo el equipo Scrum (Developers, Scrum Master, Product

Owner).

 ¿Para qué sirve?

o Reflexionar sobre el proceso de trabajo.

o Identificar qué funcionó, qué no, y cómo mejorar.

 Es más interno, orientado al proceso y al equipo.

🧠 En resumen:

Sprint Review = mostrar y recibir feedback (con externos)

Sprint Retrospective = mejorar cómo trabajamos (entre
nosotros)