¿Cuáles son los diferentes enfoques y con qué frecuencia priorizar el trabajo pendiente? [cerrado]

¿Cuáles son los diferentes aspectos de un PBI (elementos de la cartera de productos) o, en términos generales, las características que tendría en cuenta para priorizar la cartera de pedidos? riesgo, ROI, tiempo de comercialización, costo de demora, a discreción del PO, etc.

¿Consideraría una combinación o incluso una combinación ponderada de estos para priorizar la cartera de pedidos?

¿Con qué frecuencia es necesario revisar la priorización? ¿En cada sprint? ¿diariamente? o a discreción de PO?

Como está escrito actualmente, esta pregunta es demasiado amplia. Mejore la pregunta proporcionando algo de contexto sobre su situación específica, lo que ya ha intentado y por qué eso no funciona para usted.
Mayor valor, mayor riesgo, menor costo

Respuestas (2)

Permítame abordar las dos partes de su pregunta por separado.

Cómo priorizar

La Guía Scrum dice que "El Dueño del Producto es responsable de la Pila del Producto, incluido su contenido, disponibilidad y pedidos". Al final del día, el propietario del producto tiene la última palabra sobre cuál de los criterios enumerados es la mejor manera de priorizar el trabajo pendiente. Sin embargo, todo el equipo, así como las partes interesadas , pueden participar para ayudar al propietario del producto a juzgar la complejidad, el retorno de la inversión, el riesgo, etc., de una PBI. En otras palabras, los ingenieros, diseñadores, analistas comerciales, partes interesadas comerciales, analistas de control de calidad y otros pueden proporcionar información valiosa para ayudar al PO a tomar una decisión sobre cómo priorizar.

En general, he encontrado algunos métodos que ayudan a los Product Owners a lidiar con la priorización:

  • Priorización de MoSCoW : clasifique características/epopeyas de alto nivel por Debe tener, Debería tener, Podría tener y No tendrá para un próximo lanzamiento. Al trabajar con el equipo de desarrollo para comprender la línea de tiempo y el riesgo, el PO puede determinar qué características deben incluirse en la próxima versión del producto y luego dos niveles separados de "Nice-to-Haves". Won't Have también ayuda específicamente a descartar características menos importantes. Sugiero ENCARECIDAMENTE usar tableros de corcho reales con notas adhesivas o fichas para este ejercicio.
  • Mapeo de historias de usuario : explicado bastante bien aquí , si tiene historias de usuario específicas escritas, puede priorizarlas por funcionalidad, luego dibujar su línea MMF / MVP en función de qué características son absolutamente necesarias y cuáles no. Esto es bastante fácil de hacer en una pizarra o en una hoja grande de papel con notas adhesivas.
  • El método de los "cien dólares" : el propietario del producto y las partes interesadas clave obtienen 100 "dólares" o "puntos" para asignar a las diversas historias de usuarios o funciones en un tablero de corcho o pizarra. Los participantes pueden poner tantos de sus puntos para cualquier característica específica que deseen. (Los ingenieros pueden poner muchos puntos en la refactorización de un producto heredado, mientras que el marketing puede poner mucho en una característica nueva y llamativa. El CEO puede poner todos sus puntos en lo que cree que tendrá el mayor retorno de la inversión). PO puede usar esta información para ayudarlos a priorizar su trabajo pendiente.

Cuándo priorizar

Para la priorización de funciones de alto nivel, recomiendo tener una sesión de planificación de versiones al menos una vez por trimestre. Si se planean varios lanzamientos para un trimestre, cada uno debe tener su propia sesión de Planificación de lanzamiento. Aquí es donde un PO puede usar la priorización de MoSCoW u otros métodos para ayudar a determinar qué habrá en un próximo lanzamiento a un alto nivel.

Durante el desarrollo, el propietario del producto puede cambiar la prioridad de la cartera de productos en cualquier momento, teniendo en cuenta la necesidad de preparar/refinar los elementos antes de ponerlos en un Sprint. En otras palabras, los equipos nunca deben comprometerse con elementos que no consideren completamente preparados, incluso si están en la parte superior de la cartera de pedidos.

Como mínimo, los equipos deben revisar la priorización a corto plazo de los elementos con el propietario del producto en cada reunión de preparación y revisión de Sprint para asegurarse de que están refinando los elementos correctos para el próximo Sprint y trabajando en las características actuales de mayor prioridad.

Espero que esto ayude. ¡Siéntase libre de dejarme saber si hay algo que no cubrí aquí!

Usé esto para Story Mapping winnipegagilist.blogspot.ca/2012/03/… Gracias por el enlace a ScrumAlliance.
Los métodos que mencionó son formas de priorizar la acumulación, no se refieren a los factores que se consideran al priorizar. ¿Cuáles son los factores que se consideran en la priorización?
Creo que ha clasificado con precisión los factores apropiados en su pregunta. No creo que nadie pueda darle una fórmula para decir "Es X% de ROI, Y% de solicitudes de clientes y Z% de riesgo". Parte del trabajo de un PO es descubrir qué funciona mejor para su organización y su producto en lo que respecta a la prioridad, y es un proceso iterativo. La inspección de cómo fue su último lanzamiento debería conducir a la adaptación de su proceso de priorización.
Solo para agregar un poco aquí: en mi empresa hemos trabajado en proyectos desde dispositivos médicos hasta aplicaciones móviles para consumidores y sistemas de gestión de riesgos a nivel empresarial. Nunca he tenido dos propietarios de productos que hayan priorizado de la misma manera.

Yo mi opinión, depende de cuál sea el objetivo de tu producto. De acuerdo con la Guía Scrum con respecto a las responsabilidades del Product Backlog:

Ordenar los elementos en el Product Backlog para lograr mejor los objetivos y misiones;

Creo que cualquier decisión debe tomarse en conjunto con tu cliente, cuál es la misión del producto. En mi empresa, suelo utilizar primero el ROI para clasificar y segundo el Riesgo, para solucionar cualquier empate.

Al tomar una decisión con el cliente, creo que te refieres a colaborar con el cliente en las decisiones y obtener sus comentarios. Es posible que el cliente no conozca el proceso por el que está pasando y que esté confundido, ¿verdad? Por ejemplo, un cliente solicita una función y el PO trabaja con el equipo para dividirla en PBI más pequeños y entregarlos uno por uno. Estoy de acuerdo con usted en obtener la opinión del Cliente al 100%.
Bueno, el cliente quizás no sepa cuál es el proceso de desarrollo de software, pero debe saber qué es lo que más necesita. En tu ejemplo, todas las historias relacionadas con esa epopeya deberían tener una mayor prioridad, ¿estás de acuerdo?
¿Cuáles son los diferentes enfoques y con qué frecuencia priorizar el trabajo pendiente? [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v