Un sprint de cero a fin

Has aprendido las piezas por separado: el marco (Scrum), la herramienta (Jira y Confluence), la realidad que las tuerce, el ownership, las soft skills y el producto. Este capítulo no añade ninguna pieza nueva: las pone a funcionar juntas en lo único que de verdad importa, un sprint real. Vamos a recorrer una semana en el equipo del Team Builder, de principio a fin, y verás cómo cada cosa que estudiaste aparece en su momento.

UNA SEMANA, DE CERO A FIN
Lunes      ─▶  Mar–Jue              ─▶  Jueves     ─▶  Viernes
Planning       Al lío + dailies         Refinement     Review + Retro
(qué y por     (trabajo, bloqueo,       (preparar el   (demo a stakeholders,
 qué entra)     PR, review)              próximo)        mejorar el proceso)

Lunes: el planning#

Empieza el sprint. En el planning, el equipo mira el backlog que el Product Owner ha priorizado y acuerda el objetivo del sprint: “que el jugador encuentre rápido al héroe que busca”. De ahí salen las historias comprometidas, entre ellas TB-42, filtrar por rol, estimada en 3 puntos. Nadie te asigna la solución técnica: el equipo se organiza y tú coges TB-42. Esto es Scrum puro —roles, objetivo, sprint backlog— del primer capítulo.

El ticket: ownership antes del código#

Abres TB-42 en Jira y la descripción es una línea floja, sin criterios. Aquí aparece el ownership: en vez de lanzarte a programar, dejas el ticket trabajable. Defines qué es “hecho”, piensas los bordes (¿un rol sin héroes?, ¿el roster aún sin cargar?) y le preguntas al PO lo que falta. Le pones criterios de aceptación verificables y una Definition of Done. Es el capítulo de la suite Atlassian (el ticket) y el de ownership, juntos: el trabajo de dueño que ahorra el retrabajo de después.

Martes a jueves: al lío, con un bloqueo#

Programas. Cada mañana, la daily: ayer, hoy, bloqueos —corta, para el equipo, no un parte para el jefe—. El miércoles te atascas: necesitas que backend confirme si el rol llega en mayúsculas o minúsculas. En vez de quedarte botando en silencio (lo que haría que el problema explotara el último día), lo sacas pronto y bien escrito: a quién se lo pides, qué necesitas y qué haces mientras para no pararte. Ahí están la realidad (el bloqueo que no se esconde) y las soft skills (comunicarlo de forma accionable).

El Pull Request y la review#

Terminas y abres el Pull Request con una descripción de verdad: qué cambia, por qué y cómo probarlo. Pasa a “In Review” —que no es “Done”: espera a que alguien lo mire—. Un compañero te deja un comentario marcado como “nit”, concreto y respetuoso. Lo recibes bien: lo valoras, no te lo tomas como un ataque, y ajustas. Soft skills de nuevo, en su forma más cotidiana: el code review que suma en vez de restar.

Sin perder de vista la métrica#

Mientras construyes, no se te olvida el porqué. Sabes que el objetivo del trimestre es que más gente complete su equipo, y que este filtro ataca justo el momento en que el jugador busca “qué me falta”. Eso te hace elegir, ante dos formas de hacerlo, la que deja el filtro fácil de descubrir y usar: la que moverá la métrica leading que vigiláis. Es el capítulo de producto metido en una decisión técnica pequeña.

Viernes: review y retro#

En la sprint review enseñas el filtro funcionando con datos reales a los stakeholders, y lo conectas con el objetivo: no es “un filtro”, es “ayudar a completar equipos”. Recoges su feedback. Después, la retrospectiva: el equipo mira cómo trabajó y sale con una acción concreta —“los criterios de aceptación se escriben en el refinement, no en el planning”— con dueño y para revisar la próxima vez. Cierra el círculo de Scrum, y el lunes vuelve a empezar.

Lo que has hecho sin darte cuenta#

Repasa la semana y mira de qué capítulo salió cada momento:

Planning, objetivo, roles ........... Scrum y sus ceremonias
El ticket, el tablero, In Review .... La suite Atlassian
El bloqueo que no se esconde ........ La bofetada de realidad
Aclarar el "done", el bloqueo ....... Ownership
El PR, la daily, recibir el review .. Soft skills
Elegir mirando la métrica, la demo .. Entender el producto y el negocio

Ninguna de estas cosas, por sí sola, es difícil. Lo que distingue a alguien que trabaja bien en un equipo es hacerlas todas a la vez y sin fisuras, de forma que las piezas encajen: que lo que promete el ticket sea lo que prueba el PR y lo que enseñas en la demo. Eso es, al final, de lo que iba este nivel entero.

Comprueba lo que sabes#

Este es el examen del nivel: más largo y exigente que los quizzes de cada capítulo, y con preguntas que cruzan varios temas a la vez, como en el trabajo real. Repasa Scrum, Jira, la realidad, el ownership, las soft skills y el producto de una sola pasada.

Tu turno#

El ejercicio de cierre junta todo el nivel en los artefactos de un sprint: el ticket, el PR, la daily y la nota de demo de la feature de filtros, coherentes entre sí. Hazlo tú y compáralo con las soluciones, que suben de “cuatro piezas sueltas” a “un paquete que cuenta una sola historia”.

git clone <repo>
cd exercises/nivel-12/un-sprint-de-cero-a-fin
# abre index.html en el navegador y edita solucion.js

# Ticket

Filtrar por rol. Que se pueda filtrar el roster.

# PR

Título: filtro. Hecho el filtro de roles.

# Daily

Ayer con el filtro, hoy sigo. Todo bien.

# Demo

Enseño el filtro.

# Ticket — TB-42 · Filtrar el roster por rol

Como jugador que arma un equipo
quiero filtrar el roster por rol (tanque, daño o soporte)
para ver solo los héroes de la posición que me falta.

Criterios de aceptación:
- Tres filtros: Tanque, Daño, Soporte.
- Al activar uno, solo se ven los héroes de ese rol.
- Al desactivarlo, vuelven todos.

Estimación: 3 puntos.

# PR — Filtrar el roster por rol

Añade tres filtros al roster. Al activar un rol, la lista muestra solo sus héroes.

Cómo probar: abrir el roster, pulsar "Tanque", ver solo tanques.

# Daily

Ayer cerré la UI del filtro. Hoy enchufo la lógica. Estoy esperando a backend para
saber cómo llega el rol.

# Demo

Enseño el filtro funcionando con datos reales y cómo deja ver solo una posición.

# 1. Ticket — TB-42 · Filtrar el roster por rol

**Epic:** Filtros y búsqueda del roster · **Estimación:** 3 pts · **Estado:** To Do

**Descripción**
Como jugador que arma un equipo
quiero filtrar el roster por rol (tanque, daño o soporte)
para ver solo los héroes de la posición que me falta por cubrir.

**Criterios de aceptación**
- Tres filtros visibles: Tanque, Daño, Soporte.
- Al activar un rol, la lista muestra solo sus héroes e indica cuántos hay.
- Al desactivarlo, vuelve el roster completo.
- Si un rol no tiene héroes: "No hay héroes de este rol".
- Si el roster aún no ha cargado: filtros deshabilitados, no rotos.

**Definition of Done:** tests del filtrado y los dos casos límite, revisado por un
compañero, accesible por teclado.

# 2. Pull Request — Filtrar el roster por rol

**Qué:** tres filtros de rol; uno activo a la vez; muestra el contador por rol.
**Por qué:** primera historia del epic de filtros; ayuda a completar equipos (OKR del
trimestre).
**Cómo probar:** abrir el roster → "Tanque" → solo tanques + contador → desactivar →
vuelven todos. Caso límite: filtrar un rol sin héroes muestra el aviso.
Cubierto con tests, incluidos los casos límite.

# 3. Daily (miércoles)

- **Ayer:** UI de los filtros con sus tests.
- **Hoy:** conecto la lógica de filtrado y abro el PR.
- **Bloqueo:** necesito que backend confirme si el campo `rol` llega en mayúsculas o
  minúsculas (afecta a la comparación). Se lo he pedido a Luis por el canal del
  equipo; mientras, avanzo con los tests para no quedarme parado.

# 4. Nota para la demo

Enseño el filtro funcionando con el roster real: activar "Soporte" y ver al instante
solo los soportes con su contador, y el aviso cuando un rol está vacío. Lo conecto con
el objetivo del trimestre: queremos que más gente complete su equipo, y este filtro
ataca justo el momento en que el jugador busca "qué me falta". Métrica que vigilaré:
el uso del filtro en la primera sesión (leading) como señal temprana de retención.