.

Historias de usuario en Agile Scrum

file2841342633872

En un entorno Ágil tenemos que ser capaces de comunicarnos y colaborar con el cliente para recibir feedback y adaptarnos en consecuencia. Al fin y al cabo un ciclo de vida adaptable no sería útil si no nos adaptáramos. Por lo tanto es necesario compartir un lenguaje común con el cliente y por ello la definición técnica de un requisito sería poco útil; en un entorno Ágil preferimos emplear formas “no técnicas” para definir el alcance, como los son los “casos de uso” y las “historias de usuario”. Entre las dos, preferimos las historias de usuario, pues son incluso más fáciles de entender.

Ejemplos de historia de usuario son:

1) como un usuario final, quiero ser capaz de recibir una lista de mis últimas transacciones. O,

2) como administrador del sistema, quiero ser capaz de reinicializar las contraseñas.

Una historia de usuario tiene tres partes (dos obligatorias y una tercera opcional):

(1) Como…, (2) quiero…, (3) [de modo que…]

1.-como… “, define el rol de aquel que va a interactuar en la historia; por ejemplo el usuario final, el administrador o el gerente:

– como usuario final…

– como administrador…

– como gerente…

– como lector del blog…

2.-Quiero… “, define la expectativa del rol; por ejemplo buscar apartamentos, calcular el impuesto, conceder permiso a alguien y que se registre en la web.

Ten cuenta que nos referimos a acciones: “como administrador, quiero tener mi sistema para utilizar SQL Server” ¡no es una historia de usuario! Una historia de usuario implica hacer algo, en lugar de tener algo.

– como usuario final quiero acceder al carro de mi compra

– como administrador quiero…

– como gerente quiero…

– como lector del blog quiero responder a los comentarios de otros lectores

3.-de modo que… “, esta parte opcional de la historia de usuario explica la razón que está detrás de la acción y es de gran ayuda en la interpretación de la historia. La razón de algunas historias es tan evidente que es posible que no tengas que mencionarla.

– como lector del blog quiero responder a los comentarios de otros lectores de modo que pueda mantenerme en contacto con el resto de usuarios

Hay dos reglas básicas sobre los artículos del Backlog de Producto:

  1. No deben ser de carácter técnico. Recuerda que el Backlog de Producto es nuestro medio “no técnico” de comunicación con el cliente. Digamos que un niño de diez años debería ser capaz de entender cada historia de usuario.
  2. Deben ser independientes entre sí, de manera que podamos desarrollarlas libremente en cualquier orden.

Generalmente redactamos los elementos del Backlog de Producto en tarjetas o notas adhesivas y las colocamos en un tablón. Este enfoque es preferible a la utilización de una aplicación informática, a no ser que el equipo se encuentre “distribuido”.

En la parte de delante de la tarjeta escribiremos el texto de la historia de usuario (por ejemplo, como administrador, quiero reiniciar contraseñas), el valor del negocio, y la estimación (puntos de la historia). En el reverso de la tarjeta todo lo demás. Por ejemplo, ¿cómo se informa al usuario de la contraseña cambiada?, ¿qué tipo de contraseñas podemos aceptar?, etc. Además, tiene que ser breve, pues el espacio para escribir es limitado. Recuerda que la clave es mantener la sencillez.

tarjetas-historias-usuarios

 

No lo olvides: cada historia de usuario debe ser comprensible y demostrable para un cliente no técnico. Evita un argot técnico, a menos que estés con el equipo de desarrollo.

¿Quieres saber más sobre SCRUM?

QuieresCursoGratisImagen700X150_3

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

AUTOR:  miguel

Dirección proyectos TI y #ecommerce bajo Prince2 o Scrum . Usabilidad, Conversión, Seo, AdWords, Marketing online, Analítica. Consultor y desarrollador.

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR