¿Cómo dividir una historia de usuario por pasos de flujo de trabajo?

Es usual que cuando refinemos una historia de usuario que tiene un flujo de trabajo asociado descubramos que este la haga más compleja de lo que hubiéramos imaginado. Esta estrategia de división pasa por encontrar la historia MPV (Mínimo Producto Viable) y las historias incrementales necesarias para cubrir la historia original.

En algunas ocasiones el mayor valor está en el paso inicial y en el paso final del flujo de trabajo; los pasos intermedios agregan valor, pero pueden dejarse para más adelante. La historia con el paso inicial y la con el paso final formarían el MPV. La estrategia de división se basaría en los pasos o grupos de pasos que podamos agregar independientemente a posteriori.

Un flujo de trabajo ofrece una estrategia de
división excelente - cortesía de Pixabay

En otras historias de usuario todo el flujo de trabajo es necesario y el MPV ha de ser un corte fino de todo el flujo. La estrategia de división se basaría en agregar complejidad a través de historias que añadan lonchas finas al flujo de trabajo.

También nos encontraremos con historias de usuario en las que para algunos pasos del flujo de trabajo haya varias alternativas o caminos posibles. En esta situación podemos enfocar el MPV empezando por un único camino, el de máximo valor, y basar la estrategia de división en los diferentes caminos posibles.

La división por flujos de trabajo aporta el gran beneficio de mejorar el entendimiento de la funcionalidad, lo que a su vez facilita la definición del MPV.

¿Cuándo aplicarla?

Cuando la historia de usuario involucra un flujo de trabajo de algún tipo.

Ejemplo de una historia de usuario para una tienda on-line:

Como comprador

Quiero pagar los artículos de mi carrito de la compra

Para poder recibirlos en mi casa

División considerando los pasos del flujo de trabajo: MPV

Como comprador

Quiero confirmar y revisar mi carrito de la compra

Para poder confirmar antes de pagar

Como comprador

Quiero utilizar PayPal

Para poder informar de forma automática mis datos personales
y la dirección de envío y efectuar el pago

Incremento 1

Como comprador

Quiero identificarme a través de mi cuenta de Facebook

Para poder informar de forma automática mis datos personales y la dirección de envío

Como comprador

Quiero utilizar una tarjeta de crédito

Para poder efectuar el pago

Incremento 2

Como comprador

Quiero utilizar una transferencia bancaria

Para poder efectuar el pago

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

¿Cómo dividir una historia de usuario por roles?

Una de las primeras consideraciones al escribir una historia de usuario es sobre el rol para el cual la escribimos. Algunas historias pueden ser consumidas por varios roles, y probablemente de formas ligeramente distintas. Estos roles suelen estar representados por diferentes User-Persona que reciben valor de la historia de usuario de distintas maneras. La división por roles aplica cuando hay más de un rol receptor del valor descrito en la historia de usuario.

Imaginemos una web de reserva de restaurantes que va dirigida a dos públicos o roles: clientes comunes y clientes VIP. Probablemente el comportamiento de la reserva para uno u otro rol sea distinta, por tanto un Propietario del Producto encuentra en la división por roles una manera de dividir, priorizar y por ende entregar valor antes.

¿Cuándo aplicarla?

Cuando la historia involucra un conjunto de roles o grupos que realizan ciertas partes de la funcionalidad.

Ejemplo de una historia de usuario de un periódico on-line:

Como área responsable de noticias

Quiero publicar nuevos artículos en nuestra página web

Para poder atraer a nuestros clientes y tengan un aliciente para regresar periódicamente

División considerando los distintos roles involucrados en la funcionalidad:

Como cliente

Quiero leer nuevos artículos

Para poder estar informado de eventos importantes

Como periodista

Quiero escribir nuevos artículos

Para poder atraer a nuestros clientes

Como diseñador

Quiero aplicar los estilos corporativos a los artículos nuevos

Para poder integrarlos en el look&feel de nuestra página web

Como editor

Quiero revisar artículos nuevos antes de publicarlos en nuestra página web

Para poder prevenir errores

Como responsable audiovisuales

Quiero incluir fotografías y vídeos en los artículos nuevos

Para poder registrar las escenas de la noticia

Tres roles del ejemplo que con sumen la historia original: diseñador, responsable audiovisuales y editor - cortesía de Pixabay

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

¿Cómo dividir una historia de usuario por operaciones?

La división por operaciones es indicada para aquellas historias de usuario que involucren operaciones, ofreciéndonos así una forma natural de dividirlas en implementaciones independientes de cada operación asociada.

