Scrum – Historias de Usuario III

Definición de Hecho (Terminado)

Antes de empezar a hacer seguimiento de proyectos, uno de los elementos básicos que se debe pactar con el equipo es lo que todo el mundo va a entender por hecho en un artefacto llamado “Definición de hecho”.

El objetivo de la definición de hecho es identificar todas las acciones que hay que realizar (además de la propia codificación) para poder dar por finalizado un trabajo.

Quién, Cuándo y Cómo de la definición de hecho

Quién: la definición de hecho debe de construirse entre el equipo y el Product Owner. El Scrum Master tiene la labor de facilitar su generación, recopilar los acuerdos tomados y de ayudar a su puesta en práctica.

Cuándo: debe de realizarse al inicio del proyecto, antes de empezar el desarrollo.

Cómo: para poner en práctica la definición de hecho de manera sencilla y adecuada hay que interpretarla como un checklist a utilizar por el equipo durante el desarrollo, pero sobretodo, antes de cerrar las historias.

Características de las Historias de Usuario

Algunas de las principales características de las Historias de Usuario son las siguientes:

• Que sean escritas por el usuario o por un analista de negocio que le represente.
• Frase corta que encaje en una tarjeta de 3 por 5 pulgadas.
• Debe describir el rol desempeñado por el usuario en el sistema, descrito de forma explícita.
• Debe describir el beneficio para el área de negocio que representa esta funcionalidad.

¡Cuidado!

No debemos confundirlas con Casos de Uso o Escenarios de uso, la gran diferencia, es que son más cortas y no deben describir la interfaz con el usuario, los pasos de navegación o flujo de procesos de la aplicación.

Redacción de una Historia de Usuario

Los beneficios de este tipo de redacción son:

Primera persona. La redacción en primera persona de la HU invita a quién la lee a ponerse en el lugar del usuario

Priorización. Ayuda al PO a priorizar. Si el PB son un conjunto de Items como “confirmar un evento tentativo”, “notificar al responsable de logística”, “ver el estado de inscripciones”, etc. el PO puede trabajar más en conocer cuál es la funcionalidad, quién se beneficia y cuál es el valor de la misma.

Propósito. Conocer el propósito de una funcionalidad permite al equipo de desarrollo plantear alternativas que cumplan con el mismo propósito en el caso de que el costo de la funcionalidad sea alto o su construcción no sea viable.

Modelo INVEST

Una Historia de Usuario debe tener las siguientes características:

• Independiente
• Negociable
• Valiosa
• Estimable
• Small (Pequeña)
• Testeable

Ventajas de las Historias de Usuario

• Al ser muy cortas, estas representan requisitos del modelo de negocio que pueden implementarse rápidamente (días o semanas).
• Necesitan poco mantenimiento.
• Mantienen una relación cercana con el cliente
• Permiten dividir los proyectos en pequeñas entregas.
• Permiten estimar fácilmente el esfuerzo de desarrollo.
• Son ideales para proyectos con requisitos volátiles o no muy claros.

5 errores al escribir Historias de Usuario

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.

Puedes encontrar más información en este libro: