Descubrimiento y Validación frecuente

Descubrimiento y Validación frecuente

¿Cómo sabemos que estamos entregando un producto que entrega valor?

¿Cómo sabemos que estamos el producto entrega valor?

¿Como sabemos que una funcionalidad entrega valor?

¿Cómo sabemos cuáles son las oportunidades en el mercado, brecha de satisfacción o valor no realizado potencial a entregar que valen la penan convertir en realidad?

Frecuentemente los equipos Scrum se dedican a entregar funcionalidades ya definidas por otros equipos o solicitadas por los usuarios en la creencia que la entrega es la medida del éxito.

El descubrimiento puede ayudar a encontrar cuales son los problemas potenciales del cliente, explicar los escenarios en que se producen además de ayudarnos a plantear una serie de posibles soluciones validando para conseguir evidencia que nos permita decidir sobre que construir o cuando construirlo, además de validar las entrega de valor para permitirnos tomar mejores decisiones para reducir el riesgo de negocio.

Pero el descubrimiento y la validación no son actividades que se realizan solamente al inicio del desarrollo de un producto. Estas actividades son continuas y se deben combinar en cada Sprint con la entrega de producto.

Desarrollar sin verificar cuales son los problemas y soluciones potenciales del cliente agrega un riesgo innecesario. Así como también enfocarse solamente en descubrimiento no permite validar la entrega de valor no permite validar las hipótesis en el mercado al usar el producto. Ambos escenarios pueden llevar a tomar decisiones sin evidencia.

El descubrimiento puede empezar tomando en cuenta el problema de negocio. Es necesario establecer el criterio de éxito del lado del negocio para luego enfocarse en el cliente en sus problemas y dolores.

El descubrimiento y la entrega de producto y sus actividades no son lineales, debe ser adaptativo, emergente tener ciclos cortos de aprendizaje. Scrum provee el entorno para aprovechar los ciclos cortos en cada Sprint.