# 35 puntos de presión para un equipo que cierra 20

*Caso práctico de product management · Delivery · Intermedio*

Una plataforma de RR. HH. y nóminas para pymes estilo Factorial (hipotético) tiene su sede en Barcelona y clientes en España y México. El lunes es la planning del sprint 14 del equipo de Fichaje y ausencias. Durante el fin de semana te han escrito cuatro personas por separado, cada una convencida de que lo suyo entra, y si sumas lo que piden salen 35 puntos. El equipo cierra de media 20. Todos los datos del caso son hipotéticos.

## Tu papel

Eres el Product Owner del equipo de Fichaje y ausencias: cuatro ingenieros, una QA y una diseñadora compartida con otro equipo. Los sprints duran dos semanas (diez días laborables). Llevas cinco meses en el puesto y es la primera planning en la que la presión llega de tantos lados a la vez.

## Quién opina qué

- **Account Executive de grandes cuentas**: «La cadena de restaurantes firma si en la demo del jueves de la semana que viene ve sus turnos rotativos exportados. Son 48.000 € al año. Esto entra sí o sí, y entero.»
- **Customer Success**: «El saldo de vacaciones sale mal en algunas cuentas y nos llegan 38 tickets a la semana. Si esperamos otro sprint, esto se convierte en bajas.»
- **Responsable de Cumplimiento**: «Tres clientes han pedido el informe de registro horario en el formato que piden en las inspecciones de trabajo. No quiero que un cliente nos llame un día con un inspector delante.»
- **Tech lead**: «Tres de los últimos cinco incidentes vienen de la librería de fechas. Si seguimos metiendo funcionalidades con horarios encima, el próximo incidente lo tendremos con un cliente grande. Quiero la migración entera este sprint.»

## Datos

**Los últimos seis sprints del equipo**

| Sprint | Puntos comprometidos | Puntos completados | Pasaron al sprint siguiente |
| --- | --- | --- | --- |
| 8 | 24 | 18 | 6 |
| 9 | 26 | 22 | 4 |
| 10 | 22 | 19 | 3 |
| 11 | 28 | 21 | 7 |
| 12 | 21 | 17 | 4 |
| 13 | 27 | 23 | 4 |

Datos hipotéticos. Media comprometida: 24,7 puntos. Media completada: 20. En el sprint 14, una de las cuatro ingenieras tiene dos días de vacaciones.

**Lo que te piden para el sprint 14**

| Elemento | Quién lo pide | Puntos | Lo que se sabe | Fecha que importa | Confianza en la estimación |
| --- | --- | --- | --- | --- | --- |
| Exportación de turnos rotativos | Ventas | 13 | Cliente potencial de 48.000 € al año; el equipo nunca ha exportado turnos rotativos | Demo el día 8 del sprint | Baja |
| Corregir el saldo de vacaciones | Customer Success | 5 | Afecta al 4 % de las cuentas; 38 tickets por semana | Ninguna fija | Alta |
| Informe de registro horario para inspección | Cumplimiento | 8 | Lo han pedido tres clientes; ninguno tiene una inspección abierta que se sepa | Ninguna fija | Media |
| Migrar la librería de fechas | Tech lead | 5 | Origen de 3 de los últimos 5 incidentes | Ninguna fija | Media |
| Permisos por horas (arrastre del sprint 13) | Equipo | 4 | Desarrollo terminado; falta QA y un caso límite | Ninguna fija | Alta |

Datos hipotéticos. Total: 35 puntos.

- Has hablado con la Account Executive. En la demo, el cliente quiere ver los turnos de su restaurante piloto (dos turnos, mañana y tarde, con rotación semanal) exportados al programa de nóminas que ya usa. Sus otros 39 locales tienen patrones más complejos, con turnos de noche y rotaciones quincenales, pero para firmar le basta con ver que el piloto funciona.

- El error del saldo de vacaciones aparece en cuentas con jornada parcial que cambiaron de contrato a mitad de año. No toca la nómina: es lo que ve el empleado en la app y lo que acaba preguntando a su responsable de RR. HH.

- Lo que no sabes: si los 13 puntos de la exportación aguantan, porque el equipo nunca ha hecho una; si la demo podría moverse unos días; si alguno de los tres clientes de Cumplimiento tiene una inspección con fecha; y cuánto del riesgo de la librería de fechas toca a la exportación, que trabaja justo con horarios.

## Restricciones

