¿Qué informaciones son necesarias y cuáles son opcionales en una historia de usuario?

Para decidir qué información incluir en una historia de usuario es preferible no adoptar formatos rígidos. Los resultados de Scrum y Agilidad no dependen de las formas, sino de la institucionalización de sus principios y la implementación adecuada a las características de la empresa y del proyecto. Por tanto, aparte de 3 campos que se consideran necesarios, se puede incluir cualquier campo que proporcione información útil para el proyecto, recordemos que el foco de las historias de usuario y sus informaciones es la construcción de un entendimiento compartido.

Ejemplo de una tarjeta de historia de usuario

Los campos que se consideran más necesarios para describir de una manera adecuada las historias de usuario son:

• Descripción: descripción sintetizada de la historia de usuario. El estilo puede ser libre, según mejor nos funcione, debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se quiere? y ¿Cuál es el beneficio? Mike Cohn recomienda seguir el siguiente patrón que garantiza que la funcionalidad está descrita a un alto nivel y de una manera no demasiado extensa:

Como [rol del usuario], quiero [objetivo], para poder [beneficio]

El rol del usuario suele estar descrito en User-Personas y el para poder va relacionado con la visión del producto.

• Estimación: la estimación del esfuerzo de implementación es necesaria para que el Propietario del Producto pueda priorizar correctamente la pila de producto. Según convenga al equipo este puede utilizar tiempo ideal o una unidad de esfuerzo arbitraria propia del equipo u organización conocidas como punto de historia.
• Prioridad: sistema de priorización que nos permite determinar el orden en el que las historias de usuario deben de ser implementadas.

Dependiendo del tipo de proyecto, el funcionamiento del equipo y la organización, pueden ser aconsejables otros campos como:

• ID: identificador de la historia de usuario, único para la funcionalidad o trabajo.
• Titulo: titulo descriptivo de la historia de usuario.
• Valor de negocio: valor (normalmente numérico) que aporta la historia de usuario al cliente o usuario. El objetivo del equipo es maximizar el valor y la satisfacción percibida por el cliente en cada sprint. Este campo servirá junto con la estimación para determinar la prioridad con el que las historias de usuario deben de ser implementadas.
• Criterio de aceptación: pruebas de aceptación consensuadas con el cliente o usuario. Estas son las pruebas que guiarán al equipo a lo largo de la construcción y que el código deberá superar para dar como finalizada la implementación de la historia de usuario.
• Requerimiento no funcional: cualidades generales y restricciones. como la usabilidad o la seguridad, que afectan aplicaciones y sistemas enteros, y por tanto a las historias de usuario individuales.
• Definición de hecho: la definición de hecho o Definition of Done (DoD) incluye los criterios o actividades necesarias para dar por terminada una historia de usuario (desarrollada, probada, documentada...), que son las convenidas por el equipo y el Propietario del Producto.
• Dependencias: una historia de usuario no debería ser dependiente de otra historia, pero en ocasiones es necesario mantener la relación. En este campo se indicarían los identificadores de otras historias de las que depende.
• Persona asignada: en casos en que queramos sugerir la persona que pueda implementar la historia de usuario. Recordar que en Scrum es en último término el equipo autogestionado quién distribuye y por tanto asigna las tareas.
• Sprint: puede ser útil para organización del Propietario del Producto incluir el número de sprint en el que previsiblemente se vaya a realizar la historia.
• Riesgo: riesgo técnico o funcional asociado a la implementación de la historia de usuario.
• Módulo: módulo del sistema o producto al que pertenece.
• Observaciones: para enriquecer o aclarar la información o cualquier uso que pueda ser útil.

Mike Cohn comenta que si bien las historias de usuario son lo suficientemente flexibles como para describir la funcionalidad de la mayoría de los sistemas, no son apropiadas para todo. Si por cualquier razón, se necesita expresar alguna necesidad de una manera diferente a una historia de usuario, recomienda que se haga. Por ejemplo, la maquetación de pantallas se suele describir con pantallazos, por tanto esta es la mejor manera de transmitir el diseño que queramos darle a una aplicación.

Ejemplo una historia de usuario - cortesía de Scrum Manager y Gertudis

Ejemplo una historia de usuario - cortesía de Scrum Manager

Os quiero invitar a visitar el mapa mental sobre historias de usuario de mi compañero Nicolás, en él encontraréis todo lo necesario para escribir buenas historias de usuario.