¿Qué son las historias de usuario?: 5 errores comunes al escribirlas

En el artículo presentamos 5 errores comunes que pueden cometerse al escribir historias de usuario, tales como: Definir el rol en la historia como “Usuario”, “Dueño de Producto” o “Desarrollador”, estos son roles inespecíficos no asociados a algún proceso de negocio en particular. Asimismo, otros errores comunes son, el no describir el valor de la historia para el área de negocio y no describir los criterios de aceptación de la historia.

Presentamos a continuación el artículo:

Referencia

Este escrito está basado en un artículo original de Kristian Kaczor, para Scrum Alliance, titulado, “5 Common Mistakes We Make Writing User Stories”. Invitamos a su lectura.

Plantilla de historias de usuario

Pmoinformatica.com coloca a su disposición una “Plantilla para documentar historias de usuario y criterios de aceptación”, completamente gratis. Nos gustaría recibir sus comentarios sobre la plantilla y sobre el contenido del blog.

5 errores comunes al escribir historias de usuario

1.- Definir el rol a quien va dirigida la historia como el “Usuario”

Ejemplo: “Como un Usuario, deseo poder gestionar cuentas de cliente, con el fin de eliminar cuentas no utilizadas o cuentas erróneas”.

A primera vista, todos los elementos que requiere una historia están presentes. Sin embargo, ¿Qué sucedería si necesitamos entender el rol del usuario para poder construir la funcionalidad del sistema?, ¿Quien es la persona para la cual se desarrollará esta funcionalidad?, ¿es un Representante de Atención al cliente que necesita verificar los datos de clientes individuales mientras atiende llamadas telefónicas en un Call Center? o ¿es un administrador de un canal virtual de atención al cliente que necesita una lista de clientes ordenadas por antigüedad?.

Las expectativas del sistema pueden ser muy diferentes según se defina el rol para quien se desarrolla la historia, por lo que es muy importante definirlos específicamente, evitando roles genéricos en las historia, como por ejemplo “El Usuario”.

2.- Definir el rol a quien va dirigida la historia como el “Product Owner”

Ejemplo: ¿Cómo Product Owner, quiero que el sistema tenga la posibilidad de eliminar cuentas del cliente, con la finalidad que los usuarios puedan eliminar las cuentas de cliente?

De nuevo, todos los elementos están presentes, pero algo está mal, primero se dice que el “Product Owner Quiere”, pareciera ser una historia que se escribió porque alguien la quería y no porque realmente la necesitaba. Luego, una historia no puede ser dirigida al Product Owner (este es un representante de las necesidades de los usuarios de las áreas de negocio), hacerlo de esta manera evidencia problemas conceptuales en la implementación del desarrollo ágil, además, al igual que en el punto 1, no se le asigna un rol claro a la persona que permita establecer sus expectativas.

3.- Definir el rol a quien va dirigida la historia como el “Desarrollador”

Ejemplo: “Como desarrollador, yo quiero reemplazar el Widget de Barra para seleccionar productos, con la finalidad de dar mantenimieno al widget de barra para seleccionar productos”.

Este es un ejemplo típico de una historia para un Backlog técnico o la representación de un requerimiento técnico. Estas historias con frecuencia formar parte de la deuda técnica que puede ir creciendo a lo largo del proyecto. Por lo general, la deuda técnica incluye actividades de mantenimiento necesarios para realizar actualizaciones de software, refactorización, cambiar frameworks, entre otros.

Si describimos estás historias técnicas de la forma en que se presenta en el ejemplo, no estamos agregando ningún valor al cliente, por lo que no obtendremos el apoyo del Product Owner y muchos menos de los usuarios del área de negocio.

¿Cómo escribir esta historia de forma correcta?, por ejemplo podría hacerse de la siguiente forma: “Como un usuario comercial, yo necesito poder ver múltiples productos en una misma barra y poder seleccionarlos, para poder hacer mi selección de forma más rápida”. Luego de describir la historia, describiríamos tareas como “Hacer Refactorización del mecanismo para incluir los productos en el widget de barra de productos” y luego “actualizar la versión de Java”, entre otras.

Los criterios de aceptación deben ser medibles y verificables mediante pruebas, por ejemplo, “el usuario puede ver en la barra 5 productos en una misma vez” y “al presionar el botón para mover la barra, el usuario puede recorrer cinco productos en menos de 5 segundos”. Otro criterio pudiera ser, “al hacer click sobre el producto, la página de detalle del producto se muestra en menos de 4 segundos”.

4- No describir el valor para el negocio o beneficio

Ejemplo: “Como vendedor de libros, quiero una opción de filtrado”.

En este ejemplo, tenemos el rol, tenemos la necesidad, pero falta la razón y el valor de negocio. ¿Por qué un vendedor quiere una opción de filtrado?, ¿Qué objetivo necesita alcanzar con eso?, ¿Es por ejemplo para poder responder a solicitudes especificas de clientes?. Necesitamos describir este valor o funcionalidad en las historias de usuario para que los desarrolladores cuenten con más información sobre las expectativas de los usuarios.

5- No establecer los criterios de aceptación o condiciones de satisfacción

Cada historia de usuario, debe ser documentada con sus criterios de aceptación o condiciones de satisfacción, no hacerlo, puede ocasionar una definición inadecuada de las tareas o estimación errónea (subestimación o sobrestimación del esfuerzo requerido). Como resultado, los casos de prueba no cubrirán los criterios adecuados debido a un entendimiento erróneo.

Los criterios de aceptación juegan un papel importante en la confirmación del entendimiento del requerimiento. Estas condiciones sirven como iniciadoras de conversaciones entre el equipo y el Product Owner.

En la medida en que se descubren estos criterios de aceptación, es posible que las historias necesiten ser refinada, replanificadas o divididas en varias historias.

Vía: pmoinformatica.com

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s


A %d blogueros les gusta esto: