¿Qué es el Método de Priorización Debe Debería Podría No Hará?
Nuestras acciones deben expresar nuestras prioridades, y Debe Debería Podría No Hará es una excelente plantilla de retrospectiva de sprint para ayudar a los equipos a identificar esas prioridades para asegurar que continúen entregando valor donde más se necesita. Con esto en mente, es un enfoque que se alinea bien con los procesos y marcos ágiles dado su enfoque en la entrega de cosas valiosas primero. También es una gran idea para retrospectivas de sprint Scrum ya que ofrece al dueño del producto un mecanismo para ponerse en los zapatos de su cliente y ver el producto desde su perspectiva. Desarrollado en los años 90 por Dai Clegg, el método MSCW ganó prominencia en la gestión de proyectos ágiles y análisis de negocio. Proporciona una forma estructurada de organizar tareas en cuatro categorías distintas: Debe tener (crítico), Debería tener (importante), Podría tener (deseado), y No tendrá (no prioritario). La fortaleza de MSCW radica en su simplicidad y efectividad para facilitar discusiones grupales sobre prioridades. Al categorizar elementos en estos cuatro grupos, los equipos pueden alinear mejor sus esfuerzos con objetivos estratégicos, gestionar recursos eficientemente y mantener una comunicación clara sobre lo que se entregará y lo que no.
Formato Debe Debería Podría No Hará
Debe
Cosas que definitivamente debemos hacer.
Estos son requisitos no negociables que son críticos para el éxito. Al discutir elementos 'Debe', anime a los participantes a considerar verdaderos bloqueadores o elementos esenciales sin los cuales el proyecto fracasaría. Desafíe al equipo a ser estricto sobre lo que califica como 'Debe' para evitar la inflación de prioridades.
Debería
Cosas que deberíamos hacer.
Estas son características o requisitos importantes que agregan valor significativo pero no son críticos para el lanzamiento. Guíe al equipo a considerar elementos que serían dolorosos de omitir pero que no impedirían el funcionamiento del proyecto. Enfóquese en elementos de alto valor pero menor urgencia.
Podría
Cosas que podríamos hacer.
Estas son características deseables que sería bueno tener si los recursos lo permiten. Ayude al equipo a identificar mejoras que mejorarían la solución pero no son esenciales. Estos elementos a menudo son buenos candidatos para futuras iteraciones o lanzamientos.
No Hará
Cosas que no haremos.
Estos son elementos explícitamente decididos en contra para esta iteración o proyecto. Fomente una discusión honesta sobre características que, aunque potencialmente valiosas, no se alinean con los objetivos o restricciones actuales. Esto ayuda a mantener el enfoque y gestionar expectativas.
Cuándo utilizar esta retrospectiva
- Al planificar un nuevo proyecto o iniciativa y necesitar establecer prioridades claras
- Durante sesiones de refinamiento del backlog para organizar y priorizar solicitudes de características
- Cuando se enfrentan restricciones de recursos y se necesitan tomar decisiones difíciles sobre el alcance
- En reuniones con interesados para alinear expectativas sobre entregables y cronogramas
Preguntas rompehielos sugeridas
- ¿Cuál ha sido la decisión de priorización más difícil que has tenido que tomar en un proyecto?
- Si solo pudieras entregar tres características en tu proyecto actual, ¿cuáles serían y por qué?
Ideas y consejos para su reunión retrospectiva
- Limitar los elementos 'Debe' a no más del 60% del total de requisitos para mantener un alcance realista
- Revisar y actualizar las categorizaciones periódicamente según cambien las necesidades y restricciones del negocio
- Usar timeboxing durante las discusiones para asegurar la toma de decisiones eficiente
- Documentar el razonamiento detrás de las categorizaciones para mantener la claridad y consistencia
- Involucrar a todos los interesados clave en el proceso de priorización para asegurar el compromiso
- Considerar las dependencias entre elementos al asignar categorías
Nuevo en las retrospectivas? Lea nuestra guía sobre cómo llevar a cabo una retrospectiva →