---
name: azure-sprint-planning
description: Descompone PBIs de Azure Boards en tareas estimadas con dependencias y orden de ejecución, y comprueba si el sprint cabe. Úsala en la planificación de sprint, al partir un PBI grande o cuando preguntes qué hay que hacer para cerrar un item.
version: 1.0.0
license: CC-BY-4.0
updated: 2026-08-16
---

# Azure Boards: planificar a partir de los PBIs

Planificar es responder a dos preguntas: **qué hay que hacer para cerrar esto**
y **cabe todo esto**. Cualquier otra cosa es decorar el tablero.

## 1. Descomponer un PBI en tareas

Se parte de los criterios de aceptación. Si no los hay, no se planifica: se
refina primero (ver `azure-pbi-authoring`).

Una tarea es una unidad de **medio día a dos días** para una persona. Menos es
microgestión; más es una tarea que esconde una incógnita.

Esqueleto de descomposición, adaptado a lo que el PBI toque de verdad:

```
[ ] Modelo y migración            0.5 d
[ ] Lógica de aplicación           1 d
[ ] Endpoint y contrato            0.5 d
[ ] Interfaz                       1 d
[ ] Pruebas del caso vacío y límite 0.5 d
[ ] Telemetría o log del camino nuevo 0.25 d
[ ] Notas de despliegue y feature flag  0.25 d
```

Las tres últimas son las que siempre se olvidan y las que revientan la
estimación. Si el equipo no las hace, quítalas del esqueleto en vez de
fingir que se hacen gratis.

**Spikes**: cuando una tarea no se puede estimar porque falta información, no
se estima al alza. Se crea un spike con caja de tiempo fija ("2 días para
decidir si usamos Service Bus o tabla de outbox") y una pregunta concreta que
responder. Un spike sin pregunta escrita se convierte en una semana perdida.

## 2. Dependencias y orden

Marca cada tarea con lo que necesita antes de poder empezar:

- **Interna**: otra tarea del mismo PBI. Solo condiciona el orden.
- **Entre PBIs**: enlace `Predecessor`/`Successor` en Azure Boards, no un
  comentario en la descripción. Los comentarios no salen en ningún informe.
- **Externa**: credenciales del cliente, una API de terceros, una ventana de
  mantenimiento, la decisión de alguien. **Son las que hunden sprints**, y la
  única mitigación es empezarlas el día 1 aunque el desarrollo vaya después.

El orden propuesto pone primero lo que **elimina incertidumbre** (spikes,
dependencias externas, la parte del sistema que nadie conoce), no lo que es
más cómodo de programar.

## 3. ¿Cabe el sprint?

```
Capacidad = personas × días hábiles × factor de dedicación
```

El factor de dedicación no es 1. Con soporte, reuniones y revisiones de PR,
0,6–0,7 es realista para un equipo de producto. Si el equipo también atiende
incidencias de producción, reserva un porcentaje fijo **antes** de repartir, no
después.

Y contrasta contra la **velocidad de los últimos 3 sprints**, no contra la
capacidad teórica. La velocidad ya incluye todo lo que la capacidad ignora.

Cuando no cabe, la salida nunca es "apretamos". Se presentan las opciones:

1. Sacar el PBI de menor valor.
2. Recortar alcance de uno concreto (y decir qué se queda fuera).
3. Aceptar el riesgo por escrito, con el item marcado como candidato a caer.

## 4. Crear las tareas

```bash
az boards work-item create \
  --title "Migración: columna export_format en Orders" \
  --type Task --iteration "Proyecto\\Sprint 43" \
  --fields "Microsoft.VSTS.Scheduling.RemainingWork=4"

az boards work-item relation add \
  --id <tarea> --relation-type parent --target-id <PBI>
```

`RemainingWork` va en **horas**; los `StoryPoints`/`Effort` del PBI padre, en
puntos. Mezclarlos rompe la capacidad del sprint y los gráficos de burndown.

Antes de crear nada, enseña la descomposición y espera el visto bueno: veinte
tareas creadas de golpe que no encajan con lo que el equipo tenía en la cabeza
cuestan más de borrar que de escribir.

## Señales de que la planificación está mal

- Todas las tareas duran exactamente lo mismo → nadie las ha pensado.
- Ninguna tarea de pruebas → o no se prueban, o el tiempo está escondido.
- El sprint suma justo la capacidad al 100% → no hay margen para lo imprevisto,
  y lo imprevisto ocurre todos los sprints.
- Un PBI con una sola tarea llamada igual que el PBI → no se ha descompuesto.