intive Argentina Blog

¿Cómo escribir historias de usuario?

Desde antaño el hombre cuenta historias. Desde las pinturas rupestres, desde que comenzó a reunirse alrededor del fuego, nos decía Pablo Sánchez, el hombre se interesa por los relatos. “Contar historias nos une a lo largo del tiempo, atravesando distintas culturas”. Y es algo que hoy aplicamos a nuestros proyectos de software. La mejor manera de entender lo que el cliente quiere sigue siendo la de relatar historias. Tal vez porque es la forma más ancestral de comunicarnos, creemos que es el mejor camino para entender qué valor quiere recibir el usuario del producto que estamos construyendo. Por eso, Pablo, agile coach en intive-FDV, decidió explicarnos en una charla todo sobre las user stories.

User stories

Las historias comenzaron a utilizarse en el desarrollo de software dentro de un marco metodológico llamado Extreme Programming. En esta forma de trabajo la premisa radica en la posibilidad de cambiar los requerimientos a medida que el producto evoluciona. Lo mismo sucede con las historias de usuario que hoy aplicamos en nuestro enfoque ágil: evolucionan mientras el proyecto se desarrolla.

¿Cómo elaboramos una historia de usuario de manera correcta?

Para que una historia de usuario esté bien escrita se recurre a una regla mnemotécnica conocida como “I.N.V.E.S.T.”. Veamos a continuación qué significa cada sigla que la compone:

1-02

I: independiente. Cada historia de usuario debería poder desarrollarse de esta manera, sin crear una dependencia con otros parámetros.

N: negociable. Si la historia es demasiado grande o tiene elementos de menos o de más, se debería poder negociar. La idea es que evolucione de manera dinámica a través de una constante negociación de los involucrados.

V: valioso. Esta sigla nos recuerda a la pregunta ¿para qué?. La respuesta es el valor que le estamos dando al usuario.

E: estimar. Lo ideal es que la historia sea lo suficientemente clara para poder conocer su alcance y estimar esfuerzos.

S: pequeña (del inglés: “small”). Para que podamos trabajar sobre una historia dentro de un sprint. El desafío es lograr la mínima historia posible.

T: test. Básicamente, que la historia se pueda probar.

La notación de una user story

Mike Cohn escribió un libro que Pablo considera “casi una biblia” sobre el tema: “User Stories Applied for Agile Software Development”. También, plantea una notación que lleva su nombre y que sirve como modelo o plantilla para elaborar la descripción de cualquier historia. Esta modalidad resulta de gran ayuda a la hora de priorizar las historias, ya que además de describir la funcionalidad en sí, explicita perfectamente el valor de cada una de ellas y a quién le aporta ese valor.

1-03

Otra opción de template, que representa una evolución de la anterior es sumar al template anterior (como si fuese el reverso de la tarjeta) los criterios de aceptación o el conjunto de condiciones según las cuales hay que probar la historia para asegurarse que está desarrollada en forma correcta, es la siguiente:

template-2-es

Las plantillas son de mucha utilidad para automatizar o estandarizar el trabajo de quien escribe.

¿Y quién las escribe?

Cuando se trabaja según el framework Scrum, se suele indicar que las historias de usuario pertenecen al Product Owner. Lo cierto, dice Pablo, es que son de todo el mundo involucrado en el desarrollo del producto. El “PO” es el que tiene que priorizar o aprobarlas, pero las historias van modificándose bajo la influencia de quienes forman parte del equipo de desarrollo: todos son responsables de preguntar y preguntarse a sí mismos sobre la historia. Parte de la naturaleza de la historia también apunta a que el cliente la valide, muchas veces a través del “PO”.

En definitiva, las user stories podrían ser consideradas guías para tener en claro qué es lo que se necesita, para priorizar y redefinir tareas. Como bien aportó Cristina hacia el final de nuestra charla, podemos considerarlas una excusa para tener conversaciones poderosas dentro del equipo sobre la funcionalidad y el valor que se entrega. Muchas veces, cuando perdemos de vista el valor del negocio, las user stories finalmente nos lo terminan recordando.

Paula Becchetti

Paula es la editora del blog de intive – FDV. Licenciada en Comunicación Audiovisual de la Universidad Nacional de San Martín (UNSAM), se destaca como Content Manager especializada en blogs, contenido web, email marketing y social media. Su amplia experiencia en la industria del software la hace muy valiosa a la hora de traducir contenidos técnicos a un lenguaje coloquial. Según sus propias palabras: “Me conecto con el mundo por medio de la tecnología, pero también a través de todo aquello que respira, del deporte, de la música y de mis viajes”.

Deja un comentario