Quiero empezar el artículo recordando la definición de Incremento de la guía de Scrum:
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be «Done,» which means it must be in useable condition and meet the Scrum Team’s definition of «Done». An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
Al final de cada iteración – Sprint – hay un nuevo Incremento, pero el Incremento es todo, lo nuevo y lo realizado anteriormente. A veces este detalle se pasa por alto y es importante. En cada iteración, no se añaden sólo nuevas funcionalidades al producto, sino que se itera sobre las existentes como resultado de los aprendizajes de las entregas anteriores, gracias al feedback del cliente y los datos que producen nuestras métricas. Es más, puede que haya iteraciones sin nuevas funcionalidades y aun así, se entregue valor.
Otra frase que me parece fundamental es que el Incremento es un paso hacia la visión u objetivos. Hay muchas ideas, propuestas, mejoras, experimentos alrededor del producto pero hay que poner foco, para poner foco hay que elegir, y para elegir hay que tener una visión la cual te ayuda – junto con otros factores – a decidir en qué vamos a invertir nuestro tiempo y dinero. No vale todo, lo que vale es seguir intentando alcanzar nuestros objetivos y quién sabe si plantearnos cambiar los objetivos para empezar un nuevo camino. Tener clara la visión del producto, los objetivos e incluso métricas de éstos, es clave para decidir prioridades y medir si los resultados que obtenemos nos acercan a dónde nos dirigimos.
El Incremento es un artefacto que podría tener su propio ciclo de vida, donde el Producto Owner junto con el resto de roles alrededor del producto, trabajan codo a codo en cada uno de los pasos.
Elegir y refinar
El Product Owner dispone de mucha información para elegir las prioridades de las siguientes iteraciones. Elegir los elementos del Backlog es la clave del nuevo Incremento de producto.
“There’s always more to build than we have time or resources to build — always.”
― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product
Es importante que el Product Owner vaya refinando estos elementos con el resto de los roles del producto con la finalidad de que todos sepamos al menos:
- Qué problema queremos resolver/oportunidad aprovechar
- Cómo sabremos si lo estamos haciendo bien
- Cómo vamos a empezar a resolver el problema/aprovechar la oportunidad
Si el Product Onwer hace un buen el refinamiento de los elementos del Backlog, el resto de los pasos se simplifican considerablemente como veremos a continuación. Invertir en dejar claro lo que queremos hacer y por qué, ahorra mucho tiempo en el resto del ciclo de vida de cada elemento del Backlog así como del nuevo Incremento.
Implementar y revisar
Una vez está claro por todos los roles el trabajo a realizar, se empieza su desarrollo y al final de la iteración se llevará a cabo la revisión de la misma – Sprint Review – para después entregar el Incremento al cliente y mercado.
El Product Owner procura que el desarrollo del nuevo Incremento no se detenga, es fundamental que aclare cualquier tipo de duda, resuelva impedimentos e incluso ajuste el nuevo Incremento si surgen imprevistos. Cuando se hace un buen refinamiento, pueden existir menos dudas durante el desarrollo y aunque esto parezca una tontería, una duda supone que una persona se para, pregunta o espera a preguntar, se le responde y luego se retoma el trabajo. Esto es tiempo, y si pasa en muchos elementos del Backlog es tiempo que quizá tendríamos que haber añadido durante el refinamiento para evitar pararnos durante el desarrollo. Mejor llevarse las sorpresas antes de ponerse manos a la obra.
Durante la revisión de la iteración, el Product Owner ha invitado a los Stakeholders y de nuevo, si se ha hecho un buen refinamiento, los Stakeholders verán un nuevo Incremento con los elementos que habían acordado y el funcionamiento que habían definido juntos. La revisión de la iteración tendría que ser un momento para celebrar y obtener nuevo feedback, pero si nos encontramos con frases como: «esto no era así», «dijimos que el comportamiento iba a ser de otra manera»… entonces hemos cometido un grave error, porque hemos puesto en peligro el Incremento e impactado negativamente en el flujo de trabajo y emociones del equipo. Casi siempre que he visto esto, se ha debido principalmente a que durante el refinamiento no han estado los Stakeholders involucrados y/o no se ha tenido un momento de confirmación de esos elementos del Backlog con ellos. Cuando terminamos de refinar los elementos del Backlog y el Product Owner debe encargarse de que existe un momento de confirmación para alinear a los roles, crear confianza, gestionar las expectativas, y minimizar sorpresas durante la revisión de la iteración – ‘doble check’.
Entregar y aprender
Suponiendo que el Product Owner no cancela la entrega del Incremento, ahora empieza lo bueno, toca aprender. Podemos aprender a través de entrevistas a los usuarios y clientes, recogiendo los datos y evaluando nuestras métricas, pero siempre hay que analizar si el Incremento cumple con su definición, es decir: existe valor y hemos dado un pasito más hacia la visión y objetivos. Bajo mi punto de vista, expandiría la definición de ‘Done’ a cuando tenemos aprendizajes del nuevo Incremento entregado al cliente, sobre todo, para evitar casos en los que pensamos que tras la entrega ya nos podemos poner con lo siguiente. Aquí el Product Owner tiene de nuevo un papel muy importante, no sólo él tiene que aprender, sino que debe conseguir que aprendan todos los roles que están alrededor del producto, debe conseguir que sus cabezas se pongan a trabajar para transformar todos esos aprendizajes en nuevos elementos a incluir en el Backlog del producto.
Cada Incremento de producto es una nueva oportunidad para aprender.
Comunicar el Incremento
En algunos contextos, además de la revisión de la iteración donde se demuestra el Incremento de producto, también se hacen más comunicados a la organización. Es posible que exista un canal en la empresa donde se informe de que se ha puesto un Incremento de producto ‘en producción’, y a posteriori, se compartan los resultados del mismo a través de números y feedback que representan el impacto del Incremento en el cliente y mercado. El Product Owner debe saber comunicar este tipo de información, y siento si lo que voy a escribir ahora es muy básico, pero el Product Owner debe saber comunicar vía oral y escrita de forma efectiva: valor y resultados en pocas palabras/líneas acompañados de algo visual. Es más, en mi empresa, hay algunos eventos durante el año donde se hace un repaso de los objetivos y presentamos qué hemos hecho para alcanzarlos – o intentarlo – y es importante saber comunicar el Incremento delante de roles de Management y CXO. Hay que estar orgullosos del producto, hay que saber hablar de negocio, y también, hacer presentaciones bonitas, sencillas, claras y comprensibles de un sólo vistazo.
Si pensáis que aquí termina el ciclo de vida del Incremento, me temo que no, pues mientras estamos comunicando estos resultados, él sigue creciendo y el Product Owner junto con el resto de los roles, intentan que el trabajo fluya, se aporte valor y avance hacia su visión.
Os dejo los enlaces a los artículos que estoy escribiendo sobre el Product Owner:
Vanesa Tejada 