The whole file
This is exactly what you download: no summaries, nothing trimmed.
Heads-up: the skill file itself is written in Spanish. Agents read it fine and answer in your language, but the prose below is not translated.
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/Successoren 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:
- Sacar el PBI de menor valor.
- Recortar alcance de uno concreto (y decir qué se queda fuera).
- Aceptar el riesgo por escrito, con el item marcado como candidato a caer.
4. Crear las tareas
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.