No hay horas extra: el equipo las hizo en el sprint 11 y la retro lo dejó por escrito. No puedes pedir gente a otros equipos este sprint. La demo es el jueves de la segunda semana (día 8 de 10). Puedes negociar el alcance con cada stakeholder, cortar historias y decidir el orden de trabajo dentro del sprint.

## Tarea

Prepara la planning: ¿qué entra en el sprint 14, con qué sprint goal, y qué le dices a cada stakeholder cuyo trabajo no entra o entra recortado?

Entregable: cinco bullets: la capacidad que usas y por qué, el sprint goal en una frase, qué entra (con el recorte si lo hay), qué no entra y cuándo se reabre, y el riesgo que vigilas durante el sprint.

## Pistas

- Mira la primera tabla columna a columna. ¿Cuál es la capacidad real del equipo: lo que suele comprometer o lo que suele terminar? ¿Qué pasa con las vacaciones?
- Antes de mirar historias, escribe el sprint goal en una frase. ¿Qué es lo único de estas dos semanas que tiene una fecha que no se mueve?
- Para la exportación, pregúntate qué necesita ver el cliente el día 8, no qué pidió Ventas. ¿Hacen falta los 13 puntos?
- Si un trabajo técnico reduce el riesgo del sprint goal, deja de ser «deuda» y pasa a ser parte del objetivo. ¿Hay algo así en la lista?

## Análisis recomendado

Empieza por la capacidad, que es un dato y no una negociación. El equipo compromete de media 24,7 puntos y termina 20: lleva seis sprints prometiendo un 25 % más de lo que entrega, y cada sprint arrastra trabajo al siguiente. Con dos días de vacaciones (38 de 40 días de ingeniería), la capacidad realista del sprint 14 ronda los 19 puntos. Comprometer 35 no es ambición: es garantizar que el sprint falle, y que falle de la peor manera, porque no eliges qué se cae. Se cae lo último que se empezó, que suele ser lo urgente.

Antes de elegir historias, decide para qué sirve el sprint. De todo lo que hay en la mesa, solo la demo tiene una fecha que no controlas y un valor que se puede poner en euros. Pero es también lo más arriesgado: 13 puntos con confianza baja en un sprint de 19. Si el sprint goal es «la exportación entera», apuestas dos tercios del sprint a una estimación que nadie ha validado.

Aquí está el movimiento clave: cortar el trabajo por lo que necesita la fecha. El cliente firma si ve funcionar su restaurante piloto, con dos turnos y rotación semanal. Ese recorte, con criterio de aceptación claro (los turnos de un mes del piloto se exportan al programa de nóminas del cliente y cuadran con el cuadrante), el equipo lo estima en 6 puntos. Las noches, las rotaciones quincenales y los 39 locales van en los sprints 15 y 16, que es cuando el cliente los necesitaría de todos modos, porque el despliegue empieza por el piloto.

Ahora mira la deuda técnica con otros ojos. La exportación trabaja con horarios, y la librería de fechas es la que provoca incidentes. Migrarla entera no cabe, pero un spike (una investigación acotada en tiempo) de 2 puntos al principio del sprint, limitado a los cálculos que usa la exportación, reduce el mayor riesgo del sprint goal. Esa parte de la deuda entra porque sirve al objetivo, no como concesión al tech lead.

Con eso el sprint queda así: exportación del piloto (6), spike de fechas para la exportación (2), corregir el saldo de vacaciones (5) y cerrar los permisos por horas (4). Son 17 de 19. El saldo de vacaciones entra aunque no sirva al objetivo: es barato, su estimación es fiable y su coste crece cada semana en tickets y confianza. Los permisos por horas están casi terminados; dejarlos otra vez fuera es pagar inventario por algo que ya hiciste. Los 2 puntos libres no se rellenan: son el margen de una estimación de confianza baja en un equipo que termina el 81 % de lo que compromete.

Queda lo que no entra, y aquí se nota el oficio. El informe de inspección (8) no tiene fecha conocida: entra el primero en el sprint 15, salvo que Cumplimiento confirme hoy que algún cliente tiene una inspección abierta, en cuyo caso cambia todo y lo dices. La migración completa va al sprint 15 con lo que aprenda el spike. Y a Ventas no le dices «no entra entero»: le dices qué verá el cliente el jueves, qué verá en las dos semanas siguientes y por qué eso es más seguro para firmar que prometer los 40 locales en ocho días.

## Decisión

