Buenas y “malas” historias de usuario

Los criterios INVEST* no son los únicos que hacen a una historia de usuario una “buena” historia de usuario. Pero son un buen comienzo. Además, decir o pensar que una historia de usuario es buena o mala quizás no sea la mejor idea. En cualquier caso, lo más importante es si la historia está preparada o no para implementarse o desarrollarse. Si no lo está, entonces hace falta conversación, ojalá cara a cara, para ponerla a punto: conversación entre los usuarios o interesados clave y un dueño de producto o gerente de producto; y también, conversación entre estos y el equipo de personas que finalmente hará el trabajo de implementación de esas historias.

Nota mental: en realidad, lo más más importante de la historia de usuario es que genere Valor, en cualquiera de sus modos, por ejemplo: más ingresos, mayor felicidad a los usuarios o consumidores, menores gastos, mejora en la marca organizacional, más clientes, mayor aprendizaje, entre muchas otras formas de valor.

Y como son un buen comienzo, veamos algunos ejemplos de cómo se cumplen o no esos criterios en las historias de usuario. Usaremos la forma Connextra para escribir las historias de usuario, pero recordemos que hay muchísimas formas, cuando no infinitas, de representar las historias. Los ejemplos corresponden a una plataforma de compra y venta en línea de productos y en algunos de ellos obviaré la parte del “para” qué se quiere la historia, solo con la intención de concentrarnos en lo fundamental.

Independiente

En la medida de lo posible, las historias se pueden implementar en cualquier orden.

La historia del Comprador no se podrá implementar hasta tanto no estén establecidas todas las condiciones de venta que el Vendedor requiera. Y esta historia solo es verificable en cuanto a instituir y preservar las condiciones de venta, pero no en cuanto a hacerlas cumplir por el comprador. Las cosas así, es posible eliminar la dependencia, dividiendo las historias de usuario usando como criterio las distintas condiciones de venta del producto, desde el punto de vista del Vendedor, además de combinar el establecimiento de los términos de venta con algunas condiciones para hacerlos cumplir en cada historia.

Negociable

Se deja abierta la forma de lograr el objetivo, sin sugerencia de implementación.

La historia de usuario original no deja ningún margen al diálogo en cuanto a las posibilidades de implementación de las formas de pago, es la indicada y nada más. En cambio, la historia derivada abre las posibilidades y permitirá que se tomen las mejores decisiones para su confección mediante conversaciones sucesivas.

Valiosa para el usuario

Algo que el usuario realmente pueda usar, no solo una tarea técnica.

Hasta tanto las imágenes del producto puedan usarse, no tienen ningún valor y, por consiguiente, la historia de usuario en sí carece de trascendencia, de peso (alias de valor). No proporciona ningún beneficio. El impacto de su contraparte, sin embargo, es a todas luces evidente. El valor de la historia salta a la vista.

Estimable

No se requiere investigación, bien entendida.

¿Cuántos informes son? ¿Cuáles? ¿Con qué información o datos? ¿En qué momento se producirán? Estas y algunas otras cuestiones sin respuesta aparente no permitirán que la historia de usuario pueda estimarse en complejidad o tamaño, mucho menos en tiempo. La historia contigua, en cambio, goza de mayor precisión: es una única lista, un informe solo de productos entregados; estas condiciones reducen las posibilidades y aumentan los detalles necesarios para realizar una predicción más o menos confiable sobre cuándo podrá estar terminada.

Pequeña

Se puede pasar del concepto a estar preparada para su lanzamiento en un par de semanas y preferiblemente dentro de un par de días.

Como con el caso de la historia no estimable, no conocemos la cantidad ni la calidad de los informes a los que se refiere esta historia. El informe resumido por categoría de producto, por su parte, es algo mucho más acotado: es uno solo, su carácter de “resumido” ya deja entrever que los datos que incluirá son pocos. Tiene visos de ser una historia que se pueda implementar en dos o tres días de una iteración.

Comprobable

Es posible medir algo específico para verificar que la historia está terminada.

¿Qué significa “rápidas”? ¿45 segundos? ¿27? ¿Un milisegundo? No hay forma de verificarlo, no será posible probar los términos de esta historia, ni siquiera con los mejores robots de prueba existentes hoy. En general, “rápido” es una expresión ambigua, imprecisa. Si decimos “2 segundos”, la ambigüedad desaparece de inmediato. Unos pocos casos de prueba nos permitirán comprobar la completitud de la historia.

 

¿Quieres saber más sobre historias de usuario?

En octubre estaré facilitando un curso donde te contaré de mis experiencias en este y otros asuntos sobre lo esencial de las historias de usuario. Encuentras más información en:

https://luchosalazar.com/portfolio/nuevo-curso-historias-de-usuario/

¡Te espero!

 

Planificar historias de usuario en tareas

El trabajo a realizar durante el Sprint se planifica en la Planificación de Sprint. Este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo.

En particular, en esta presentación  muestro algunos ejemplos de cómo descomponer historias de usuario de un backlog de producto en tareas de un backlog de sprint. También explico algunas prácticas y guías a tener en cuenta a la hora de la planificación.

Estas y otras ideas, en la presentación que puedes ver y descargar aquí.

El Planning Poker me arruinó por completo

Si llegaste hasta aquí pensando que voy a estigmatizar esta práctica de estimación ágil, aún estás a tiempo de hacer clic en algún otro lugar de tu navegador. Quizás aquí, mi artículo sobre “Estimaciones en los tiempos de la agilidad”, en cuya sección final decía que si sigues estimando como hace algún tiempo seguramente no estás en el camino ágil o te alejaste de este, es más, quizás ni estés haciendo estimaciones propiamente dichas. A lo que seguí con una serie de recomendaciones que terminaban con una enfática pero respetuosa propuesta de simplemente no estimes del todo, enfócate en entregar Valor, en reducir el Time to Market, en eliminar desperdicios y en mejorar continuamente.

Se trata precisamente de evolucionar, de seguir experimentando y aprendiendo de los resultados de nuestros experimentos. Ya dimos el primer paso y fue dejar de usar técnicas tradicionales que requerían de tener mucha información y de hacer mucho trabajo que, a la postre, se convertía en desperdicio para la organización o que, en general, no era de valor para nadie. El nivel de predictibilidad era muy bajo, tuve la oportunidad de comprobarlo una y otra vez hasta la desesperación durante dos décadas. Luego empezamos a usar técnicas de estimación relativa y juegos como Planning Poker nos enseñaron a hacer mejores predicciones acerca del trabajo sin generar tanto desperdicio de tiempo.

A veces es posible hacer algo sin hacerlo. Una de las formas de estimar es no estimar. Sé que para llegar a eso el camino es cuesta arriba, pero eso muchas veces es bueno, porque cuando lo logras, ves que valió la pena porque la vista es fantástica.*

Así que avancemos un poco por ese camino…

Enfócate en generar Valor, no estimes

Imagen de Nattanan Kanchanaprat en Pixabay

Motiva al Dueño de Producto o a quien sea tu “cliente” a Ordenar por Valor todo lo que quiere. Acompáñalo en el proceso. Haz que se enamore profundamente de esta forma de pensar y de hacer basada en el valor, pero sin que llegue a odiar las formas anteriores. Hay muchas técnicas para ordenar el backlog:

• En función de lo que quieran tus clientes o consumidores
• Lo que los interesados internos quieren
• Lo que creas que impactará más
• La antiquísima MoSCoW
• Por Costo-Beneficio
• RoI (Retorno de la Inversión)
• VIP (el método del servicio preferencial)
• El costo de la demora
• Puedes elaborar una matriz Valor – Complejidad  

Puedes usar una combinación de estos, por ejemplo, entre dos elementos Requeridos (MoSCoW), implementa primero el que menor costo de implementación tenga y mayor beneficio te genere (Costo-Beneficio) o el que mayor retorno de la inversión te genere (RoI); entre dos elementos que te generen el mismo RoI, construye primero el de mayor costo de la demora (CoD) o el que te haya solicitado la persona más importante para tu organización de entre tus interesados. Aunque, ojo, esta persona no siempre es la de mayor rango jerárquico.

