Qué información contiene una historia de usuario Francisco Javier Cervigon Ruckauer

Qué información contiene una historia de usuario

Aunque dependiendo del proyecto se podría incluir cualquier otro campo que proporcionase información útil, en este apartado se describen aquellos campos que se consideran más necesarios para describir de manera adecuada una historia de usuario. Estos campos se pueden observar en la siguiente figura:

Figura 4. Historia de usuario

De esta manera, una historia de usuario está compuesta por los siguientes elementos:

• ID: identificador de la historia de usuario.

• Título: título descriptivo de la historia de usuario.

• Descripción: descripción sintetizada de la historia de usuario. Si bien el estilo puede ser libre, la historia de usuario debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se quiere? y ¿Cuál es el beneficio? Cohn (M. Cohn, 2004) [1] recomienda seguir el siguiente patrón:Como [rol del usuario], quiero [objetivo], para poder [beneficio]. Con este patrón se garantiza que la funcionalidad se captura a un alto nivel y que se está describiendo de una manera no demasiado extensa.

• Estimación: estimación del tiempo de implementación de la historia de usuario en unidades de desarrollo, conocidas como puntos de historia (estas unidades representarán el tiempo teórico de desarrollo/persona que se estipule al comienzo del proyecto).

• Valor: 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 o usuario en cada iteración. Este campo determinará junto con el tiempo, el orden con el que las historias de usuario van a ser implementadas.

• 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.

•  Pruebas de aceptación: pruebas consensuadas entre el cliente o usuario y el equipo que el código debe superar para dar como finalizada la implementación de la historia de usuario. Este campo también se suele denominar “criterios o condiciones de aceptación".

Cohn en (M. Cohn, 2004) [1] 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, las interfaces de usuario se suelen describir en documentos con muchos pantallazos. Al igual puede ocurrir con documentos especificaciones de seguridad, normativas, etc.

No obstante, lo que sí es importante con esta documentación adicional es mantener la trazabilidad con las historias de usuario. Por ejemplo, a través de hojas de cálculo donde se lleve el control de a qué historia pertenece cada documento adicional, o especificando el identificador de la historia en algún apartado del documento, etc. 

---

[1] Cohn, M. (2004). User stories applied: For agile software development Addison-Wesley

Francisco Javier Cervigon Ruckauer