Capacidad: 19 puntos (media completada de 20, menos dos días de vacaciones), comprometo 17. Sprint goal: «La cadena de restaurantes puede exportar los turnos rotativos de su local piloto a su programa de nóminas en la demo del jueves». Entra: exportación del piloto (6), spike de fechas limitado a la exportación (2, los dos primeros días), saldo de vacaciones (5) y cierre de permisos por horas (4). No entra: informe de inspección (primero del sprint 15, o antes si hay una inspección con fecha), migración completa (sprint 15, con los datos del spike) y exportación del resto de locales (sprints 15 y 16). Riesgo que vigilo: el spike; si el miércoles de la primera semana muestra que el recorte no cabe, lo hablo ese día con Ventas y con el equipo, no el viernes. Cómo sabré si acerté: sprint goal cumplido el día 8, tickets del saldo de vacaciones a cero la semana siguiente y menos de 3 puntos arrastrados al sprint 15.

## Alternativa defendible

**Mover la demo una semana y comprometer la exportación entera.** Si el cliente es estratégico (la primera cadena de hostelería, la puerta a un sector nuevo) y Ventas sabe que el cliente aceptaría ver la demo unos días más tarde, se puede pedir mover la demo al sprint 15 y dedicarle la exportación completa con una estimación ya validada por el spike. Gana una demo más completa y evita enseñar algo parcial. Cuesta credibilidad comercial (mover una fecha ya dada) y no elimina el riesgo: solo lo aplaza. Tiene sentido si el piloto solo no convence al cliente, cosa que hoy la Account Executive dice que no pasa.

## Trade-offs

- Enseñar solo el local piloto puede parecer poco si el cliente esperaba ver toda la cadena; se compensa con un plan visible para los otros 39 locales.
- Dejar 2 puntos libres parece desperdiciar capacidad, y alguien lo dirá en la planning. Es el precio de no volver a arrastrar trabajo por séptimo sprint seguido.
- Meter el saldo de vacaciones, que no sirve al sprint goal, diluye el foco; se acepta porque es pequeño, fiable y su coste crece cada semana.
- Aplazar la migración completa mantiene un riesgo de incidente dos semanas más; el spike reduce la parte que toca a la exportación, pero no la del resto del producto.

## Giro final

El miércoles de la primera semana, el spike descubre que el restaurante piloto abre hasta la 01:00 los viernes y sábados, y que la librería de fechas cuenta mal las horas de los turnos que cruzan la medianoche. El recorte de la exportación pasa de 6 a 10 puntos. El saldo de vacaciones ya está terminado.

**¿Qué haces con el sprint y con la demo?**

Lo hablo con el equipo ese mismo día. El sprint goal es la brújula: la pregunta no es cómo meter 4 puntos más, sino qué necesita la demo para ser honesta. Arreglar el cálculo de horas que cruzan la medianoche en la ruta de la exportación pasa a formar parte del objetivo.

Para que quepa, uso los 2 puntos de margen y saco del sprint el caso límite de los permisos por horas, que no tiene fecha. Si aun así no cabe, llamo a la Account Executive antes del viernes con dos opciones: enseñar el jueves la semana laborable y los fines de semana en el sprint 15, o mover la demo tres días. Lo que no hago es pedir horas extra en silencio ni llegar al jueves con una demo que falla con el turno del sábado.

Y en la retro dejo escrito el coste: la deuda de la librería de fechas nos ha costado 4 puntos de un sprint con una demo comercial en juego. Ese dato es lo que convierte la migración completa en la primera prioridad técnica del sprint 15, con algo más sólido que una opinión del tech lead.

> Se evalúa si conviertes la presión en un plan que cabe: capacidad leída en lo que el equipo termina, un sprint goal que decide qué entra, el trabajo grande cortado por lo que necesita la fecha y cada renuncia explicada con su fecha. La teoría está en cómo funciona un sprint de verdad y en qué hace realmente un Product Owner.

## Relacionado

- [Cómo funciona un sprint de verdad](https://productcasa.pro/app/aprender/sprint-de-verdad)
- [Qué hace realmente un Product Owner](https://productcasa.pro/app/aprender/product-owner-de-verdad)
- [User stories y criterios de aceptación](https://productcasa.pro/app/aprender/user-stories-criterios)
- [Priorización y sequencing](https://productcasa.pro/app/aprender/prioritization-sequencing)
- [La CEO pide una feature nueva a mitad de sprint](https://productcasa.pro/app/casos/ceo-mitad-de-sprint)

---
> Fuente: https://productcasa.pro/app/casos/sprint-35-puntos · ProductCasa, formación en product management en castellano · Actualizado: 2026-10-14