Hazlo gradualmente, de manera orgánica. Experimenta.

Imagen tomada de https://pixabay.com/images/id-512503/

Pasa de puntos de historias a tallas de camiseta. Pero no hagas un equivalente entre una talla y un número de puntos. Sería como tratar de saltar en paracaídas con una soga atada al avión, ¡no lo vas a lograr! Si lo que quieres es “medir” la velocidad del equipo, entonces cambia la escala también: ya no serán 30 o 47 puntos, sino seis elementos Talla M u ocho talla S, por ejemplo. Más adelante, busca una forma cada vez menos cuantitativa y más cualitativa de realizar la estimación, que tienda o evolucione siempre hacia el valor del incremento de producto a entregar y se aleje de una vez por todas y para siempre del esfuerzo necesario para hacer el trabajo o de la complejidad inherente a cada elemento del producto.

Evidentemente necesitarás kilometraje ágil. Tú, tu equipo y muy probablemente tu organización ya habrán llegado, al menos, a la cima de la curva de la innovación, en este caso, de cambio de forma de pensar y de hacer las cosas “a lo ágil”. Es decir, una gran mayoría temprana y un sector de la mayoría tardía, ya han entendido de qué se trata, ya han interiorizado, practican y promueven el pensamiento ágil, los valores y principios del Manifiesto Ágil, los pilares de Colabora, Entrega, Reflexiona y Mejora del Corazón de la Agilidad; y ya hay un sistema de valores de poca o ninguna variabilidad y consistente con las prácticas empresariales como base que guía el accionar de todos o de casi todos en la empresa y en su entorno.

Algunos patrones Scrum para estimar

Imagen de Achim Scholty en Pixabay

Usa patrones Scrum como el Gradiente de granularidad. ^(II)

Hemos experimentado y sabemos que los elementos pequeños son más fáciles de estimar, pero desglosar los elementos de trabajo es mucho trabajo en sí mismo. Las estimaciones de trabajo para pequeños incrementos de producto y tareas tienen menos errores que para los más grandes por tres razones:

·    La magnitud del trabajo (y, por lo tanto, del posible error) es menor que para un incremento o tarea más grande.

·    El equipo puede comprender mejor las entregas y tareas más pequeñas que las más grandes.

·    El porcentaje de error en las entregas y tareas más pequeñas es menor que en las grandes porque hay menos elementos de adivinanzas (y el tamaño máximo de cualquier error se mitiga implícitamente).

Por lo tanto:

Divide los primeros PBI en elementos pequeños de medio Sprint o menos de trabajo para una persona (aproximadamente el 10 % del trabajo total del Sprint) cada uno. El equipo debe desglosar los PBI posteriores para que su tamaño sea proporcional a su profundidad en el backlog Producto.

Otro patrón es el del Trabajo fijo. ^(III)

Scrum divide el tiempo en dos. Hay un cronograma continuo para el análisis y el negocio, y un cronograma cíclico de Sprint para la producción. El tiempo para el análisis y la innovación es imposible de estimar y puede desarrollarse durante largos intervalos, porque surge de manera impredecible en un proceso que Steve Johnson llama "la corazonada lenta" en su libro “Where Good Ideas Come From: The Natural History of Innovation”, Capítulo III, “The Slow Hunch”.

Todo el trabajo debe tenerse en cuenta si el Dueño del producto va a utilizar la velocidad del equipo para la planificación del lanzamiento del producto, pero no todo el trabajo de desarrollo puede tener un límite de tiempo.

Así que:

Divide todo el trabajo del Equipo de Desarrollo en aquel cuya duración estiman (es decir, trabajan en el producto) y lo que no pueden estimar (como el trabajo para entender los requisitos a medida que el equipo mueve los PBI a Preparado). En cada Sprint, reserva tiempos periódicos para el trabajo no estimable, fuera del presupuesto del Sprint, y completa la mayor parte de cada tipo de trabajo que permita el bloque de tiempo.

