Sprint, releases, MVP/MMP y calidad
El Product Owner participa en Sprint Planning, valida incrementos, lidera aprendizaje con Sprint Review, planifica releases y balancea entrega de valor con deuda tecnica y Definition of Done.
PO durante Sprint y Review
El PO colabora en Sprint Planning para explicar valor y prioridades, aclara criterios durante el Sprint y usa Sprint Review para inspeccionar el incremento con stakeholders y adaptar el Product Backlog.
- Developers deciden cuanto trabajo tomar.
- El PO no baja calidad para meter mas alcance.
- La Review no es solo demo; es inspeccion colaborativa.
MVP, MMP y releases
Un MVP permite aprender con funcionalidad minima; un MMP ya es comercializable. Release Management planifica y controla entregas incrementales alineadas con vision, calidad y expectativas.
- Sprints construyen incrementos.
- Releases agrupan valor entregable.
- MVP busca aprendizaje; MMP busca mercado.
Calidad, DoD y deuda tecnica
La Definition of Done transparenta que esta terminado. La deuda tecnica reduce velocidad, aumenta costo, baja calidad y eleva riesgo de entrega. El PO debe considerar trabajo tecnico que proteja sostenibilidad del producto.
- La DoD no se negocia hacia abajo para cerrar alcance.
- Metricas de release incluyen lead time, cycle time y frecuencia.
- Calidad tambien maximiza valor.
Términos clave
Objetivos de aprendizaje
- PO-6.1.1 · K1Recordar participacion del PO en Sprint
El PO explica valor, aclara criterios, valida aprendizaje y colabora en Review y Planning.
- PO-6.2.1 · K2Explicar MVP, MMP y release management
MVP aprende con lo minimo viable; MMP es comercializable; releases entregan valor incremental.
- PO-6.3.1 · K2Describir Definition of Done y deuda tecnica
DoD transparenta calidad; deuda tecnica afecta velocidad, costo, calidad y riesgo.
- PO-6.4.1 · K3Aplicar metricas de release y decisiones de calidad
Lead time, cycle time y frecuencia de release ayudan a gestionar flujo y entrega de valor.
Errores frecuentes
- Aceptar trabajo no terminado para complacer una fecha.
- Confundir MVP con producto pobre o incompleto sin aprendizaje.
- Ignorar deuda tecnica porque no aparece en demos.
- Usar Sprint Review como aprobacion tardia.
Ejemplos aplicados
- Si un incremento no cumple DoD, no debe considerarse terminado.
- Un MVP de onboarding puede validar activacion antes de construir todos los modulos del producto.