Pensemos en historias de usuario sobre entidades como artículos, pedidos, tarifas, usuarios, etc., todas ellas asociadas a operaciones tipo CRUD (CRUD - Create, Read, Update & Delete). En este caso el Propietario del Producto puede llevar al equipo sólo las funcionalidades más prioritarias o complejas, como el alta de un artículo por ejemplo, mientras que otras, que son poco frecuentes, las puede dejar para más adelante, como por ejemplo eliminar o actualizar un artículo, que mientras no se desarrolle, se puede efectuar directamente sobre la base de datos (BBDD). 

¿Cuándo aplicarla?

Cuando una historia de usuario involucre operaciones, por ejemplo si menciona la palabra "gestionar" nos está indicando que cubre múltiples operaciones; como por ejemplo las típicas de alta, lectura, modificación y baja (CRUD - Create, Read, Update & Delete), u otras como "configurar" y "gestionar".

Ejemplo de una historia de usuario para un carrito de la compra:

Como comprador on-line de libros

Quiero gestionar los libros que voy eligiendo en un carrito de la compra

Para poder realizar la compra con mi decisión final

División considerando las operaciones individuales (CRUD):

Como comprador on-line de libros

Quiero añadir libros nuevos a mi carrito de la compra

Para poder tener visibilidad sobre los libros elegidos

y una vez agotado mi presupuesto efectuar la compra de esos libros

Como comprador on-line de libros

Quiero poder consultar mi carrito de la compra

Para poder saber lo que he elegido hasta el momento

Como comprador on-line de libros

Quiero poder actualizar las unidades de cada libro

Para poder comprar varios ejemplares de un mismo libro

Como comprador on-line de libros

Quiero poder eliminar libros de mi carrito de la compra

Para poder efectuar una compra de los libros más importantes para mi

y que la compra se ajuste a mi presupuesto

Añadir es "la" funcionalidad - cortesía de Pixbay

Démonos cuenta que desde la perspectiva del valor de negocio el añadir libros al carrito de la compra es la funcionalidad más prioritaria.

Si abriéramos nuestra tienda con esa única funcionalidad quizá habría compradores que puedan estar sorprendidos o molestos por la precariedad de la tienda, pero seríamos los primeros en apuntarnos a una oportunidad de negocio emergente de venta de libros on-line.

Por otro lado, lo quieren nuestros compradores es encontrar los libros que buscan y comprarlos, y aunque nuestra funcionalidad fuera precaria, si han logrado lo que buscaban, van a volver.

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

¿Cómo dividir una historia de usuario por compatibilidad de navegador?

Esta estrategia propone dividir las historias de usuario por la diversidad de navegadores de internet por los cuales un usuario puede interactuar con la página web.

Las aplicaciones web a menudo tienen que trabajar con diferentes navegadores (Chrome, Firefox, Edge, ...), los más modernos tienden a ser más compatibles con los estándares y los más antiguos suelen necesitar de personalizaciones para que todo funcione correctamente.

Esta estrategia es una oportunidad de división que le permite al Propietario del Producto priorizar y así ayudar al equipo a dedicar tiempo y esfuerzo a la funcionalidad de más valor en cada momento. Probablemente un alto porcentaje de usuarios de un tienda on-line accedan con Chrome, y probablemente los usuarios de una intranet de una gran multinacional cargada de legacy accedan mediante Internet Explorer. Focalizándonos en el navegador más utilizado podemos entregar valor antes.

¿Cuándo aplicarla?

Cuando tengamos historias para aplicaciones web que deban funcionar en distintos navegadores.

Ejemplo de una web de venta on-line de artículos de belleza:

Como comprador

Quiero ver los detalles del producto

Para poder decidir si es lo que quiero comprar

División considerando los diferentes navegadores donde se debe poder ver la funcionalidad:

Como comprador
Quiero ver los detalles del producto en el navegador moderno Edge
Para poder decidir si es lo que quiero comprar

Como comprador con un ordenador vintage
Quiero ver los detalles del producto en Internet Explorer 7
Para poder decidir si es lo que quiero comprar

Como comprador con un móvil iPhone
Quiero ver los detalles del producto en mi navegador Safari
Para poder decidir si es lo que quiero comprar

Las estadísticas del blog marcan que la combinación de Chrome y Windows son la preferida de los lectores, por tanto nuevas historias de usuario pueden estar priorizadas según esta combinación

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

¿Qué podría ser una guía para el trabajo remoto?

#YoMeQuedoEnCasa y #YoTrabajoEnCasa, gracias Belén @bgcampa

Uno de los grandes aprendizajes del confinamiento por el COVID-19 es el haber impulsado verdaderamente el teletrabajo, un teletrabajo distribuido en el día a día en todas sus dimensiones. Los trabajadores del conocimiento llevamos meses trabajando en casa y nos coordinamos y comunicamos a través videoconferencias y herramientas colaborativas digitales.

