Elaboración de historias de usuario centradas en comportamiento

Por Juan Daza Arévalo, @juanenlasala

Palabras clave

Historias de usuario, comportamientos, valor, épicas, temas

Intención

Esta técnica ha sido diseñada con el fin de apalancar la idea de la “oportunidad para una conversación” que viene de la mano de una historia de usuario. Que ese diálogo sea poderoso al contar con un texto donde están consignados los comportamientos que queremos acompañar con la solución que se propone.

Motivación

Las historias de usuario cuentan con un formato, una plantilla que permite un encuentro para validar qué se espera lograr en el próximo sprint. Sin embargo, el poder no radica en la forma en que se redacta, en cada historia reposan comportamientos que se desean modificar o a los que se quieren apelar cuando el usuario esté al frente de la solución. Tener presente el comportamiento como eje permite trabajar con una óptica de User Centered Design o Diseño Orientado al Usuario.

Descripción

Las historias de usuario son la respuesta a la forma tradicional en la que los “requerimientos” se convertían en un listado de tareas y acciones que, casi siempre, desembocaban en situaciones abiertas a interpretaciones, o en un listado de acciones cerradas. Son la evolución de una tarea redactada en forma de historia que recoge el verdadero problema que se desea resolver.

Los primeros rastros en la historia de las historias de usuario conducen a Steinberg & Palmer [Steinberg-Palmer 2003] y al artículo de Bill Wake [Wake 2003] en el que propone, a partir de las siglas, INVEST y SMART la construcción de historias: independientes, negociables, valiosas, estimables, pequeñas y que se puedan testear (probar) o si se toma el segundo acrónimo que sean: eSpecíficas, medibles, alcanzables, relevantes y con tiempo regulado.

En su artículo, Wake cita a Ron Jeffries y describe las historias de usuario en XP (Extreme Programming) como herramientas que deben tener tres componentes: Cards (Tarjetas) como medio físico; Conversation (Conversación) o la discusión que genera la propuesta de dicha historia, y Confirmation (Confirmación) o la manera de probar que se ha cumplido lo esperado. Es frecuente encontrar discusiones frente a las sugerencias de redactar historias de usuario independientes y valiosas y que a la vez sean pequeñas.

Justamente ese es el punto de partida de Gojko Adzic [Adzic 2014] cuando afirma que “software valioso es un concepto vago y esotérico en el campo de los usuarios de un negocio, pero el tamaño de la tarea es algo que se puede tener bajo control para un equipo de desarrollo, por eso muchos equipos terminan escogiendo tamaño sobre valor.” El valor se convierte en un adjetivo que genera dudas y cada quien apropia a su manera. Por eso surgen expresiones como “una página dinámica” para expresar lo que se desea, frases que aparecen como muestra de un problema importante de fondo.

En XP se sugiere que la historia de usuario sea escrita por el cliente. Desde otros marcos de trabajo y metodologías es una herramienta a la que se llega en conjunto, como un ejercicio colectivo perfecto para cubrir temas de experiencia de usuario (UX), prioridad, etc. Nuevamente es una apropiación que cada equipo va refinando a su modo de trabajo. Las dudas posibles del uso de historia de usuario pueden resolverse en la medida que se explica el contexto y las oportunidades asociadas a otro nivel para el proyecto, el negocio y el usuario.

Jeremy Jarrel [Jarrel 2014] describe las diferencias entre historias de usuario, temas y épicas, como un conjunto de textos que en distintos momentos describe las necesidades del proyecto. La historia de usuario dice, es una “unidad auto-contenida de trabajo acordada entre el equipo de desarrollo y el stakeholder.” Los temas, agrega, son “ideas expuestas en historias que se pueden agrupar” en atención a un tema, funcionalidades similares, etc. Mientras que las épicas “comprometen un flujo completo para un usuario” a diferencia del lugar común de verlas como historias grandes, que necesitan refinamiento.

Lo que se quiere hacer supera el tradicional guión de: "Como un [rol] yo deseo [características] para que así exista [beneficio]." porque las conversaciones deben confirmar no lo que se desea hacer sino lo que se quiere lograr. No toda acción o desarrollo apoya un objetivo. Estas conversaciones son momentos para confirmar una y otra vez qué es lo que realmente se quiere hacer. De ahí que Gojko Adzic y David Evans [Evans 2014] hablen de ver las historias de usuario como una oportunidad de “modificar comportamientos”.

¿Realmente la funcionalidad que tiene una solución apela a un comportamiento? ¿No se trata únicamente de un proceso donde el código activa tareas y funciones? Cada funcionalidad debería responder a una hipótesis o la suma de un supuesto con una medición, más una alta dosis de empatía.

