Las Historias de Usuario (User Stories) son una de las técnicas peor entendidas en los equipos ágiles. Muchas empresas creen que son parte de Scrum, otros piensan que el famoso como-quiero-para son clave de las Historias de Usuario, y hay quienes lo usan como plantilla para tomar requisitos.
Repasamos todos los mitos y leyendas sobre las Historias de Usuario y cuándo usarlas ¡Comenzamos!
Scrum y las Historias de Usuario
Las Historias de Usuario nacen de eXtremme Programming (XP) tiempo antes del manifiesto Agile. Su función es proporcionar una manera diferente de tomar requisitos y que los Developers mejoren sus resultados al entregar valor.
Scrum evita prescribir cómo tomar requisitos. Scrum se centra en la entrega, el hacer delivery, y deja que el Scrum Team descubra lo que hay que hacer a su criterio. Por eso, Las Historias de Usuario no se encuentran recogidas en Scrum. Las Historias de Usuario son complementarias y deben evitarse en ciertas situaciones.
En Scrum, los elementos del Product Backlog son los Product Backlog Items (PBIs) y pueden ser Historias de Usuario, requisitos, Requisitos no funcionales o documentos. Cualquier trabajo que haya que realizar estará recogido.
Qué son las Historias de Usuario
Las Historias de Usuario son una técnica diferente de entender el trabajo que haremos. Son escritos desde la perspectiva del usuario, a diferencia de los análisis tradicionales que se centran en describir cómo funciona el producto. De hecho, en la situación más ideal, son los usuarios finales los que realmente escriben las Historias de Usuario (aunque es poco habitual).
Las Historias de Usuario describen como el usuario se beneficia de nuestro producto para obtener un resultado. Se busca que sean cortas y que dispongan de criterios de aceptación que nos ayuden a validar que están finalizadas.
Están compuestas por dos partes, una primera que describe el problema a resolver y la segunda con los citados criterios. La descripción del problema suele ser algo ambigua y explica quién es la persona que realiza la acción y su motivación. La segunda es más cerrada. Las Historias de Usuario deben ser desarrolladas mediante conversaciones, son el resultado de un trabajo conjunto entre el solicitante y las personas que van a resolver el problema.
Gherkin y las Historias de Usuario
Uno de los grandes males de las Historias de Usuario es considerarla una plantilla de toma de requisitos. Muchos equipos usan el formato Gherkin para escribir las Historias de Usuario:
Cómo…[tipo de usuario]
Quiero… [necesidad a cubrir]
Para… [motivación]
Este formato estructura muy bien la información y es muy útil para ciertas técnicas de desarrollo como TDD. Eso sí, el formato no es obligatorio y debemos entender muy bien la filosofía de las HdU.
¿Cuándo usar Historias de Usuario?
Debemos evitar usar Historias de Usuario para describir todos los problemas que queramos resolver. Las Historias de Usuario carecen de sentido para describir requisitos técnicos o fallos (Bugs).
Para que sean útiles, las Historias de Usuario necesitan:
- Tener usuarios identificados
- Disponer de un acceso cercano a los usuarios
- Entender que los requisitos se deben refinar
- Comunicación fluida en el equipo de desarrollo para entender y mejorar su comprensión
- Ser capaces de describir acciones que hará nuestro usuario
Recordemos que la gran diferencia entre las Historias de Usuario y los requisitos tradicionales es que describen cómo el usuario interactúa con el sistema frente a una descripción del propio sistema.
Versión Tradicional:
En la zona superior existirá un botón que muestra la pantalla con las ventas trimestrales
Historia de Usuario:
Cómo cliente habitual
Quiero ver mis ventas trimestrales
Para entender mi negocio
Escenario #1 Cliente Habitual
Dado un cliente con ventas durante varios meses
Cuando pulsamos en el botón de ventas
Entonces veremos las ventas de los últimos 3 meses con estadísticas
Escenario #2 Cliente Nuevo
Dado un cliente nuevo que no tiene ventas
Cuando pulsamos en el botón de ventas
Entonces visualizamos un mensaje “aquí están tus ventas futuras”
Por tanto, evita usar Historias de Usuario para todo y aplicarlas cuando queramos descubrir la experiencia de usuario que vamos a brindar a nuestro usuario.
Y tú, ¿Cuándo usas Historias de Usuario?