Recordemos que no es lo mismo informar que comunicar, comunicar implica que la parte que da el mensaje tiene la responsabilidad de asegurarse que el mensaje llegué y se entienda correctamente. Actualmente la comunicación a través de los medios digitales conlleva un paradigma diferente y más que nunca la comunicación efectiva se ha vuelto crítica, tanto entre iguales como entre líderes y equipos.

Asistí a un meetup de Scaling Agile New York que trató sobre "Leading your organization in a remote environment (Agile & non-Agile)" en el que Bridgette Wilson de ezTagile expuso entre otras una guía para una comunicación efectiva en la situación actual.

La comunicación efectiva en el trabajo remoto viene marcada por 7 puntos clave:

• Invertir en tecnologías de mensajería que fomenten la colaboración: Si estamos teletrabajando y queremos ser productivos a través de una comunicación efectiva, necesitamos dotar a las personas de las mejores infraestructuras de comunicación posibles; necesitamos todo el hardware y software necesario para que las videoconferencias y los tableros virtuales funcionen eficientemente y sean fáciles de manejar. El coste de retraso por no dotar a todo el ecosistema de teletrabajo de las herramientas adecuadas puede ser muy alto en comparación con la dotación de esas infraestructuras.
• Establecer pautas para la comunicación: Colaborar de forma remota requiere acuerdos sociales adicionales o complementarios a las reuniones y eventos presenciales. Por ejemplo para fortalecer la comunicación en las videoconferencias es adecuado:
• Tener el vídeo encendido en la medida de lo posible, vernos permite leer gestos y expresiones faciales que nos acercan y nos conectan, potenciado así la comunicación sincrona.
• Tener el audio apagado mientras no hablemos para evitar posibles interferencias y ruidos ambientales que rodean a los asistentes.
• Levantar la mano para pedir turno para hablar o preguntar.
• Pausas frecuentes explícitas, como la técnica del pomodoro de 25 minutos por ejemplo, para que todos mantengamos la atención y estemos presentes.
• Asegurar clarificar las expectativas a los equipos: Para que nuestros equipos y sus miembros entiendan de qué están formando parte y fomentar su participación activa, es necesario hacerles entender la misión que les estamos encomendando y las expectativas que tenemos.
• Puntos de seguimiento individuales posteriores con los miembros de equipo: En presencial las conversaciones conllevan muchas comunicaciones en paralelo que alinean a las diferentes personas que participan, en remoto, y con la consecuente desconexión, es necesario cuidar de que las personas no diverjan en sus acciones con respecto a la misión del mensaje.
• Pedir feedback sobre la situación remota: Trata de aplicar la mejora continua y refinar continuamente la comunicación; hemos de encontrar nuestra receta para la comunicación más efectiva posible, y para ello hemos de tomar feedback de todos los implicados y buscar oportunidades de mejora de forma frecuente.
• Sobrecomunicar y ser claramente explícito: En eventos remotos ocurren momentos de personas en sombra, por ejemplo una distracción en su ubicación o una caída de conexión de la que no nos damos cuenta. En una sala presencial sabemos quienes están presentes y sabemos si ocurre algo. En remoto no tenemos esa visión completa de la sala y por tanto hemos de lanzar el mensaje con la mayor claridad posible, y repetirlo hasta que sintamos que ha llegado a todos.
• Transparencia, alineamiento y visualizar el trabajo: Haciendo visible toda información significativa de forma transparente en tableros virtuales o herramientas que permitan tanto una visión agregada como detallada, reforzaremos la comunicación y el alineamiento en todo el equipo.

"Leading your organization in a remote environment (Agile & non-Agile)" en el que Bridgette Wilson

¿Se pueden usar historias de usuario para describir elementos de calidad para el producto?

Historia de usuario de búsqueda de libros

Recientemente tuvimos un interesantísimo debate sobre una pretendida historia de usuario, sobre si lo es o si no lo es:

Como lector de libros

Quiero que la búsqueda libros sea más rápida

Para poder evitar tener que esperar tanto

A priori tiene toda la pinta de una historia de usuario, ¿verdad? La primera pregunta que nos debemos de hacer es si esta historia es algo que realmente quiera un lector.

¿Un lector de verdad quiere que mejoremos los tiempos de respuesta de nuestra tienda on-line? o, ¿más bien quiere encontrar el libro que busca y poder comprarlo? No me imagino un lector pidiendo a Amazon que acelere su proceso de búsqueda. Si encuentra el libro en nuestra tienda on-line, aunque excesivamente lenta, pensará que somos unos chapuzas, pero como ha logrado el libro que quería volverá en el futuro... eso si mientras tanto no ha encontrado una tienda on-linea más rápida que tenga los libros de su interés. Si no ha encontrado el libro probablemente no vuelva a nuestra tienda on-linea nunca más.

