Product Backlog y técnica MoSCoW para priorización ágil
Contenido del curso
Jorge Bernaola
Julián Darío Bermúdez Trujillo
Angela María García Tangarife
Profesor
Paula Andrea Pérez Espitia
Angela María García Tangarife
Profesor
Gustavo Enrique Córdova Rodriguez
Paula Andrea Pérez Espitia
Ixcoatl Francisco Pérez
Ixcoatl Francisco Pérez
Ixcoatl Francisco Pérez
Paula Andrea Pérez Espitia
Paula Andrea Pérez Espitia
Paula Andrea Pérez Espitia
Andres Bernal
José David Calderón Serrano
Condor Agency
ORLANDO ERNESTO ARBAIZA AVILES
ORLANDO ERNESTO ARBAIZA AVILES
Izael Ruelas Garcia
Platzi Team
Diego Mauricio Zuluaga Rodríguez
Existe alguna otra técnica para usar cuando el cliente es de esos clientes que dice que todo es debe estar, todo es prioritario, todo es ya? y que aún cuando le has dado a entender que hay que priorizar y que no todo se puede al tiempo, es insistente con eso?
Hola Julián, Existen muchas técnicas de priorización que le pueden ayudar a un PO a definir que es lo que realmente se requiere para solucionar el problema del cliente. Muchas veces solo pensamos ¿que es lo que necesita el negocio?, pero pocas veces pensamos ¿qué es lo que necesita el usuario? (el que va a usar el producto). Hay que educar al PO y precisamente trabajar en su mindset y cuestionarlos con este tipo de pregunta. Adicional, hacerlo consciente de que entre más nos demoremos en liberar producto o servicio funcional (porque querer hacer todo va a requerir más esfuerzo), más nos demoramos en recibir: 1. Feedback del usuario (esto es realmente lo que se quería?) 2. Retorno de inversión Muchas veces cuando hablamos de costos, presupuesto y time to market, estos PO cada vez serán más consciente de que la solución no es entregar todo, es lo que nos generé retorno y feedback. Te dejo este enlace a otras técnicas: 20 Product Prioritization Techniques: A Map and Guided Tour | Briefings | career.pm
Gracias por compartir el reto
El reto está mla puesto. Lo colocaron antes de explicarlo. Está como 1 minuto adelantado
Sí, es cierto. Corresponde a esta información con relación al ejercicio de creación de aplicación de aprendizaje de idiomas:
El product backlog es una lista emergente y ordenada de todo lo necesario para crear el producto o servicio. Su gestión es responsabilidad del *product owner*. Este artefacto nunca está terminado: evoluciona a medida que aprendemos del producto y del mercado.
El refinamiento descompone los elementos del product backlog en partes más pequeñas, concisas y detalladas. No es un evento de Scrum, sino una actividad continua durante el sprint.
No se puede construir todo al mismo tiempo. La técnica MoSCoW ayuda a clasificar según importancia para tomar decisiones informadas y visibles para todos.
¿Qué significan Must have, Should have, Could have y won’t have?
Dado el caso de negocio Salud Tech:
i. ¿Qué elementos identificas que hagan parte del product backlog?
Requerimientos de negocio
ii. ¿Cómo priorizarías el Product Backlog con la técnica MoSCow?
Permitir el registro e inicio de sesión seguro (pacientes y médicos)
Configurar mi disponibilidad horaria para citas (médico)
Ver el calendario de disponibilidad de los médicos (paciente)
Solicitar y agendar una nueva cita (paciente)
Reprogramar una cita desde la aplicación (paciente)
Cancelar una cita desde la aplicación (paciente)
Ver un historial de citas agendadas (paciente)
Ver un listado de todos mis pacientes (médico)
Ver un historial de las citas médicas pasadas (paciente)
Módulo de facturación y pagos (médico)
Pagar una cita (paciente)
Generar fórmula con medicamentos (médico)
Permitir el envío de documentos y resultados de laboratorio de forma segura (paciente a médico)
Enviar fórmula con medicamentos por correo (paciente)
Implementar un dashboard con métricas de adherencia al tratamiento (paciente)
Recibir confirmación de la cita y recordatorios (paciente y médico)
Habilitar un chat bidireccional simple para consultas rápidas (paciente-médico)
h. Dado tu Proyecto personal:
i. ¿Qué elementos identificas que hagan parte del product backlog?
Requerimientos de negocio
Un juego plataformero de aventura multijugador
Interactuar con personajes
Posibilidad de que sea interactivo
Con configuración de idioma para multilenguaje
ii. ¿Cómo priorizarías el Product Backlog con la técnica MoSCow?
Los requerimientos del juego
Una historia (lore)
Creación de personajes (sprites)
Diseño de mundo y elementos (mas sprites)
Mecánicas de movilidad
Elaboración de niveles
Interacciones con personajes
Desarrollo de sonido y cinemáticas
Desarrollo de cooperatividad
Portabilidad a diferentes plataformas
Caso de estudio Salud Tech. Técnica MoSCow
Product Backlog (De acuerdo con el caso SaludTech)
Basado en el caso de estudio, los elementos que integran el backlog serían:
MoSCow: Caso de estudio SaludTech
¿Qué proceso se puede seguir, para priorizar una funcionalidad entre las clasificaciones de la tecnica MoSCoW?
¿Se utiliza el expertis del Product Owner o se realiza una votación con el equipo de desarrolladores?
.Product Backlog – Técnica MoSCoW
🔴 MUST HAVE (Imprescindible)
1.1 Gestión de Usuarios
1.2 Agenda y Citas
1.3 Atención Médica Virtual
1.4 Historia Clínica Electrónica (HCE)
1.5 Seguridad y Cumplimiento
1.6 Notificaciones Básicas
🟠 SHOULD HAVE (Muy importante, pero no bloqueante)
2.1 Escalamiento a Cita Presencial
2.2 Especialidades Médicas
2.3 Gestión Médica Avanzada
2.4 Experiencia del Usuario
2.5 Pagos (si aplica al modelo)
🟡 COULD HAVE (Deseable)
.1 Inteligencia y Automatización
3.2 Analítica y Seguimiento
3.3 Experiencia Premium
3.4 Multiplataforma
⚪ WON’T HAVE (Por ahora no)
Diagnóstico automatizado por IA (sin médico)
Clase 17 – Product Backlog y Priorización MoSCoW
g. CASO SALUD TECH
i. Elementos del Product Backlog
Funcionalidades de Negocio (17 identificadas): 1. Registro e inicio de sesión seguro (pacientes y médicos) 2. Ver historial de citas médicas pasadas (paciente) 3. Ver historial de citas agendadas (paciente) 4. Ver calendario de disponibilidad de médicos (paciente) 5. Solicitar y agendar nueva cita (paciente) 6. Reprogramar cita desde la aplicación (paciente) 7. Recibir confirmación de cita y recordatorios (paciente y médico) 8. Cancelar cita desde la aplicación (paciente) 9. Pagar cita (paciente) 10. Generar fórmula con medicamentos (médico) 11. Enviar fórmula con medicamentos por correo (paciente) 12. Ver listado de todos mis pacientes (médico) 13. Configurar disponibilidad horaria para citas (médico) 14. Implementar dashboard con métricas de adherencia al tratamiento (paciente) 15. Permitir envío de documentos y resultados de laboratorio (paciente a médico) 16. Habilitar chat bidireccional simple (paciente-médico) 17. Módulo de facturación y pagos (médico)
Requisitos Técnicos (ítems no funcionales):
18. Integrar sistema de notificaciones push 19. Integración con sistema de historiales clínicos del hospital 20. Performance: Cargar citas en <3 segundos 21. Disponibilidad: Uptime 99.9% 22. Escalabilidad: Soportar 5.000 usuarios concurrentes 23. Auditabilidad: Registrar accesos y modificaciones 24. Usabilidad: 95% de usuarios navegan sin tutoriales 25. Localización: Español e inglés 26. Tolerancia a fallos: Consistencia ante caídas
Deuda Técnica y Criterios de Equipo:
27. Implementar CI/CD pipeline automático 28. Configurar test automation (unitarios, regresión) 29. Refactorizar código a Clean Code 30. Documentar API interna
ii. Priorización MoSCoW
MUST HAVE (Mínimo indispensable para MVP en 3 meses): - #1 Registro/login seguro - #4 Ver disponibilidad médicos - #5 Solicitar/agendar cita - #7 Confirmación y recordatorios - #8 Cancelar cita - #12 Ver listado pacientes (médico) - #13 Configurar disponibilidad (médico) - #18 Notificaciones push - #20 Performance <3s - #23 Auditabilidad (obligatorio legal) - #24 Usabilidad 95% (crítico adopción) - #27 CI/CD (sin esto no hay velocidad sostenible)
SHOULD HAVE (Alto valor, se agregan post-MVP):
- #2 Ver historial pasado - #3 Ver historial agendado - #6 Reprogramar cita - #9 Pagar cita - #14 Dashboard adherencia - #15 Enviar documentos - #19 Integración historiales clínicos - #26 Tolerancia a fallos
COULD HAVE (Nice-to-have, si sobra tiempo):
- #11 Enviar fórmula por correo - #16 Chat bidireccional - #17 Módulo facturación - #25 Localización inglés (fase beta solo español)
WON'T HAVE (Fuera de scope del Product Goal actual):
- #10 Generar fórmula (requiere validación médica compleja) - #21 Uptime 99.9% (sobreingeniería para 100 usuarios) - #28 Test automation completo (se construye iterativamente)
---
h. PROYECTO PERSONAL – APP "FINZ"
i. Elementos del Product Backlog
Core (Gestión de Portfolio): 1. Conectar cuenta de broker (API o scraping) 2. Ver portfolio actual (valor, ganancia/pérdida) 3. Ver detalle por activo (acción, ETF) 4. Añadir transacción manual 5. Editar transacción 6. Eliminar transacción 7. Recibir alerta si activo cae >X% 8. Dashboard de rentabilidad vs índice de referencia
Meta Libertad Financiera (Diferenciador):
9. Establecer meta de libertad financiera (monto objetivo) 10. Proyección de tiempo hasta meta según rendimiento 11. Checklist de milestones (ej: "Ahorrar 6 meses de gastos") 12. Tips educativos semanales 13. Calculadora de interés compuesto 14. Simulador de aportes periódicos
Técnicos y UX:
15. Registro/login con email 16. Sincronización en la nube 17. Exportar datos a CSV 18. Performance: Cargar portfolio en <2s 19. Seguridad: Encriptar datos sensibles 20. Manejo de errores de API de bolsa 21. Modo oscuro 22. Responsive (móvil primero)
ii. Priorización MoSCoW
MUST HAVE (MVP funcional en 1 mes):
- #1 Conectar broker - #2 Ver portfolio actual - #3 Ver detalle por activo - #4 Añadir transacción manual - #18 Performance <2s - #20 Manejo errores API (sin esto la app se rompe) - #15 Registro/login (persistencia mínima)
SHOULD HAVE (Añade valor y diferenciación):
- #7 Alertas de caída - #9 Meta libertad financiera - #10 Proyección tiempo hasta meta (core del pitch) - #16 Sincronización nube - #19 Encriptar datos
COULD HAVE (Mejora experiencia):
- #5 Editar transacción - #6 Eliminar transacción - #8 Dashboard vs índice - #21 Modo oscuro - #17 Exportar CSV
WON'T HAVE (Fase 2 o posterior):
- #11 Checklist milestones (requiere contenido educativo) - #12 Tips educativos (no es tecnología, es contenido) - #13 Calculadora interés compuesto (puede hacerse manual) - #14 Simulador aportes (complejidad adicional) - #22 Responsive web (focarse solo en móvil inicial)