O este otro patrón del Alto valor primero.^(IV)

Que hace alarde del antiguo y conocido refrán “más vale pájaro en mano que un ciento volando”, y hoy por hoy los desarrollos a corto plazo deberían ofrecer valor lo antes posible.

Las cosas así:

Haz que tu equipo desarrolle primero los elementos del Producto de alto valor más esenciales.

Imagen basada en “A Scrum book”. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

También usa patrones como El Clima de Ayer, Equipos que terminan más temprano aceleran más rápido e Illegitimus Non Interruptus no solo para hacer mejores predicciones de lo que planeas entregar sino también para llevar a tu equipo a niveles de desempeño grandiosos y entregar más valor en menos tiempo, quizás el doble del valor en la mitad del tiempo. Para saber más de estos y otros patrones puedes ir a:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/

Donde encontrarás sendas presentaciones para descargar y videos para ver sobre el tema.

Para finalizar

Como siempre, permite que las personas comprometidas con el trabajo decidan qué hacer respecto a la estimación. Guíalos. Muéstrales beneficios de uno u otro enfoque, de una u otra práctica. Y también perjuicios. Contrasta con el camino ágil recorrido. No es lo mismo un equipo u organización que apenas están saliendo de los enfoques tradicionales a uno que ya lleva ciertos kilómetros transitados.

Si este último es tu escenario, la próxima vez que quieras estimar algo, estima el valor de lo que vas a entregar, no el esfuerzo que te lleva realizarlo o la complejidad de lo que vas a hacer.

Y aunque no hablé de #NoEstimates, este es un movimiento, una filosofía, una visión de pensar acerca de cómo hacer algo, no es una técnica o metodología. Bueno, quizás estas ideas y propuestas constituyan un aporte a esa tendencia.

Referencias

* Basado en una frase de la película Hannah Montana (2009) que viera con mi hija Pamela, de 12 años entonces: “la vida es cuesta arriba, pero la vista es genial”.

(II) ¶59 Granularity Gradient. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

(III) ¶23 Fixed Work. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

(IV) ¶51 High Value First. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

Imagen de la portada basada en:

• Imagen de Natalia Ovcharenko en Pixabay
• Imagen de Mike Cohn en www.mountaingoatsoftware.com
• Imagen de Agile Poker Estimation Planning Cards by Clearly Agile, Inc.

La deuda de producto: cómo se manifiesta y qué hacer al respecto

The Uncomfortable Entrance - Illustration by Katerina Kamprani

Este tipo de deuda se presenta cuando el producto no constituye algo significativo para tu identidad como consumidor o usuario, para tu desarrollo personal o tu bienestar. Aquí estamos hablando de la experiencia de usuario. Es decir, si el producto no genera en sus consumidores emociones y actitudes positivas que sean capaces de impactar su estatus actual. O si esos usuarios no perciben aspectos del producto como su utilidad, la facilidad de uso y la eficiencia, entonces estamos ante una deuda en rojo.

Le faltan esos atributos tangibles e intangibles que brindan al consumidor los beneficios esperados por este y que le resuelven una necesidad específica. Con tangibles me refiero a lo que hace el producto, a la tecnología, al diseño, a la forma. Con intangibles, a los elementos emocionales que generan apego en el usuario, a su identidad de marca, a su ecosistema, a si impacta positivamente la vida de quienes lo consumen y si ese impacto es sostenible. Otra vez, estas dos clases de características es lo que hace posible una extraordinaria experiencia de consumidor, de cliente.

La deuda de producto también es interna, algo que muchas veces ni siquiera el usuario es capaz de percibir. Me refiero a la cultura de Agilidad en medio de la cual fue creado o elaborado el producto, al empoderamiento del equipo, a la felicidad de sus miembros, al foco en el cliente que pusieron todas las personas encargadas de su ideación, descubrimiento, prototipado, desarrollo y puesta en producción de ese producto.

