1. Definir el rol a quién va dirigida como “Usuario”
Ejemplo
“Como un Usuario, deseo poder gestionar cuentas de cliente, con el fin de eliminar cuentas no utilizadas o cuentas erróneas”.
Las expectativas del sistema pueden ser muy diferentes según se defina el rol para quien se desarrolla la historia.
Es muy importante definirlas 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
“Como 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.”
Una historia no puede ser dirigida al Product Owner, ya que es un representante de las necesidades de los usuarios de las áreas de negocio.
3. Definir el rol a quien va dirigida la historia como el “Desarrollador”
Ejemplo
“Como desarrollador, quiero reemplazar el Widget de Barra para seleccionar productos, con la finalidad de darle mantenimiento.”
Ejemplo de requerimiento técnico (forman parte de la deuda técnica). No se agrega valor al cliente.
La historia de usuario debería ser algo como:
“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”.
4. No describir el valor para el negocio
Ejemplo
“Como vendedor de libros, quiero una opción de filtrado”.
Tenemos la necesidad, pero falta la razón y valor de negocio.
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
No hacerlo ocasiona una definición inadecuada de tareas o estimación. Los casos de prueba no cubrirán los criterios adecuados. En la medida que se especifican los criterios de aceptación, es posible que las historias tengan que ser redefinidas, replanificadas o divididas en varias historias de usuario.