Aunque todo esto es opcional, para que te hagas una idea, en este apartado se describen aquellos campos que, típicamente, se consideran más necesarios para describir (recuerda que la descripción es sólo una parte, quizá la menos importante comparada con la conversación) de manera adecuada una Historia de Usuario. Estos campos se pueden observar en la siguiente figura

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? (M. Cohn, 2004) recomienda seguir el siguiente patrón:
  • Como [rol del usuario], quiero [objetivo], para poder [beneficio]. Con este patrón se garantiza que se captura funcionalidad y que se está describiendo de una manera no demasiado extensa.
• Estimación: normalmente en unidades conocidas como puntos de historia (estas unidades representarán el tiempo ideal o la complejidad para que el equipo desarrolle la Historia de Usuario).
• Valor: valor (normalmente numérico) que aporta la Historia de Usuario al cliente o usuario. El objetivo del equipo, y concretamente del Product Owner, es maximizar el valor y la satisfacción percibida por el cliente o usuario en cada iteración. Este campo determinará 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".

(M. Cohn, 2004) 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., que suelen complementar a la Historia de Usuario.