Historias de Usuario Parte 3

Continuando con el post de historias de usuario , este es el 3 y ultimo apartado , donde se describe el formato y algunos tips para redactarlas bien.

Formato

El formato habitual para redactar historias de usuario es el siguiente :

I as [Role] want [function] so that [business value]

Como: <Actor >

Deseo: <Necesidad>

Para: <Valor de negocio>

 Criterios de Aceptación (Test de Aceptación)

1Las pruebas de aceptación es el proceso de verificar que las historias se desarrollaron exactamente igual como el equipo cliente espera que funcione.

userStoryFormal

Si se desea ir mas allá para generar escenarios de prueba para complementar la información a desarrollo y calidad , aplicando el inicio de B.D.D por parte de negocio.

Escenarios de prueba

Given , when ,then (Pasado , Presente , futuro)

Dado que: <Un Contexto (Entrada)>

Cuando: <se produce un evento>

Entonces: <resultado esperado (Salida)>

 

Release Plan

Es importante determinar cuándo será lanzado nuestras funcionalidades generando un mínimo producto viable que genere el mayor retorno de la inversión permitiendo generar un producto con crecimiento organico de forma iterativa e incrementental

Cuando tenemos las historias de usuario defiidas , el product owner debe determinar cuales de esas historias van a salir en el lanzamiento en determinado números de sprint.

Una técnica utilizada es la de MoSCoW 2 Del acrónimo de 3:

  1. Must have to : Requisito que tiene que estar implementado en la versión final del producto para que la misma pueda ser considerada un éxito
  2. Should have to : Requisito de alta prioridad que en la medida de lo posible debería ser incluido en la solución final, pero que llegado el momento y si fuera necesario, podría ser prescindible si hubiera alguna causa que lo justificara.
  3. Could have to : Requisito deseable pero no necesario, se implementaría si hubiera posibilidades presupuestarias y temporales.
  4. Won’t have this time : Hace referencia a requisitos que están descartados de momento pero que en un futuro podrían ser tenidos de nuevo en cuenta y ser reclasificados en una de las categorías anteriores.

 

Ya que permite identificar cuales requisitos generan mas valor al sistema.

Consejos

Cuando una historia de usuario es grande, es necesario dividirla en varios, generando que la historia principal sea comúnmente llamada EPIC.

-Cada historia debe ser escrita en lenguaje de negocio.

-Los desarrolladores estiman cada historia

-Cada historia se le asigna un estimado de puntos de historia . que indica el tamaño del esfuerzo relativo a las demás historias.

-Redactar las historias en voz Activa

-Mantener la interfaz de usuario lo más lejos posibles al redactar las historias de usuario.

-Escribir las historias por roles individuales, por ejemplo “Un buscador de finca raíz puede eliminar descripción”, es mejor “Un buscador de finca raíz puede eliminar sus descripciones”.

-Evitar utilizar números como identificadores, es recomendado utilizar el titulo abreviado para tener un mejor contexto del id de la historia.

-La historia de usuario debe probar partes o funcionalidades en concreto , no todo el sistema

-Usar etiquetas en los escenario , para clarificar el contexto , como por ejemplo si es lento o pesado el escenario , si es necesario configurar el ambiente ,dependencias externas , y otras mas.

– El product owner no puede estimar (Gerencia de Proyecto) sin información del equipo de desarrollo , ya que necesita saber el esfuerzo que representaría las historias de usuario.

Para finalizar comparto un template en hoja de calculo para facilitar el manejo de las historias de usuario.

DESCARGAR TEMPLATE HISTORIAS DE USUARIO HOJA DE CALCULO

Parte 1 Parte 2

Referencias

  1. User Stories Applied: For Agile Software Development   (Cohn, Mike 2004)
  2. For information on DSDM see DSDM: Business Focused Development (Stapleton 2003)
  3. https://jummp.wordpress.com/2013/04/27/metodo-moscow/

Posted by Giovanny

¡Hola! Soy Giovanny Cifuentes, apasionado Consultor en Transformación Digital, con un enfoque principal en impulsar cambios significativos en las organizaciones. Mi misión es ayudar a las organizaciones a aprovechar las oportunidades y esquivar las amenazas mediante la incorporación de la Tecnología, Metodologías de Trabajo y Cambio Cultural.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Descubre más desde Giovanny Cifuentes | Consultor Transformación Digital

Suscríbete ahora para seguir leyendo y obtener acceso al archivo completo.

Seguir leyendo