¿Existen técnicas de lluvia de ideas relacionadas con las sesiones de recopilación de requisitos o las Revisiones de Sprint que puedan ayudar a producir ideas?

Antes de elegir alguna técnica, debe definir criterios: ¿Necesita profundizar más o más?

Probablemente la mejor estrategia es:

• al principio es ir más profundo (enfoque) para obtener una mejor comprensión de cuáles son realmente las necesidades del Cliente,
• más tarde, al final: amplíe para mostrar el espectro completo de posibles sulluciones

Para hacer eso, necesita comprender los detalles de diferentes [técnicas de pensamiento].

En mi humilde opinión, debe aplicar de acuerdo con los pasos mencionados anteriormente:

1. Análisis morfológico
2. Combinación de técnicas [TRIZ][3]: operador del sistema, también conocido como 9 ventanas y resultado final ideal (IFR)

ps lamentablemente no puedo proporcionar más enlaces

TL;DR

Determinar qué producto debe construirse y qué características debe tener el producto es responsabilidad de las partes interesadas identificadas en el estatuto de un proyecto. Nunca es responsabilidad del Propietario del Producto tal como lo define el marco Scrum.

Generar ideas comerciales no es responsabilidad del propietario del producto

¿Existen técnicas relacionadas con las sesiones de requisitos o Revisiones que puedan ayudar a producir ideas? ¿Son importantes las ideas para estas sesiones?

Esto parece ser un malentendido fundamental sobre los roles del propietario del producto y las partes interesadas en Scrum. El propietario del producto no está allí para ayudar a las partes interesadas a generar ideas comerciales; el rol de PO está ahí para:

1. Obtener los requisitos del producto de las partes interesadas.
2. Generar consenso entre las partes interesadas sobre la propuesta de valor y las prioridades de las características del producto.
3. Trabaje con las partes interesadas para formalizar una lista ordinal de características para crear un Product Backlog secuencial.

Ninguna de estas cosas equivale a una lluvia de ideas sobre las características potenciales del producto. Esa es la responsabilidad de las partes interesadas y los patrocinadores ejecutivos del Acta Constitutiva del Proyecto.

La guía Scrum no es prescriptiva sobre la solicitud de aportes de las partes interesadas

La Guía Scrum no es prescriptiva sobre cómo el Product Owner debe interactuar con las partes interesadas, pero es clara acerca de limitar la responsabilidad del Product Backlog al Product Owner. Formalmente, el rol del propietario del producto se define dentro del marco como el único árbitro de la cartera de productos y el único representante de las partes interesadas en el proyecto. La guía dice, en parte:

El Product Owner es una persona, no un comité. El propietario del producto puede representar los deseos de un comité en la cartera de productos, pero aquellos que deseen cambiar la prioridad de un elemento de la cartera de productos deben dirigirse al propietario del producto.

Formas de crear consenso sobre el producto

Si bien "generar ideas para el producto" no es responsabilidad del Product Owner o Scrum Master, ciertamente existen técnicas para generar consenso en torno a las funciones y asignar prioridades. Muchos de ellos se pueden encontrar como herramientas gratuitas proporcionadas por Mountain Goat Software . Incluyen:

• Ponderación relativa
• Proyección temática
• Puntuación del tema
• Controles deslizantes de éxito del proyecto

Sin embargo, no estás limitado a estas técnicas. Una vez que las partes interesadas saben lo que quieren que el proyecto construya o entregue, existen muchas técnicas de análisis comercial que puede usar para obtener buenas especificaciones, historias de usuarios o definiciones de características. Dado que el marco no es prescriptivo sobre cómo se recopilan estos detalles de las partes interesadas, el propietario del producto es libre de usar cualquiera de ellos o inventar otros nuevos según sea necesario.