Las Historias de Usuario son un elemento básico para aplicar metodologías Ágiles y especialmente para poder aplicar SCRUM.

Su simpleza hace de esta técnica una gran herramienta para poder tratar casi todos los aspectos necesarios para la creación de productos, especialmente los de software. Y todo se basa en una regla de palabras muy curiosa:

Así, el <rol> que escojamos que va a utilizar la aplicación software, requiere de una <Acción> que ocurra, porque desea cubrir una <funcionalidad>. Corto y conciso. Directo. Claro.

El aspecto más importantes de las Historias de Usuario es el PARA

Cuando empezamos a trabajar con Historias de Usuario, siendo el equipo desarrollador o el cliente, lo más fácil es entender cuál es el PARA. puesto que lo que siempre queremos cubrir es la <funcionalidad>. El resto es una forma de responder al PARA.

Pero cuidado! Si estas empezando a utilizar el concepto de Historia de Usuario,  cuando las escribes se puede confundir el QUIERO y el PARA por la sencilla razón de que el lenguaje te lleva a error.

Ejemplo de confusión con el PARA y el QUIERO de las Historias de Usuario

Situación real utilizando las Historias de Usuario en Scrum de un cliente, explicándolo de la siguiente manera:

Como <Operador>

QUIERO <Acceder a la Aplicación de Registro>

PARA <Ver un listado ordenado>.

En un primer momento, te parecerá correcto, pero si lo piensas bien, realmente no me estaba hablando de funcionalidad, me estaba hablando de requisito. Realmente quería ver un listado? Realmente quería acceder al Registro? o Quizás lo que quería es tener información del registro para tomar una decisión? es esa decisión automatizable? Podríamos facilitarle la funcionalidad que busca sin tener que pintar un listado en pantalla?

Es labor de todo el mundo buscar las funcionalidades reales que hay por detrás de forma que encontremos la mejor solución posible. Una mala redacción de las Historias de Usuario conlleva trabajo posiblemente innecesario.

Las 3 Cs de las Historias de Usuario

Una historia está compuesta por 3 Cs (Card – Conversation – Confirmation).

Card de tarjeta de Historia de Usuario

Documentación en SCRUMEl primer punto es tener una tarjeta donde escribamos la regla. Mi recomendación, Post-It Super Sticky 6556SY – Pack de 6 blocs de notas adhesivas, 76 x 127 mm, color amarillo. Así tendrás espacio para poder escribir lo que necesites con un rotulador y con letras mayúsculas en cada post-it.

De esta manera, con una Historia de Usuario en cada post-it podrás pegar y despegarlos para colocarlos donde más te convengan.

Para identificar la Historia de Usuario, el encargado es el Product Owner. Quien con apoyo del equipo de desarrollo redactará las que necesite.

Al ser post-it, las podemos desplazar y reordenar según nos interese. Por orden de prioridad o por módulos temporales o por lo que necesitemos.

Conversation para explicar mejor la Historia de Usuario

Concisa y sencilla. Si. Pero no ilimitada. Así que, cada Historia de Usuario se concreta con el Product Owner sobre su contenido. Al ejemplo del filtro, salen dudas como…

  • un botón o un combo como en otras webs?
  • el botón que texto tiene?

Todo ello se puede concretar en una conversación. O en alguna herramienta más elaborada. Tan elaborada como la plantilla de Historias de Usuario que te ofrezco en Excel un poco más abajo.

Confirmation de los Criterios de Aceptación

La parte oculta de las Historias de Usuario, son los Criterios de Aceptación. Es la concreción real de la tarjeta. Donde se concreta de forma exacta el comportamiento.

Así, establecemos criterios del ámbito “cuando no haya geles, el botón saca un mensaje” o “Cuando no haya ninguno, no hace nada” o “Cuando tarde más de 30 segundos en responder, saca mensaje de error”. Para ello podemos utilizar texto libre que nos permita hacer verificaciones, o podemos utilizar el lenguaje Gherkin, que nuevamente utilizar otra regla de palabras.

Características esenciales de las buenas Historias de Usuario Scrum

Para que las Historias de Usuario sean buenas, utilizamos la regla de INVEST de la siguiente forma:

Independientes entre sí, para poder llevarlas a cabo en el orden que más nos convenga según las prioridades que establezca el Product Owner.

Negociables con el Product Owner para establecer los limites adecuados, la parte de conversación de una historia es esencial

Valor para el usuario, el PARA es fundamental. Se ha de entender la funcionalidad siempre y la tiene que entender todo el Equipo de Desarrollo

Estimable. El Equipo de Desarrollo que la vaya a recoger, debe ser capaz de estimar el esfuerzo que supone realizarla.

Small de un tamaño que el equipo de desarrollo pueda asumir en un sprint. Y a ser posible que el equipo pueda asumir varias dentro del sprint

Testeable para poder confirmar que está correctamente implementada. O dicho de otra forma con los Criterios de Aceptación establecidos.

Plantilla Historias de Usuario

Te aconsejo que lo hagas simple, lo simple es fácil de modificar a gusto de cada uno y permite ese punto de flexibilidad que la creación de historias de usuario requiere. Por ello, te propongo este Plantilla Historias de Usuario, para que empieces a trabajarlo.

Para empezar a identificar las Historias de Usuario, deberías de emplear la técnica de User Story Mapping con la que te resultará muy sencillo empezar a recoger ideas. Además, te recomiendo especializarte en el ámbito de Product Owner si lo tuyo es lo de sintetizar y priorizar.

La plantilla que te facilito la puedes implementar también en Google Drive y de este modo ya tienes un elemento colaborativo de forma que el Equipo de Desarrollo, el Product Owner y el Scrum Master pueden ver el contenido de todas las Historias de Usuario.