¿Cómo definir historias de usuario?
En equipos donde se desarrolla con metodologías ágiles como Scrum, Lean Startup o Design Thinking es necesario crear soluciones rápidas y dejar de lado procesos de gestión tradicionales.
Las historias de usuario son parte de las herramientas ágiles, como muchas otras, a la hora de definir un Sprint Planning y poder abordar un Sprint.
En ellas se debe describir la tarea que el usuario quiere realizar y su finalidad a un alto nivel para que los desarrolladores puedan estimar el esfuerzo que implica la implementación de dicha tarea.
“Una historia de usuario tiene que ser como un tuit.”
Hacer una buena historia de usuario y poder garantizar que estas ofrecen valor al negocio debe cumplir los criterios de la metodología INVEST.
¿Qué es INVEST?
INVEST son las iniciales de seis cualidades que se aplicarán en cada historia y que hará muy probable que estén listas para empezar a desarrollar.
I de Independiente
La historia puede ser entregada independientemente de otras historias. Es conveniente que cada historia de usuario pueda ser planificada e implementada en cualquier orden, totalmente independientes unas de las otras.
N de Negociable
Las historias deben ser negociables ya que sus detalles serán acordados con el cliente o el usuario durante la fase de definición. Por tanto, se debe evitar descripciones demasiado largas porque limitaría la conversación acerca de las mismas.
V de Valiosa
Cada historia que se entrega debe ofrecer valor al cliente o al usuario. Eso significa que debe haber cumplido con las expectativas esperadas y con lo que realmente se necesitaba.
E de Estimable
Una buena historia de usuario debe de poder ser estimada con la precisión suficiente para ayudar al cliente o usuario a priorizar y planificar su implementación.
Habitualmente, la estimación la realizará el equipo de desarrollo y estará directamente relacionada con el tamaño de la historia de usuario (una historia de usuario de gran tamaño es más difícil de estimar) y con el conocimiento y experiencia del equipo.
S de Small
Como más pequeñas son las historias más fáciles son de entender para el equipo y más asequibles de entregar. Así como, cuanto más pequeña es una historia menor es el riesgo.
T de Testeable
Cualquier historia de usuario debería ser capaz de ser probada. Es decir, si el cliente o usuario no sabe cómo testearlo significa que no es una historia clara o que no es valiosa. También hay que tener en cuenta que si el equipo no puede revisar una historia nunca sabrá si se ha terminado o no.
Marta Portales —Product Designer at LambdaLoopers
