Historias de Usuarios

Get Started. It's Free
or sign up with your email address
Historias de Usuarios by Mind Map: Historias de  Usuarios

1. Información que puede contener

1.1. Identificador

1.1.1. Identificador de la historia de usuario, único para la funcionalidad o trabajo.

1.2. Descripción

1.2.1. Descripción sintetizada de la historia de usuario. Mike Cohn recomienda seguir el siguiente patrón que garantiza que la funcionalidad está descrita a un alto nivel y de una manera no demasiado extensa: Como [rol del usuario], quiero [objetivo], para poder [beneficio]

1.3. Estimación

1.3.1. Estimación del esfuerzo necesario en tiempo ideal de implementación de la historia de usuario. Según convenga al equipo también se puede utilizar unidades de desarrollo, conocidas como puntos de historia.

1.4. Prioridad

1.4.1. Sistema de priorización que nos permite determinar el orden en el que las historias de usuario deben de ser implementadas.

1.5. Titulo

1.5.1. Titulo descriptivo de la historia de usuario.

1.6. Criterios de aceptación

1.6.1. Pruebas de aceptación consensuadas con el cliente o usuario. Estas son las pruebas que el código debe superar para dar como finalizada la implementación de la historia de usuario.

1.7. Valor

1.7.1. Valor (normalmente numérico) que aporta la historia de usuario al cliente o usuario. El objetivo del equipo es maximizar el valor y la satisfacción percibida por el cliente en cada iteración.

1.8. Dependencias

1.8.1. 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.

1.9. Persona asignada

1.9.1. En casos en que queramos sugerir la persona que pueda implementar la historia de usuario. Recordar que en Scrum es en último término el equipo autogestionado quién distribuye y por tanto asigna las tareas.

1.10. Criterio de finalización

1.10.1. La definición de finalizada/hecho incluye los criterios o actividades necesarias para dar por terminada una historia de usuario (desarrollada, probada, documentada...), que son las convenidas por el equipo y el propietario del producto.

1.11. Sprint

1.11.1. Puede ser útil para organización del propietario del producto incluir el número de sprint en el que previsiblemente se vaya a realizar la historia.

1.12. Riesgo

1.12.1. Riesgo técnico o funcional asociado a la implementación de la historia de usuario.

1.13. Módulo

1.13.1. Módulo del sistema o producto al que pertenece.

1.14. Observaciones

1.14.1. Para enriquecer o aclarar la información o cualquier uso que pueda ser útil.

2. División vertical

2.1. Por pasos de flujo de trabajo

2.1.1. Para historias de usuario que incluyen algún tipo de flujo de trabajo, estas se pueden dividir según los pasos individuales del flujo.

2.2. Por reglas de negocio

2.2.1. Historias de usuario que conllevan implícita o explícitamente reglas de negocio se pueden dividir por estas reglas. Frecuentemente los casos de test implican importantes reglas de negocio, por tanto para esta división podemos basarnos en las pruebas.

2.3. Por happy/unhappy flow

2.3.1. las funcionalidades usualmente describen un flujo en que todo va bien y otros flujos en que se tratan desviaciones, excepciones o problemas, por tanto estos flujos también son una forma de dividir historias grandes.

2.4. Por opciones/plataformas de entrada

2.4.1. En caso de productos que han de rodar en diferentes plataformas, como portátiles, tablets, móviles... pueden dividirse las historias de usuario por su plataforma de entrada.

2.5. Por tipos de datos o parámetros

2.5.1. Algunas historias de usuario se pueden dividir por sus parámetros de entrada o salida, como por ejemplo las diferentes opciones de una búsqueda.

2.6. Por operaciones

2.6.1. Hay historias que involucran las típicas operaciones de alta, lectura, modificación y baja (CRUD - create, read, update & delete), operaciones que pueden ser otra forma de división.

2.7. Por casos/escenarios de test

2.7.1. A veces hay historias que son difíciles de dividir funcionalmente, en este caso puede ayudar a preguntarse cuáles van a ser los escenarios de test de la historia y dividir por estos. Los escenarios pueden ser combinación de reglas de negocio, flujos que van bien y con excepciones, plataformas de entrada, etc.

2.8. Por roles

2.8.1. Para historias de usuario que cubren diferentes roles, estas se pueden dividir por las funcionalidades propias de cada rol.

2.9. Por optimizar ahora o más tarde

2.9.1. Las historias de usuario pueden ser implementadas en diferentes grados de perfección y optimización de la funcionalidad descrita.