Si consideramos la historia incial del post como una historia de usuario, lo que estamos haciendo es trasladar nuestra falta de calidad al lector... y eso desde luego no nos va a hacer competitivos ni a crear buenas experiencias de usuario.

Por tanto podemos concluir que nuestro ejemplo no es una historia de usuario. Si puede ser una historia técnica, algo que hemos de hacer para mejorar la experiencia del usuario. Somos nosotros, no los lectores, quienes debemos de descubrir nuestras debilidades. Podemos detectar el problema en tiempos de respuesta a través pruebas de rendimiento en entornos de test o de staging, lo importante es que sea antes de liberar la funcionalidad de búsqueda a producción.

Si la problemática ya está en producción podemos analizar el comportamiento del software y la experiencia del usuario mediante herramientas como google analytics; rendimiento del segmento de usuarios, grabar sesiones y monitorizar contenidos visitados. Podemos detectarlo también en una encuesta a final de cada compra; si me imagino a un lector dando feedback de un tiempo de espera excesivo en la encuesta post-compra que hace Amazon.

Lo que ha de quedar claro es que los que tenemos interés en tener un tiempo de respuesta adecuado somos nosotros, no el lector. Por tanto si hemos detectado esa carencia podemos corregirla mediante una historia técnica que luego se convierta en un requerimiento no funcional que probablemente aplique al resto de funcionalidades de nuestra tienda on-line.

La historia técnica necesaria para dotar al sistema de los tiempos de respuesta adecuados podría ser la siguiente:

Rediseñar la arquitectura del sistema que sustenta la web on-line

para que soporte tiempos de respuesta <200 milisegundos

en situaciones de alta concurrencia por encima de los 100 usuarios

Por tanto la forma correcta para la problemática descrita en el post sería de un requerimiento no funcional para una historia de usuario como la que sigue:

Como lector de libros
Quiero poder explorar libros

Para poder escoger el que voy comprar

con el siguiente requerimiento no funcional:

Paso 1

Nombre: usabilidad.rendimiento

Escala: milisegundos entre que el lector clica "buscar" y se le presenta la página con el resultado

Métrica: promedio de los tiempos de búsqueda de libros

Paso 2

Objetivo: <200 milisegundos (lo que Google considera como tiempo de respuesta máximo)

Restricción: >3000 milisegundos (cuando el lector empieza a sentir ansiedad)

Línea base: 1800 milisegundos

Quiero dar mis agradecimientos a Sara y a Miguel por el debate enriquecedor que tuvimos para que pueda escribir este post :-)

¿Cuáles son las ventajas de las historias de usuario?

Historia de usuario - cortesía de freepng.es

Resulta que las historias de usuario son la mejor forma para fomentar la comunicación entre las diferentes partes que intervienen en la construcción de un producto, desde quienes vayan a consumir las funcionalidades que describen hasta los que construyen esas funcionalidades: cliente, Propietario del Producto y equipo de desarrollo.

Hemos desarrollado dos formas de comunicación para recoger y transmitir requisitos, cada una con sus características:

Comunicaciones escritas

• Proporcionan un registro permanente
• Se pueden compartir más fácilmente con grupos y personal remoto
• Se pueden pensar y repensar bien y de forma completa
• Se pueden malinterpretar fácilmente

Comunicaciones verbales

• Podemos recibir feedback de inmediato
• Son dinámicas, adaptamos automáticamente la conversación para maximizar la transmisión del contenido
• Se adaptan fácilmente a nuevos desarrollos
• Provocan ideas nuevas
• Se alcanza fácilmente comprensión y claridad comunes

Las historias de usuario combinan las fortalezas de ambas formas de comunicar, la escrita y la verbal, lo que hace que presenten varias ventajas para utilizarlas como elementos de la pila de producto:

• Proporcionan algo de documentación, pero lo que es más importante es que fomentan la conversación y el debate
• Fomentan la interacción y colaboración entre todos interesados y el equipo ágil al completo
• Son en el lenguaje del usuario y por tanto mantienen una relación cercana con el cliente
• Involucran y captan al cliente para el proceso y para el producto
• Por su naturaleza son independientes
• Facilitan la planificación e implementación
• Son ideales para proyectos con requisitos volátiles o no muy claros
• Alientan el aplazamiento de los detalles hasta el último momento responsable
• Son pequeñas y por tanto fáciles trabajar
• Permiten dividir los proyectos en pequeñas entregas
• Permiten estimar fácilmente el esfuerzo de desarrollo de las mismas
• Funcionan para el desarrollo iterativo ya que al ser pequeñas estas representan requisitos del modelo de negocio que pueden implementarse rápidamente (días o semanas)
• Necesitan poco mantenimiento