Escrito por Miguel Ángel Lanz para Deconstruyendo Scrum.

Érase una vez en una historia llena de agilismo. Un Development Team y su Scrum Master se encuentra en los preparativos para conocer a su nuevo Product Owner, definiendo, fecha, hora y sitio para tener su primer encuentro. 

Al pasar los días, llega el momento en el cual ya podrán poner cara y voz a su nuevo compañero de equipo. El equipo de desarrollo le pregunta con ansias a su Scrum Master -¿Hoy es el primer día de nuestro Sprint?

La Scrum Master responde –hoy no es el primer día del Sprint, este es simplemente nuestro primer encuentro para conocernos y establecer el primer contacto con nuestro Product Owner, el cual me ha adelantado que quiere contarnos su visión sobre una idea chulísima de su nuevo producto;  A lo que el resto del equipo dice -ok!

Llega el momento del encuentro y todos se presentan educadamente –como si fuese una primera cita. La Scrum Master se para junto al Product Owner y comparten la agenda de la sesión – ¡ok equipo! Hoy en nuestro primer encuentro tenemos como objetivo entender la visión del producto que tiene en mente nuestro Product Owner. 

Pasado varios minutos en el cual el nuevo equipo Scrum (ya que tienen ahora su Product Owner) genera un entendimiento común sobre la nueva visión del producto, uno de los miembros del Development Team pregunta –y ahora, ¿Cuáles son los siguientes pasos? La Scrum Master responde –luego de este encuentro tenemos que generar nuevos espacios de entendimiento, donde el Product Owner acompañado de una serie de personas interesadas en el Producto y nosotros, vamos a ir estableciendo acuerdos que nos permitan descubrir en una primera versión, el Producto que se desea desarrollar. 

Un nuevo miembro del Development Team pregunta –y esta fase, ¿Cómo se llama? ¿Sprint “0” cero? La Scrum Master responde –nooooo! Eso de Sprint “0” cero no existe, esta fase se le conoce como el proceso de descubrimiento del producto, en la cual podemos hacer uso de diferentes métodos o prácticas (Design Thinking, Inception Deck, Lean Inception entre otras) que nos permitan generar un entendimiento común entre todos los involucrados. Esto nos va a llevar a establecer un acuerdo sobre el objetivo de nuestra primera versión del producto y beneficio esperado que nos deje el mayor aprendizaje, permitiéndonos adaptar la construcción del producto en base al feedback que nos darán nuestros clientes. 

Al pasar los días y las diferentes reuniones del proceso, el nuevo equipo Scrum ha acordado con las partes interesadas la primera versión del producto (MVP), y a su vez el Development Team ha aportado una primera estimación (relativa) sobre la primera versión del producto. 

Dicha información en un futuro le será útil al Product Owner para tener una previsión de cómo podría evolucionar (incremento) su producto… Continuará

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar