Disponible el libro "Historias de usuario: Una visión pragmática"

Prólogo

Con historias y contando historias es como las culturas se hacen más fuertes y sobreviven. Las historias generan conexiones entre los emisores y los receptores y hacen que unos y otros se conviertan en un solo grupo, un solo equipo, un solo ser.

Las historias son un poderoso medio para fomentar la cooperación y la enseñanza de muchas cosas y las historias de usuario, tal y como las conocemos, no son la excepción a esta condición. Estas permiten crear un vínculo entre usuarios o consumidores y desarrolladores de productos. Y esta relación es el primer gran paso hacia la creación y pináculo de productos admirables, que influencien positivamente a las personas que los usen o consuman e incluso cambien para mejorar su estilo de vida.

Las historias de usuario permiten a los equipos virtuosos construir los productos correctos, incluso antes de pensar en hacerlo de la manera correcta (el método o las prácticas). Nos permiten concentrarnos en el valor de los componentes de cada producto y de cómo estos componentes hacen o harán resonancia unos con otros, en vez de involucrarnos directamente desde el inicio del esfuerzo de desarrollo en los detalles del producto o en los intríngulis de la tecnología que usaremos para construirlo.

En el caso particular del desarrollo de software, las historias de usuario son el primer movimiento de esa sinfonía que es el descubrimiento del producto y de sus características. Las historias de usuario nos ayudan a entender la proposición de valor del producto desde sus inicios, nos ayudan a anticiparnos a la gran incógnita que supone si los usuarios efectivamente usarán o no el producto, nos permiten interactuar no solo con los usuarios e interesados internos, sino también con los consumidores finales del mismo.

En este libro hemos recogido algunas de las formas de hacer las cosas cuando de historias de usuario se trata, es una visión, la nuestra, soportada en la experiencia de muchísimos años no solo en proyectos y esfuerzos de desarrollo con pensamiento Ágil y Lean, sino con otros enfoques y métodos que a estas alturas son considerados tradicionalistas.

Hemos acompañado y ayudado a cientos de equipos en docenas de empresas, en Colombia y en otros países. Han sido cientos o miles de iteraciones en conjunto, cientos de personas con las que hemos experimentado continuamente y hemos encontrado algunos escenarios exitosos, otros no tanto; pero hemos crecido en el proceso. Y sobre este aspecto, que nos haya funcionado a nosotros no quiere decir que les funcione a otros; como siempre, el llamado es a experimentar en cada escenario, en cada momento e ir analizando qué funciona y qué no en sus propios espacios y ambientes.

Al hablar de historias de usuario es necesario hablar de eXtreme Programming (XP), el contexto en el que nacieron; pero también es necesario hablar de Scrum, el contexto en el que más se usan hoy día. Sin embargo, en lo posible trataremos de ser agnósticos al marco de trabajo. Hablaremos indistintamente de iteraciones o sprints para referirnos a lo mismo.

Quienes nos conocen saben que llevamos escribiendo varios años sobre este tema que nos apasiona. De hecho, el libro es una recopilación de todos esos artículos en nuestros blogs:

Lecciones Aprendidas (http://www.lecciones-aprendidas.info/) y

Gazafatonario (http://www.gazafatonarioit.com/).

Pero los hemos enriquecido con numerosos ejemplos, les dimos un hilo conductor en el sentido en que creemos es mejor abordar su lectura, aunque nada evita que se haga en direcciones diversas.

Hemos dedicado mucho tiempo y espacio a tratar el tema de lo que significa tener buenas historias de usuario (INVEST) y hemos hecho énfasis repetidamente en que estas son un instrumento de conversación entre los miembros involucrados en el desarrollo de productos, software o no. En la parte final, incluimos el Lienzo para Conversaciones sobre Historias de Usuario, ampliamente detallado y listo para uso, una herramienta, un medio de comunicación, para promover y facilitar las conversaciones que se dan o deben darse alrededor de las historias de usuario. Una herramienta visual para documentar diferentes aspectos o dimensiones de historias de usuario nuevas o existentes en el backlog de producto.

Así es que bienvenidos a este libro y así como lo plasmado acá fue exitoso para nosotros, esperamos sea útil para ustedes, dándole aplicabilidad en su contexto.

Pueden encontrar el libro en Amazon:

Formato Kindle:

https://www.amazon.com/dp/B07HLYX68Z

Formato Tapa blanda:

https://www.amazon.com/gp/product/1723933562

Y como siempre, bienvenida cualquier retroalimentación.

Jorge y Lucho

Puedes descargar la presentación complementaria (versión 1.7 - 20190613) del siguiente enlace:

Historias de usuario: todo lo que querías saber y no te atreviste a preguntar de Lucho Salazar

Puedes descargar la presentación complementaria (versión 1.5 - 20190425) del siguiente enlace:

Historias de usuario: todo lo que querías saber y no te atreviste a preguntar de Lucho Salazar

Diferencias en el tratamiento de los requisitos entre los enfoques Cascada y Ágil

¡Una pregunta de un viejo amigo me llevó una vez más por este sendero!

Es un hecho. Muchos profesionales trabajan actualmente en circunstancias desafortunadas y, sin embargo, no toman la iniciativa de cambiar su situación porque están condicionados a un formato de seguridad, conformidad y conservación, donde todo puede parecer tranquilo pero, en realidad, nada es más perjudicial para el espíritu innovador y de transformación que requerimos hoy quienes vivimos en los tiempos del VUCA*.

En particular, durante la transición de un enfoque en cascada a uno Ágil tenemos que lidiar con la búsqueda de medios y maneras para acortar el tiempo de salida al mercado y entregar productos de alta calidad y de más valor, más temprano y más frecuente y, si es posible, a un costo menor. Sin embargo, el camino hacia la Agilidad puede ser escabroso, con baches riesgosos y con personas deambulando por allí erráticamente y hasta en dirección opuesta, incluso con temor a o sin saber cómo avanzar.

Y uno de los aspectos que empiezan a diferenciar en profundidad el uso de uno u otro enfoque es este de los requisitos. Abordamos este asunto con Carlos Gil, Johnny Ordoñez, Carlos Quiroga, Luis Mulato y el grandioso equipo de coaches del Scrum Coaching Retreat Cartagena y, como siempre, llegamos a algunas conclusiones que se mueven en el terreno de los principios y, más en el fondo, de los valores Ágiles, la cultura ágil, el Ágil es algo que eres:

• En Ágil no hablamos de requisitos, más bien de respuestas a necesidades y, en otros casos, de hipótesis de cosas que queremos aprender. Cambiar el enfoque de “requisito” a “necesidad” o respuesta a necesidad, genera un sentido profundo de empatía entre todos los interesados, es decir, equipo de desarrollo de producto y usuarios o clientes finales.
• A propósito de clientes finales, en Ágil, el cliente siempre es el centro de atención. Esto habilita a los equipos a buscar las mejores formas de suplir esa necesidad o de comprobar las hipótesis. Estas en últimas son necesidades de aprendizaje.
• Creemos que esta es la distinción más grande entre las dos propuestas: el requisito te lleva a algo preestablecido, definitivo o definible claramente. Hablar de necesidades o de hipótesis abre la puerta al cambio.
• En el enfoque Cascada se definen experiencias orientadas al proceso, con momentos de interacción preconcebidos por los formularios y procesos definidos en los requisitos, y aun hablamos de interacciones y no de conversaciones con las soluciones tecnológicas. En Ágil, aspectos como la experiencia de usuario, momentos de verdad, conversaciones, son esenciales para la definición de la historia de usuario que guía el desarrollo de producto.

Vamos con las disparidades entre uno y otro enfoque cuando de requisitos se trata

Son muchas las diferencias que existen en la forma de abordar los requisitos de un producto cuando usamos (o usábamos) la forma Cascada y lo que hacemos ahora, motivados por el pensamiento Ágil. Estas que describo a continuación son apenas algunas de ellas, algunas más relevantes que otras pero significativas todas al fin y al cabo.

Al principio del proyecto o del esfuerzo de desarrollo

En Cascada se toman o "levantan" (casi) la totalidad de los requisitos al principio del proyecto, y de muchos de ellos se hace con gran detalle. En Ágil no. Se establece un alcance, sí, una visión, pero de muy alto nivel, muy horizontal, es decir, no se llega a ningún detalle excepto quizás para esas necesidades de los dos primeros Sprints (a lo sumo), la porción de producto que se va a construir durante las primeras de cambio. El llamado Mínimo (o Minimísimo) Producto Viable.

En Cascada nos tardamos semanas y hasta meses haciendo esta primera actividad. En Ágil nos tardamos unas pocas horas, a lo sumo unos pocos días, se establece un bloque de tiempo (time-box) y cuando este se acaba, se acaba.

En Cascada participa una persona del lado del equipo de desarrollo o un "subequipo", el o los analistas funcionales o de requisitos. Quizás en algún momento entra uno que otro rol, como el Arquitecto de Software. En cualquier caso, no participa todo el equipo. En Ágil participa todo el equipo de desarrollo desde el inicio, escuchando a los usuarios e interesados en el producto.

Más adelante, cuando el proyecto está en marcha

En Cascada se refinan los requisitos, hay ajustes, controles de cambios. El sobrevaluado CCC (léase Comité de Control de Cambios) que se reúne el último jueves de cada mes, mientras el cliente ve impaciente cómo su competencia se adelanta y le quita parte del mercado. Mientras tanto, en Ágil se van refinando los requisitos iteración tras iteración. Siempre nos concentramos en lo que se va a construir en los siguientes 2 sprints o iteraciones, a lo sumo. Más tiempo no, porque las cosas pueden cambiar. Los equipos Ágiles aprovechamos los cambios para brindar ventaja competitiva a nuestros clientes.

En Cascada los requisitos siempre los "administra" una persona o un subequipo (analistas), con los usuarios. En Ágil hay un Dueño de Producto (representante de los usuarios), pero la responsabilidad es de todo el equipo.

En Cascada los requisitos se construyen, como sabemos, siguiendo un proceso secuencial donde ellos se tratan aparte y son una entrada al resto de ese proceso; además, el producto se entrega como un todo. En Ágil se construye un incremento del producto en cada iteración (de muy pocos días), esto es, producto probado y funcionando con valor, potencialmente desplegable y que genera retorno de la inversión (ROI) o, al menos, permite recibir retroalimentación, con lo que podemos aprender muchísimo del comportamiento y de la reacción de los usuarios al uso del producto.

En Cascada normalmente el orden de construcción lo decide el equipo de desarrollo (quizás en cabeza de un arquitecto o un subequipo). En Ágil el orden de construcción lo decide el usuario (dueño de producto), es él quien tiene la última palabra sobre esto.

En Cascada, el énfasis en cuanto a requisitos está en la especificación (documentación) de los mismos, en otras palabras, en escribir y escribir requisitos. En Ágil, el énfasis está en la conversación que tienen los usuarios o su representante (dueño de producto) con el equipo de desarrollo. Esta conversación es cara a cara y continua, durante todo el proyecto o esfuerzo de desarrollo.

Esta última característica es lo que nos empieza a volver ágiles, cuando lo logramos nos damos cuenta que estamos usando el pensamiento Ágil y estamos dejando atrás la cascada y otras formas tradicionales de trabajo.

En Cascada se espera que prácticas de aseguramiento de calidad permitan que se entregue un producto que cumpla con casos de prueba previamente definidos y aprobados con el área de negocio. En Ágil damos espacios a prácticas como TDD y BDD para guiar la definición de los criterios de aceptación, identificando de manera temprana la respuesta real que espera el usuario final, la prueba es guiada por la retroalimentación continua, lo cual mejora el uso y por lo tanto la aceptación del usuario.

Y sobre medios o herramientas para “recolectar” y administrar requisitos

Una diferencia en cuanto a los medios o mecanismos para "recolectar" requisitos:

En Cascada se usan medios como los documentos escritos tradicionales llenos de expresiones tipo "el sistema debe hacer esto" o "el sistema debe hacer aquello", o se usan mecanismos como casos de uso, entre otros. En cualquier caso, como mencioné antes, la fuerza está en elaborar grandes cantidades de documentación de requisitos. Escribí mucho sobre esto aquí en el Gazafatonario durante la década pasada y publiqué un libro al respecto. Lo pueden encontrar en Amazon.

En Ágil, por su parte, usamos medios o mecanismos que promuevan la conversación entre los interesados (usuarios y equipo de desarrollo). Las Historias de Usuario se han constituido en el medio esencial para esto. Pueden encontrar una especie de índice de mis artículos y propuestas y las de mi gran amigo Jorge Abad sobre este tema en bit.ly/lashistoriasdelucho.

Ahora sí, cuéntame en el foro de otras diferencias a la hora de recolectar y administrar requisitos o necesidades que consideres importantes.

*VUCA: siglas en inglés de Vulnerabilidad, Incertidumbre, Complejidad, Ambigüedad

Revisión a la Guía de Nexus 2018

Ken Schwaber y Scrum.org anunciaron hoy (enero 17 de 2018) que fue publicada una actualización a Nexus, el marco de trabajo para escalar Scrum. Acorde con los recientes cambios a su marco de trabajo subyacente, los cambios a Nexus aumentan la claridad, enfatizan la criticidad de “Terminado” a Escala y extienden el alcance mundial de Nexus, se anunció hoy en un comunicado oficial.

Las actualizaciones fueron determinadas en parte a través de los comentarios de la comunidad de Scrum a través del sitio web Scrum Guide User Voice, la comunidad de Scrum.org y sus entrenadores profesionales de Scrum (PST). Un énfasis en aumentar las aclaraciones sobre el Equipo de Integración de Nexus y el propósito de su rol, afirmando la importancia de la transparencia a escala para la integración y definiendo qué significa "Terminado" a Escala, son algunos de los principales cambios que los practicantes de Scrum encontrarán en la versión actualizada de la Guía Nexus.

Estos son los cambios más significativos:

1.    Actualizada la descripción de la Guía Nexus de “El exoesqueleto de desarrollo a escala con Scrum” a “La guía definitiva para escalar Scrum con Nexus: las Reglas del Juego”.

2.    Nexus se define ahora como “una relación o conexión entre personas o cosas”.

3.    En el Flujo del Proceso Nexus, la terminología se cambió para hacer foco en los equipos en vez de en los miembros individuales, “Un Nexus consiste de múltiples equipos Scrum multifuncionales que trabajan en conjunto para entregar al menos un Incremento Integrado potencialmente distribuible en cada Sprint”.  También se agregó que basados en las dependencias, los equipos se autoorganizan y seleccionan los miembros más apropiados para hacer un trabajo específico.

4.    Claridad alrededor del rol del Equipo de Integración Nexus:

a.    El Equipo de Integración Nexus está conformado a menudo de miembros de los Equipos Scrum individuales del Nexus. Esta composición soporta la necesidad de inteligencia hacia arriba de los Equipos Scrum individuales en el Nexus.

b.    El Equipo de Integración Nexus no es el encargado de hacer la integración. Los Equipos Scrum individuales realizan el trabajo de integración.

c.    Se eliminó la definición de que el Equipo de Integración Nexus es un Equipo Scrum puesto que esto ha causado confusión, permitiendo creer que sus miembros son un Equipo Scrum separado permanentemente de los demás en el Nexus.

5.    El Refinamiento se movió en los Eventos Nexus hasta la parte superior. Ahora aparece antes que la Planificación del Sprint Nexus.

a.    El Refinamiento ya no está prescrito como un evento de dos partes. La terminología se enfoca en la transparencia en vez de en la visualización.

b.    Se eliminó la referencia al Refinamiento como “reuniones”, en vez de eso solo “Refinamiento”.

c.    Se enfatiza en el Refinamiento como una actividad continua a lo largo del Sprint mientras sea necesario y apropiado.

6.    La Meta Nexus ya no se especifica como una entrada o salida de la Planificación del Sprint Nexus puesto que esto puede variar, en cambio se define como una meta que el Dueño de Producto discute durante la Planificación del Sprint Nexus. Se eliminó terminología sobre la necesidad de estar en el mismo espacio físico.

a.    La Meta Nexus es ahora la Meta del Sprint Nexus y ya no se encuentra en la lista de nuevos artefactos, para ser consistente con el Marco de Trabajo Scrum.

b.    Se eliminó de la Tabla de Contenido.

7.    El Scrum Diario Nexus es una oportunidad para que los equipos busquen impactos entre equipos así como dependencias entre ellos.

a.    El Scrum Diario Nexus no es la única vez que la Lista de Pendientes del Sprint Nexus debería ajustarse. Es al menos uno de los momentos en los cuales los equipos se juntan para ajustar la Lista de Pendientes del Sprint Nexus para reflejar su entendimiento del trabajo y las dependencias entre equipos.

b.    El Scrum Diario Nexus es el momento en el que los Equipos de Desarrollo en el Nexus inspeccionan el progreso hacia la Meta del Sprint Nexus.

8.    La Revisión del Sprint Nexus no es para mostrar algo a la audiencia y contarle sobre eso, como no lo es en Scrum – se agregó terminología que la clarifica como una oportunidad de adaptar La Lista de Elementos del Producto si es necesario. También se menciona la necesidad de retroalimentación en la descripción de la Revisión del Sprint Nexus en el “Flujo del Proceso Nexus” en la página 5.

9.    Se agregó que la Retrospectiva del Sprint Nexus es una oportunidad formal para que el Nexus se inspeccione y adapte y cree un plan de mejoramiento que se ejecute a partir del próximo Sprint.

a.    Similar a la actualización de la Guía de Scrum, la Retrospectiva del Sprint Nexus existe para asegurar el mejoramiento continuo para el Nexus.

10. El Incremento Integrado representa el estado actual del trabajo integrado.

11. La Definición de “Terminado” especifica que el Incremento Integrado debe estar integrado.

12. En “Transparencia de los Artefactos” se eliminó la definición “la prueba de deuda técnica inaceptable es cuando la integración ocurre y sigue sin estar claro que todas las dependencias están resueltas”. Se reemplazó con “El software debe ser desarrollado de tal forma que las dependencias sean detectadas y resueltas antes de que la deuda técnica sea inaceptable para el Nexus”.

13. Se eliminó el párrafo sobre las prácticas de software. Aunque importante y relevante, el tema requiere de mayor elaboración para que agregue valor.

14. Se adicionó la cláusula de Creative Commons, lo que permitirá a los equipos y organizaciones, a nivel mundial, reutilizar el contenido de la guía y ampliar su alcance.

Como siempre, con mis grandes amigos Jorge Abad (@jorge_abad) y LeonardoAgudelo (@sweepnoise), hicimos la traducción de los cambios y mejoramos también algunos aspectos de la terminología en español.

La guía actualizada puede descargarse ya en español (2018) desde el sitio Web:  https://www.scrum.org/resources/nexus-guide.

Para conocer más de Nexus, pueden leer mi artículo:

http://www.gazafatonarioit.com/2016/01/nexus-el-exoesqueleto-de-desarrollo.html

En el que también podrán ver y descargar una presentación al respecto.

¿Cómo les ha ido con el uso de Nexus? ¿Tienes alguna pregunta adicional al respecto? Por favor, déjanoslo saber en el foro.

The User Story Conversation Canvas

Good user stories “stimulate”, in a good sense, the conversation between those involved (e. g. Product Owner and team members). In addition, user stories see, or let you see, functionality from a business perspective, specifically from the Value that the story provides to the business.

As its name suggests, this User Story Conversation Canvas is a means of communication, a tool to promote and facilitate conversations that take place or should take place around user stories. In the background, it is a visual tool to document different aspects or dimensions of new or existing user stories in the product backlog.

Anyone involved, be the Product Owner, the whole team or just one member of it, the Scrum Master, even a user, can find in this canvas the aid they need to describe the most relevant aspects of a user story in a clever manner, from the people who are or will be involved during the definition, evolution, development and implementation of the story, through the context of the story itself, to the expected result and the metrics associated with the story. But most of all, you can find the support needed to prepare fantastic conversations about the elements that make up the product.

Refinment, planning and review sessions are three of the main scenarios where we can use this Canvas to Talk about User Stories. But it can be used in many other circumstances: the product owner talking to users and other interested parties; members of the development team, to agree and synchronize the work to be done; the Scrum Master and the Product Owner, in conversations around the product and the product backlog, when applying patterns to divide the stories, among other scenarios.

When it comes to user stories, the emphasis is on the Conversation!

This is the first version of the canvas and its associated guide, in English. In this I explain what it is for and the intention of each section of the canvas, as well as different aspects to take into account when using it: the different scenarios where it can be used, who can use it and what are its main benefits. 

Get the User Story Conversation Canvas and its associated guide below.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Get the original Canvas in Spanish.

Sobre el Backlog de Producto, el Refinamiento del Producto y el Rol del Dueño de Producto

La Guía de Scrum define el Refinamiento del Backlog de Producto como:

“El refinamiento de la Lista de Producto es el acto de añadir detalle, estimaciones y orden a los elementos de la Lista de Producto. Se trata de un proceso continuo en el cual el Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos de la Lista de Producto. Durante el refinamiento de la Lista de Producto, se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente consume no más del 10% de la capacidad del Equipo de Desarrollo. Sin embargo, los elementos de la Lista de Producto pueden actualizarse en cualquier momento por el Dueño de Producto o a criterio suyo”.

Pero ¿qué hay detrás de escena? ¿Cómo luce un buen refinamiento de producto? Hablemos un poco sobre eso.

Sobre el Producto

Primero, me gustaría decir algunas palabras sobre backlogs y cómo logramos que estos sean grandiosos:

Actualmente sabemos que

“La Lista de Producto es una lista ordenada de todo lo que podría ser necesario en el producto y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación”.

Aunque no es un concepto complicado, la noción de backlog de producto (o como se llama en español, la Lista de Producto), no siempre la entendemos completamente.

Roman Pichler y Mike Cohn dicen que un backlog de producto apropiado debería ser DEEP:

Detallado apropiadamente. Los elementos del backlog de producto difieren en su nivel de detalle. Los que se desarrollarán en los próximos sprints deben haber sido lo suficientemente entendidos hasta el punto de que puedan ser completados por el equipo en cada uno de esos sprints. De otro lado, aquellos elementos que no serán construidos durante un tiempo deberían describirse con menos detalles.

Emergente. El backlog de producto es una entidad viva que cambia constantemente y evoluciona a medida que el producto está siendo desarrollado o mantenido. A medida que el Dueño de Producto y el equipo aprenden más acerca del producto y de su entorno, por ejemplo, del mercado y de sus usuarios, adicionan nuevos elementos, eliminan otros y ajustan otros. Emergente es un atributo el cual no solo esperamos que este atributo esté presente en cada backlog, sino que es un indicativo de un backlog de producto sólido y efectivo.

Estimado. Cada elemento del backlog de producto tiene un estimado que corresponde al esfuerzo requerido para desarrollar ese elemento. El Dueño de Producto usa muchas veces este número, entre otras cualidades, para determinar la prioridad del elemento en el backlog de producto.

Priorizado. ¡Ni más faltaba! Todos los elementos el backlog de producto están priorizados (ordenados). Los elementos de mayor valor deben estar en la parte superior y los de menos valor en el fondo. El ordenamiento del backlog de producto determina el orden de entrega de sus elementos. Esta es una de las muchas formas en que un Dueño de Producto maximiza el esfuerzo del equipo y el valor entregado al negocio.

Por experiencia también sé que un buen backlog de producto es:

• Transparente. Es visible a todos aquellos involucrados en el diseño y desarrollo del producto y a todos los interesados en el producto.
• Relevante. Los nuevos cambios que se observan mientras se desarrolla el producto se reflejan en el backlog de producto, refinando sus elementos de manera adecuada.

Una vez que hemos entendido estas premisas, estamos preparados para jugar el juego del refinamiento del producto.

Sobre el Refinamiento

El refinamiento establece un entendimiento común entre el Dueño de Producto y los miembros del equipo acerca de los elementos priorizados y su funcionalidad y los desafíos técnicos. También crea más transparencia entre los miembros del equipo Scrum.

Aunque no hay una sola forma de definir el refinamiento del Backlog de Producto genéricamente en Scrum, - no hay ninguna fórmula que garantice el éxito cuando de afinar el backlog se trata – en la práctica hacemos refinamiento cuando enfrentamos:

• Un backlog de producto muy grande
• Un elemento de backlog grande
• La adición de nuevos elementos al backlog de producto

También, cuando eliminamos elementos existentes del backlog de producto lo estamos refinando.

Cualquier elemento del backlog de producto debería refinarse cuando y a medida que conocemos información adicional sobre él.

Deberíamos dar prioridad al refinamiento de elementos del backlog de producto que se van a desarrollar en el siguiente Sprint.

El refinamiento del backlog de producto es o debería ser un proceso continuo conducido por el Dueño de Producto. Este se reúne con los interesados y usuarios para recolectar cualquier información necesaria para el refinamiento. Pero también planea y lleva a cabo reuniones con el equipo para que sus miembros conozcan los elementos nuevos/modificados en el backlog. El Dueño de Producto también debería conducir estas sesiones de refinamiento del backlog de producto.

Para saber más de Refinamiento del Producto puedes leer mi artículo sobre Purga Ágil del Producto.

Sobre el Dueño de Producto

Esta es la razón por la cual, solo a través de una buena sinergia entre el equipo y el dueño de producto, que ellos pueden construir un producto útil y fantástico. Un gran desafío para el dueño de producto es gestionar el flujo de los múltiples requisitos que llegan desde los distintos interesados y lograr que haya consenso entre todos (interesados, usuarios, equipo de desarrollo) sobre los requisitos que proporcionen el mayor valor al negocio.

El resultado de una sesión de refinamiento de producto es un entendimiento común de los elementos del backlog de producto que pueden desarrollarse en el siguiente sprint. ¡Por lo menos!

Un Dueño de Producto extraordinario sabe que si un producto debe ser competitivo en el mercado, entonces este debe cumplir con todos sus atributos requeridos que se hayan definido (las características imprescindibles), pero también con sus atributos de desempeño (las características importantes o que sería bueno que tuviera) y sus atributos interesantes (esas características que tienen valor para el negocio y que sería bueno que el producto tuviera).

Por cosas como esta es que ejercer el rol de Dueño de Producto eficientemente no solamente es vital para desarrollar productos fructíferos con Scrum. También es un proceso de aprendizaje para los individuos que ejecutan el rol y para la organización.

Desde este punto de vista, el rol del Dueño de Producto significa lograr un balance entre el tira y el afloje del desarrollo del producto. No es una tarea simple de llevar a cabo. Construir el producto correcto en el momento correcto es un asunto de mayor interés para el éxito de todo Dueño de Producto. Es lo que se conoce como el “Dilema del Dueño de Producto”.

Cuando un producto exhibe una historia bien construida que es coherente, se convierte en un producto no ordinario. Cuando las partes de este producto no ordinario interactúan, generan resonancia, una mejora de la potencia que hace que un producto sea más grande y más eficaz de lo que la suma de sus partes podría predecir. Esta resonancia incita a respuestas de sus usuarios. Por lo general, son reacciones que hacen que la gente experimente un producto como algo extraordinario, útil y valioso.

Scrum, junto con otro conjunto de prácticas y técnicas ágiles, nos proporciona el marco de trabajo necesario para construir tales productos de valor con las características correctas.

¡Y para eso es que están los Dueños de Producto!

Así que, ¿qué estás haciendo tú para crear esta sinergia y construir productos sorprendentes? Déjamelo saber en la sección de comentarios abajo.

Nota:

Publiqué este artículo en Pulse el 1 de junio de 2017, originalmente en inglés:

On Product Backlog, Backlog Refinement and the Product Owner Role

Para saber más sobre el rol del Dueño de Producto puedes leer mi artículo Guía Supernumeraria para un Dueño de Producto Virtuoso.