La deuda de producto crece cuando el equipo no aprendió ni mejoró un ápice durante su desarrollo. Además, si el equipo y otros interesados no conocen al cliente, cuáles son sus necesidades o porqué deberían adquirir o usar el producto, la deuda de ese producto también se incrementa.

Si no hubo confianza en el equipo, no se le delegaron las principales responsabilidades para elaborar el producto ni se les habilitó un entorno seguro, donde el empoderamiento y la experimentación estuvieran a la orden del día, hay más deuda de producto.

Si todas las buenas ideas del producto terminan con su despliegue al mercado, todavía habrá un gran camino que recorrer, una deuda aumentada que pagar. El despliegue del producto no es el objetivo. La meta es el cliente, su satisfacción, su felicidad, mejorar su modus vivendi. Si nos quedamos en la puesta en marcha del producto, apenas si nos habremos concentrado en la salida del producto, un número de características de las cuales no sabemos cuáles serán usadas y cuáles no. Consecuencia: más deuda de producto. En cambio, si nuestro foco es el cliente y sus necesidades y la experiencia que tenga usando el producto, entonces estaremos concentrándonos en el valor, en el resultado positivo que puede entregar ese producto a la humanidad.

Otras causas de la deuda de producto:

• Siempre aplicamos las mismas prácticas en todas partes
• Siempre exigimos adherencia a actividades y procesos, ágiles o no
• Definimos la cadena de herramientas permitida
• Forzamos la estandarización en todas partes
• Creemos que el proceso habla por sí mismo
• Confiamos en el proceso más que en las personas y el equipo

Las cosas así, podríamos definir la deuda de producto como:

Deuda de Producto = Falta de Experiencia de Usuario + Falta de Tangibles (Tecnología, Diseño, Forma) + Falta de Intangibles (Emociones, Identidad de Marca) + Falta de Agilidad + Falta de Foco en el Cliente + Falta de Confianza en el Equipo + Falta de Delegación + Otros*

* Incluye aquí los que aplican para tu entorno específico

Para no incurrir en más deuda de producto

El Dueño de Producto debe:

• Definir y liderar la visión del producto.
• Investigar y probar las necesidades del cliente / mercado
• Identificar opciones de productos de alto valor.
• Hacer que los elementos del backlog estén "preparados" para su planificación y desarrollo
• Aceptar solo trabajo "terminado"
• Realizar demostraciones de producto
• Fomentar la consistencia donde esta sea importante, en todos los niveles de la organización
• Explicar siempre el valor detrás de un proceso
• Observar, aprender de y analizar el mercado.
• Compartir ideas en la organización con respecto al producto y aceptar retroalimentación oportuna
• Decidir las fechas de lanzamiento y el contenido.
• Salir al mercado (a producción) tan rápido como sea posible e ir afinando el producto a medida que recibe información de su uso
• No lanzar en la fecha, lanzar en calidad (a lo Spotify).
• Asegurarse de que el producto vaya de excelente en su salida inicial a extraordinario después del lanzamiento, afinándolo continuamente.
• Saber cuándo descontinuar o sacar el producto del mercado

El equipo de desarrollo de producto debe:

• Ser pragmático en la elección de las herramientas
• No obsesionarse con las ceremonias o eventos de un proceso o marco de trabajo, por muy ágil que este parezca. Atención a eso Scrum Másters, coaches ágiles, habilitadores ágiles, consultores Lean y estrategas Kanban, entre otros.
• Demostrar voluntad de evolucionar en función de la retroalimentación que proporcione el entorno

Toda la organización debe:

• Concentrarse en el Valor.

¡Esperen! Sobre Valor del producto hablaré en una próxima oportunidad. Hasta entonces, déjame saber en el foro tus experiencias e impresiones sobre este asunto crítico de la deuda de producto.

Créditos de la imagen de portada:

The Uncomfortable Entrance

Illustrations by Katerina Kamprani

https://www.theuncomfortable.com/portfolio/the-uncomfortable-entrance/

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

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.