Historias de Usuario Parte 3

Valore este artículo
(0 Votos)

Parte 1 Parte 2

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.

 

 Imagen tomada de

 

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.

 

 

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.

Concejos

-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

 

 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/

  Parte 1 Parte 2

Última modificación Martes, 26 Julio 2016 13:42
Giovanny Cifuentes

¿ Quien es Giovanny Cifuentes ?

Mi nombre es Giovanny Andres Cifuentes , me desempeño como Scrum Master, experto en gestión de proyectos ágiles .

Colaboro en las comunidades Mozilla Colombia y Agiles Colombia.

He sido desarrollador, diseñador,jefe de proyecto,emprendedor  y he pasado por casi todas las dedicaciones del desarrollo e implementacion de software.

Mozillians  : https://mozillians.org/es/u/igacifuentes/

 

 

Más en esta categoría « Scrum Impact Mapping »

Deje un comentario

Asegúrese de teclear la información requerida dónde se indica (*). El código HTML no está permitido