¿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. Por eso, hoy en nuestro blog, nos preguntamos: ¿Cómo definir historias de usuario?

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.

blog-definir-historias-de-usuario-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.