Scrumízate
Analizar continuamente las reacciones de los usuarios o clientes permite iterar y adaptar los productos y servicios a sus necesidades o deseos. La agilidad propone dinámicas y herramientas para ayudar a seguir el camino hacia aportar el máximo valor.
Los frameworks ágiles o Lean recomiendan las historias de usuario para describir estas necesidades o deseos y poder definir qué se necesita.
Como ya sabes, las historias de usuario son frases cortas y esquemáticas (como-quiero-para) que comparten todas ellas una misma forma sintáctica y que van acompañadas de un listado de criterios de validación.
Como X (rol que sea) quiero M (lo que sea) para Y (lo que sea)
Las historias de usuario responden a las preguntas:
- ¿Quién se beneficia?
- ¿Qué se requiere?
- ¿Cuál es el beneficio?
Observando las preguntas vemos que sus respuestas se centrán en el QUÉ necesita el usuario y no en el CÓMO se debe proporcionar la solución. Las historias de usuario no pretenden dar una definición completa de los requisitos y las tareas a realizar. Tenemos que verlas como una promesa a tener una conversación de equipo.
Si quieres aprender o recordar los elementos clave de las historias de usuario puedes leer este artículo.
Beneficios de escribir buenas historias de usuario
Las historias de usuario son una de las herramientas más recomendadas entre los frameworks ágiles o Lean UX. No se trata de un capricho sino fruto de la voluntad de trabajar en puntos que aporten valor.
Trabajar con historias de usuario nos aportará los siguientes beneficios:
- Definir los deseos o necesidades concretos de algunas partes del producto
- Ofrecer una visión externa del producto sin prejuicios
- Fomentar el trabajo en equipo en busca de soluciones
- Estimar el esfuerzo que se necesita para desarrollar una idea
Las historias de usuario permiten definir el mínimo producto viable y las posteriores iteraciones para mejorar o incrementar el producto. Si quieres conocer los 7 errores más comunes en la definición del mínimo producto viable puedes leer este post.
Estrategias para dividir historias de usuario
Una situación muy frecuente cuando alguien o un equipo empieza a trabajar con historias de usuario es la dificultad en construir historias lo más pequeñas posible y que aporten valor al usuario.
Ante la costumbre de trabajar con grandes definiciones de requisitos o tan siquiera usar una definición de requisitos es fácil encontrarse en situaciones en las que cuesta dividir las historias de usuario y pensar que es imposible, que su caso es especial y que puede que esta herramienta no le sirva.
A continuación describiremos cuatro estrategias para la división de las historias de usuario bajo distintos puntos de vista.
1. Descomponer por flujo de trabajo
Una buena estrategia inicial es afrontar la división de las historias de usuario bajo el flujo de trabajo que representa conseguir un objetivo.
Este enfoque requiere detectar los pasos individuales que debe seguir el usuario. Cada uno de estos pasos, si aporta valor, es una historia de usuario.
Esta estrategia nos permite crear la secuencia completa de historias por las que pasará un usuario hasta completar el objetivo final.
Ejemplo: Seleccionar un producto
- Como X quiero loguearme para que el sistema recuerde mis datos y compras previas
- Como X quiero ver la lista de productos en oferta para descubrir si estoy interesado
- Como X quiero seleccionar el producto para proceder a la compra
El error más común al aplicar esta estrategia es esconder historias de usuario, por ausencia o en los criterios de validación.
Para no caer en el error debemos asegurarnos que las historias de usuario o ítems de los criterios de validación enlazan completamente en todo lo escrito anteriormente. De no ser así seguramente estamos escondiendo alguna historia de usuario.
2. Descomponer por medio del flujo feliz/infeliz
El uso de una aplicación no siempre funciona todo, algunas veces aparecen errores. La estrategia de definir por flujo feliz/infeliz permite definir las historias de usuario cuando todo va bien y cuando las cosas van mal.
Este enfoque nos obliga a definir los pasos que seguirá el usuario cuando todo funciona correctamente y todos los puntos en los que se puede generar un error.
Esta estrategia permite detectar todos los posibles errores en un proceso y a definir la comunicación de los errores al usuario.
Ejemplo: Login
- Como X quiero iniciar sesión para Y (feliz)
- Como X quiero restablecer mi contraseña para Y (infeliz)
Recomendamos la estrategia de flujo feliz/infeliz a la estrategia anterior, por flujo de trabajo. En el primer caso definimos el flujo feliz y una vez terminado lo completamos con la vista puesta al flujo infeliz.
3. Descomponer por parámetros de entrada
La estrategia de descomponer por parámetros de entrada tiene como objetivo no esconder grandes funcionalidades entre los criterios de validación.
Un ejemplo típico es en la definición de sistemas de búsquedas de productos y los distintos filtros de configuración de búsqueda y mostrado de resultados. Existe la tentación de describir estos filtros y opciones entre los criterios de validación.
Por desgracia es un clásico encontrarse un criterio de validación que indica que el sistema de búsqueda de productos tendrá accesibles un conjunto de filtros, citar los más obvios y dejar completamente abierta su definición con puntos suspensivos.
Ejemplo: Búsqueda de productos
- Como X quiero buscar productos por su referencia para Y
- Como X quiero buscar productos por su precio para Y
La estrategia de descomponer por parámetros de entrada nos obliga a definir una historia de usuario para cada uno de los parámetros de entrada. Siguiendo el ejemplo de búsqueda de productos debemos entender que cada uno de los filtros debemos contemplarlo como una historia de usuario independiente.
4. Descomponer por operaciones
La estrategia de descomponer por operaciones nos obliga a definir todas las acciones que un usuario puede realizar alrededor de una de las entidades del sistema.
Las operaciones típicas de una entidad son dar de alta, dar de baja, modificar su valor y realizar consultas de lectura (CRUD). Estas operaciones son prácticamente imprescindibles para cualquier apartado de administración.
Recomendamos completar la estrategia de descomponer por operaciones con la estrategia de flujo feliz/infeliz para poder definir la gestión de errores en las acciones de administración.
Ejemplo: Gestión de elementos
- Como X quiero dar de alta productos para Y
- Como X quiero eliminar productos para Y
- Como X quiero listar productos para Y
- Como X quiero modificar un producto para Y
La estrategia de descomponer por operaciones nos facilita no dejarnos ninguna operación básica sobre cualquiera de las entidades de nuestro producto.
Un buen truco es aprovechar cada vez que aparece una entidad nueva en el producto utilizar esta estrategia para definir todas las acciones disponibles para los distintos roles de usuario de esa entidad.
Conclusiones
Las historias de usuario son una herramienta recomendada para equipos que trabajen siguiendo las recomendaciones de frameworks agile, como scrum, en el desarrollo de productos y aplicaciones.
Las características principales de las historias de usuario son:
- Ser lo más pequeñas posible
- Aportar el máximo valor al usuario
- Definir una necesidad completa para el producto
Es fácil caer en errores en la definición de las historias de usuario cuando se empieza a usar esta herramienta para la definición de necesidades. Los errores más típicos son escribir historias de usuario demasiado largas o esconder historias dentro de la lista de criterios de validación.
Este post explica cuatro técnicas para escribir buenas historias de usuario. Utilizar las cuatro estrategias debidamente cruzadas a lo largo del proceso nos ayudará a prevenir problemas de definición futuros durante el desarrollo de producto.
Los problemas futuros sin una correcta división y definición de las historias de usuario son:
- Afrontar un mínimo producto viable demasiado grande
- Desarrollar soluciones de necesidades demasiado genéricas
- No identificar donde reside el auténtico valor para el usuario
- No planificar correctamente la evolución del producto
Si quieres conocer más técnicas para la división de historias de usuario para hacerlas lo más pequeñas posible y aportando el máximo valor puedes leer este artículo de Javier Garzás.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
