Historias de Usuario en Scrum. ¿Qué son y para qué sirven?

Vamos a definir qué es una Historia de Usuario (User Story), y para que te sirve elaborarlas dentro de Scrum.

¿Qué son las Historia de Usuario?

Las Historias de Usuario (User Story) buscan obtener los datos de quién, qué y porqué. Este requisito es necesario para poder conocer mejor las necesidades de nuestro cliente.

¿Quién es nuestro cliente?, ¿Qué quiere?, y ¿Por qué? Con estas preguntas básicas podremos adentrarnos más en lo que nuestro cliente busca, y es la forma que tenemos nosotros  para hacer que el proyecto pueda desarrollarse de la mejor manera y siguiendo los requerimientos de nuestro cliente o usuario. Que será quién finalmente haga uso del proyecto en que estemos trabajando.

¿Para qué sirven las Historias de Usuario?

Historias de Usuario se realizan de manera simple, pero tienen un alto impacto dentro del proyecto, ya que si no se realiza una buena Historia de Usuario, será más difícil que podamos comprender a nuestros clientes.

No es tan difícil como puede sonar, de hecho las Historias de Usuario pueden ser realizadas en notas de papel o post it. Conservando siempre la información más relevante.  Cabe destacar que las Historias de Usuario que se elaboren, siempre deben ser aprobadas por el Propietario del Producto (Product Owner), donde para ser aprobadas se harán técnicas de estimación.

Es claro que al realizar las historias de usuario se puede mezclar la subjetividad, de hecho las historias de usuario son subjetivas, ya que estarán interpretadas por una persona, y esas persona tiene un imaginario, un bagaje cultural por el cual se guía, entonces para eso existe algo que se llama Criterios de Aceptación.

Por medio de ellos nos podremos guiar para obtener la objetividad necesaria y requerida para que una historia de usuario sea considera como “Lista” o no, durante la Revisión de Sprint. Y resultando eso en claridad al equipo sobre que esperar de esa historia de usuario.

Estás historias de usuario son diseñadas con el fin de que nosotros podamos entender y garantizar que los requisitos que el cliente nos pide, estén claramente representados ahí. Además de que ayudará a que todo el Scrum Team pueda entender mejor, y si hay alguna duda, resolverla en el momento.

Todas estas historias de usuario pasarán a formar épicas y después a formar parte del Prioritized Product Backlog.

¿Cómo debe ser una Historia de Usuario?

Las Historias de Usuario deben tener una organización específica, pero sencilla a la vez. Para poder documentar todos los requisitos y funciones deseados por parte de nuestro cliente final.

Estos requisitos, deben ser concisos, simples y fáciles de comprender por todos. Ya que de esto se derivará que exista una comunicación efectiva más eficaz entre todos y como consecuencia habrá una mejor estimación.

Nota: para rastrear las historias de usuario, existe algo llamado Index Cards.

Ejemplo de una Historia de Usuario

Como persona <ROL/PERSONA>, yo debería poder ser capaz de <REQUISITO> para que <BENEFICIO>

Ahora trasladémoslo en un ejemplo real:

“Como comprador de la aplicación, yo debería ser capaz de restablecer “undo” un número de veces seleccionado para poder llegar incluso hasta el inicio, o medio sin perder los avances.