¿Alguien tiene alguna experiencia con la gestión de productos de abajo hacia arriba? ¿Esencialmente hacer que sus equipos decidan sobre las características y la dirección del producto?
En la mayoría de mis equipos anteriores, la gestión de productos y las partes interesadas decidían sobre las funciones y los temas, y luego hacía que mis equipos escribieran historias de usuarios y tareas para cumplir con esta hoja de ruta.
Sin embargo, con mi equipo actual, tenemos la suerte de haber tenido más control. Todavía tenemos limitaciones, pero se nos ha permitido hacer esencialmente una gestión de productos de abajo hacia arriba. La organización ha decidido una dirección de alto nivel para el año, pero debemos decidir qué características se necesitan.
¿Alguien tiene algún buen método para lograr que los equipos de scrum hagan esto?
Mi idea inicial era simplemente tener un embudo de equipo en el que todas las personas enviaran ideas capturadas en un wiki o algo así y expresaran la complejidad y el impacto de sus envíos. Sin embargo, la idea es un poco meh y quiero la acumulación de características en uno o dos meses, por lo que tal vez se necesite un taller.
Podría considerar usar una técnica como el mapeo de historias .
También valdría la pena tener una conversación con el equipo sobre cómo definen el valor. Con una idea más clara de eso, estará en una mejor posición para priorizar el trabajo pendiente.
Creo que Scrum hace exactamente lo que quieres. El equipo en su conjunto agrega elementos a la cartera de pedidos (refinamiento de la cartera de pedidos) y el propietario del producto es la persona del equipo que establece las prioridades.
Si aún no tiene una propiedad clara del producto, debe determinar cómo se ejercerán la responsabilidad y los controles y, lo que es más importante, cómo se medirá el valor empresarial. Tener esos objetivos anuales es un comienzo, pero es muy poco probable que sea suficiente debido al riesgo inherente de tales objetivos a largo plazo. Para tener éxito, el equipo deberá entregar resultados con cada iteración, obtener comentarios de las partes interesadas y luego adaptar su enfoque en función de esos comentarios. El papel del PO es hacer que eso suceda y así optimizar el valor del trabajo que entrega el equipo.
Como se mencionó en otras respuestas, puede realizar un ejercicio de mapeo de historias, pero primero puede considerar alinear a todas las partes interesadas con un marco de priorización y objetivos/temas/ epopeyas de alto nivel (para el producto que está creando).
El principal problema con el enfoque de abajo hacia arriba es la divergencia de ideas de diferentes personas que pueden o no estar alineadas con los objetivos/problemas en cuestión. Si los participantes conocen los desafíos clave que deben resolver y también una idea general de cómo se priorizarán sus elementos en comparación con otras ideas, la acumulación será más refinada desde el principio.
Una forma muy divertida es hacer un Design Sprint . Seguido de un mapeo de impacto y un mapeo de historias de usuarios .
Dependiendo de su producto, salga del maldito edificio y deje que los desarrolladores hablen con los usuarios reales. Tal vez investigue el programa Shiftup para ayudarlo a facilitar la innovación continua.
Reúna al equipo con los usuarios y las partes interesadas clave, obtenga y mantenga la conversación y los bucles de retroalimentación y descubra las funciones JUNTOS .
También puedo recomendar la técnica de mapeo de historias de usuario. Con ella puedes alinear a tu equipo en una dirección y todos los miembros del equipo pueden planificar el proyecto. Si todos están involucrados en el proceso de planificación, la propiedad es mucho mayor.
A menudo veo equipos que utilizan un enfoque de arriba hacia abajo y de abajo hacia arriba al mismo tiempo. Pero, de nuevo, tal vez estoy usando el término "de abajo hacia arriba" de una manera ligeramente diferente.
Las "historias de usuarios", para mí, son de arriba hacia abajo: "este edificio tendrá un magnífico arco de piedra sobre la entrada principal".
Pero alguien también está trabajando al mismo tiempo de abajo hacia arriba, averiguando cómo implementar realmente estas cosas en el contexto más amplio del todo. "Para hacer esto, el día 41 necesitaremos tener una estructura de soporte temporal capaz de soportar 2,300 libras. La cual debe diseñarse así. Por lo tanto, para el día 36 los cimientos deben estar en lugar, y probado para asegurarse de que sostendrán el peso".
Los equipos se dividen para estar mirando ambos extremos al mismo tiempo para asegurarse de que se encuentran en el medio.