2.10. Por compatibilidad de navegador

2.10.1. Las historias de usuario para aplicaciones web a menudo tienen que trabajar en una amplia variedad de navegadores, los más modernos tienden a ser más compatibles con los estándares y los más antiguos suelen necesitar de personalizaciones para que todo funcione correctamente.

3. Fórmula de captura

3.1. Card

3.1.1. Cada historia de usuario debe ser limitada, esta debería poderse memorizar fácilmente y escribir sobre una tarjeta o post-it.

3.2. Conversation

3.2.1. Antes de ser implementadas, estas van acompañadas de conversaciones con los usuarios y la definición de los criterios de validación asociados.

3.3. Confirmation

3.3.1. Los criterios de validación permiten al propietario del producto/usuario de negocio confirmar que el equipo ha recogido correctamente los requisitos, al equipo realizar las pruebas adecuadas y/o desarrollar guiados por pruebas con TDD, y finalmente comprobar que la historia ha sido completada.

4. Criterios de aceptación

4.1. S - Specific (Específicos)

4.2. M - Measurable (Medibles)

4.3. A - Achievable (Alcanzables)

4.4. R - Relevant (Relevantes)

4.5. T - Time-boxed (Limitados en el tiempo)

5. Comprobar la calidad

5.1. I - Independent (independiente)

5.1.1. Es ventajoso que cada historia de usuario pueda ser planificada e implementada en cualquier orden. Para ello las historias deberían de ser totalmente independientes (lo cual facilita el trabajo posterior del equipo). Resaltar que las dependencias entre historias de usuario pueden reducirse combinándolas en una o dividiéndolas de manera diferente.

5.2. N - Negotiable (negociable)

5.2.1. Una historia de usuario es una descripción corta de una necesidad que no incluye detalles. Las historias deben ser negociables ya que sus detalles serán acordados con el cliente o el usuario durante la fase de conversación. Por tanto, se debe evitar historias de usuario con demasiados detalles porque limitaría la conversación acerca de las mismas.

5.3. V - Valuable (valiosa)

5.3.1. Una historia de usuario tiene que ser valiosa para el cliente o el usuario. Una manera de hacer una historia valiosa es que la escriba el mismo.

5.4. E - Estimable (estimable)

5.4.1. Una buena historia de usuario debe de poder ser estimada con la precisión suficiente para ayudar al cliente, usuario o propietario del producto a priorizar y planificar su implementación. La estimación generalmente la realizará el equipo de trabajo y está directamente relacionada con el tamaño de la historia de usuario (una historia de usuario de gran tamaño es más difícil de estimar) y con el conocimiento del equipo de la necesidad expresada (en el caso de falta de conocimiento, serán necesarias mas fases de conversación acerca de la misma).

5.5. S - Small (pequeña)

5.5.1. Las historias de usuario deberían englobar como mucho unas pocas semanas/persona de trabajo. Incluso hay equipos que las restringen a días/persona. Una descripción corta ayuda a disminuir el tamaño de una historia de usuario facilitando así su estimación.

5.6. T - Testable (comprobable)

5.6.1. La historia de usuario debería ser capaz de ser probada (fase confirmación de la historia de usuario). Si el cliente o usuario no sabe como probar la historia de usuario significa que no es del todo clara o que no es valiosa. Si el equipo no puede probar una historia de usuario nunca sabrá si la ha terminado o no.

6. Priorización MoSCoW

6.1. M - MUST HAVE (es necesario)

6.1.1. Se debe tener la funcionalidad implementada en la solución, sino esta fallará o la solución no puede ser considerada un éxito.

6.2. S - SHOULD HAVE (es recomendable)

6.2.1. Se debería tener la funcionalidad implementada en la solución ya que es una funcionalidad de alta prioridad. La solución es prescindible, no fallará si no existe pero debería de haber causas justificadas para no implementarla.

6.3. C - COULD HAVE (podría implementarse)

6.3.1. Es deseable, por tanto sería conveniente tener esta funcionalidad implementada en la solución, dependerá de las posibilidades de los tiempos y el presupuesto del proyecto.

6.4. W - WON'T HAVE (no lo queremos... quizá en un futuro)

6.4.1. Se trata de una funcionalidad de muy baja prioridad o descartada en ese momento, pero que en futuro pueda ser relevante. Posteriormente, cuando cobre importancia, puede pasar a alguno de los estados anteriores.