Qué son las User Stories

Ahora que ya entendemos porque existen y cuál es el objetivo que buscan, veamos qué son exactamente estas tan famosas User Stories.

Se dice que las User Stories son una “promesa de una futura conversación”. Esto es porque en un principio cuando se crean suelen ser una simple frase o breve descripción de una funcionalidad que aporta valor al usuario o al negocio y que si no es prioritaria en ese momento no se entra en más detalle. Es por esto que queda en el backlog como un recordatorio de un requerimiento, para en el futuro trabajar sobre ella entre el Product Owner (PO) y el equipo (PO en el contexto Scrum o responsable de producto y/o definición de necesidades y prioridades como rol más genérico). Esto nos permite enfocarnos en lo que hoy es importante sin miedo a olvidarnos de algo en el futuro.

Una User Story se compone de tres partes. Tarjeta, Conversación y Confirmación (CCC por sus siglas en inglés).

Tarjeta: Una simple y breve descripción de la funcionalidad, desde la perspectiva del usuario, que recuerda a todos, de una forma fácil, de que se trata la Story y que ayuda en la planificación. “Tarjeta” hace referencia a las tarjetas de papel que se utilizaban en un comienzo en eXtreme Programing (XP).

Para esta descripción se suele usar un formato o template donde se dice “Como… Quiero… Para…”. En el siguiente post voy a entrar más en detalle en este tema, para que se entienda bien que beneficios tiene escribirlo así.

Conversación: Los detalles de las User Stories y las posibles dudas son aclarados en conversaciones que tienen el PO y el equipo. Esta es la parte más importante de las User Stories ya que es lo que hace que se creen los requerimientos de una forma ágil, alineada con los conceptos de colaboración y comunicación que mencioné en el post anterior.

Confirmación: Captura los criterios a tener en cuenta para asegurar que una User Story está hecha y que cumple con todas las expectativas. Estos criterios se van creando a partir de las conversaciones entre el PO y el equipo. La lista de estos criterios es conocida como, Criterios de Aceptación o Satisfacción, Tests de Aceptación, etc.

CCC

Una vez sabemos que son las User Stories la siguiente gran pregunta es ¿cómo es una “buena” User Story? Para esto existe la nemotecnia INVEST que ayuda a recordar las características de una buena User Story.

Independiente: Lo más independientes posible. Permite una mejor priorización

Negociable: No es un contrato, sino una invitación a hablar. El resultado surge de la colaboración y negociación entre las partes

Valiosa: Debe aportarle valor al usuario o cliente. Si no aporta valor no debe hacerse.

Estimable: Debe poder estimarse el tamaño. Si no podemos estimarla mejor seguir conversando.

Pequeña (Small): Lo suficientemente pequeñas para poder estimarla, priorizarla y planearla.

Testeable: Debe poder probarse y confirmar que cumple con lo esperado.

Si analizamos esto con las características de los requerimientos ágiles del post anterior, podemos ver que el INVEST está totalmente alineado con las necesidades de requerimientos que faciliten un desarrollo iterativo e incremental.

Puede parecer algo obvio, pero es importante ser prácticos y tener sentido común a la hora de usar estas reglas. Si no podemos terminar poniéndonos muchas trabas a la hora de crear las User Stories solo por intentar aplicar esta regla como una simple plantilla.

 

Anuncios

2 comentarios en “Qué son las User Stories

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s