Wendell [Wendell 2013] describe la forma en la que trabaja en su organización donde implementan “algunos elementos de agilidad” y se ve una correlación con el Pensamiento de Diseño o Design Thinking. En la base de todo desarrollo está un proceso de “entendimiento” que en la agilidad se ha recopilado en distintas prácticas conocidas como Inception. Un ejercicio atento de conexión con el usuario donde se identifican los problemas y posibles usos para que la solución propuesta confirme que está clara la visión que se tiene del producto o servicio.

Al apoyar procesos de desarrollo desde el diseño de la propuesta de valor, he querido darle un alcance distinto a las épicas para encontrar en ellas los comportamientos que se van a acompañar. Es imposible cambiar un comportamiento con sólo una historia de usuario pero sí se puede influenciar un comportamiento para que, poco a poco, se convierta en un hábito.

El flujo de trabajo descrito en una épica está poblado de comportamientos: miedo a entregar información, dudas por el uso de la información privada, reservas por el sentido del proceso, molestia por tener que memorizar una nueva contraseña, sospechas por la relación que se establece entre una red social y la solución que está usando, etc. Estos y otros comportamientos se van asentando a medida que las rutinas asociadas al proceso se repiten, son más sencillas, transparentes, etc.

El poder detrás de la experiencia de usuario no radica en una sensación de gusto o satisfacción, el poder se consolida si hay un comportamiento que queda satisfecho. Por eso, desde la empatía, se conversan cuáles son los comportamientos que puede tener un usuario en distintos momentos de uso de una solución. Parte de los diálogos necesarios al diseño de la épica.

Para esos diálogos diseñé un formato, una plantilla llamada LYPS como acrónimo de Love Your Epics. Por un lado, busca resignificar la idea de que una épica es nociva por no tener foco o estimación y convertirla en una oportunidad de ampliar la mirada del proyecto. Por otro, el juego de palabras y el término “lips” o labios que resuena con conversación, encuentros, “besos”, etc.

LYPS se usa en el Inception o gestación de la idea, durante el diseño de la propuesta de valor, a medida que vamos descubriendo las posibilidades de la solución que se va a programar, etc. y propone una serie de campos para ser usados con los interesados en cada fase del proyecto. Puede ser desde el equipo de desarrollo en pleno o en sesiones con cliente y desarrolladores.

Los campos descritos en la imagen se utilizan con la misma libertad de apropiación de otras herramientas ágiles. Sin embargo, el grupo debe tener en cuenta qué entiende por “comportamiento que espera modificar” porque es sobre eso que se puede medir el impacto de la solución, por ejemplo "Disminuir en un 20% la cantidad de formularios rechazados". Este camino permite oportunidades de mejora y de modificación constante de la solución.

Al respecto, y aunque este capítulo no se refiere al comportamiento humano es importante tener en cuenta que las conductas humanas y los comportamientos tienen relación y sutiles pero importantes diferencias. Una conducta se refiere a acciones asociados a un código propuesto en grupo y con implicaciones morales. El comportamiento habla de respuestas, acciones y actividades de un organismo. La conducta se refiere también a una lectura trazable en el tiempo, normalmente en una institución mientras que el comportamiento responde a interacciones inmediatas.

love your epics

Figura 4.1_. LYPS - Love your epics

LYPS ha sido usado para la identificación de comportamientos en aplicaciones móviles y sitios web para encontrar si las implementaciones confirman los números esperados. La hemos puesto en marcha usando a la par herramientas de graficación de tráfico y donde los usuarios hacen realmente click (por ejemplo http://www.crazyegg.com o https://mouseflow.com) con el fin de validar los comportamientos esperados.

La idea de encontrar un mecanismo que permita modificar, con precisión, un comportamiento humano es poco menos que una fantasía. Nada puede predecir cómo los individuos y los grupos de personas reaccionan frente a una señal o un impulso; podemos entender y anticipar algunos pero estamos siempre frente a la complejidad propia de los seres humanos. Contemplar los comportamientos es preparar los límites suficientes para contar con metas y objetivos no sólo alineados con el negocio sino con el uso de las soluciones.

En nuestros proyectos LYPS nos ha dado foco en tres aspectos que aborda Gojko Adzic [Adzic 2016] y que llama operational awareness y que en la plantilla se ven como Tiempo, Local y Humano. Los comportamientos van de la mano de esas variables que nunca podemos controlar. La incertidumbre no es otra cosa que la realidad convertida en una historia cruel cuyo autor definitivamente no nos hace caso. Por eso, antes de medir resultados nos hemos propuesto a buscar cómo confirmar comportamientos y ojalá este formato sea un aporte para una meta también difícil.