Historias de usuario

Agenda
• Historias de usuario
• Spike
• Visual Story Mapping
• Bibliografía
 Agenda
• Historias de usuario
• Spike
• Visual Story Mapping
• Bibliografía
 ¿Por qué usar historias de usuario?
• Porque siguen los principios básicos de requerimientos ágiles, estos son:
• Potencian la participación del equipo en la toma de decisiones.
• Se crean y evolucionan a medida que el proyecto avanza.
• Peticiones concretas y pequeñas
• Contiene la información imprescindible. Menos es más.
• Apoyan la cooperación, colaboración y conversación entre los miembros del equipo, lo
que es fundamental.
 Historia de usuario
• Una historia de usuario describe una funcionalidad que, por sí misma, aporta
valor al usuario.
• Debe ser breve (para ser memorizable) e idealmente debe poderse
automatizar.
• Es una invitación a conversar.
• Puede representar requisitos funcionales, no funcionales o defectos.
• Proviene de XP.
 3C
• Card: descripción.
• Confimation: Criterios de Aceptación.
• Conversation: explicación.
 Card
• Hace alusión a la descripción de la necesidad del usuario.
• Se suele usar el formato:
• Yo como <rol> quiero <acción> para <valor del negocio u objetivo>
 Confirmation
• Hace referencia a los criterios de aceptación.
• Para hacer ATDD se suele usar Gherkins.
• Es lo que debe probar tanto el equipo de desarrollo como el Product Owner
para marcar como completada la historia.
• Los criterios de aceptación acompañan el Definition of Done. Por lo cual
para que la historia este completa debe cumplir los criterios de aceptación y el
Definition of Done.
 Conversation
• Es el momento en el cual el equipo asimila la necesidad. Entiende cual es el
problema que tiene el usuario y asimila cual es el camino correcto para dar
solución.
• Resultado de esta conversación hay claridad entre las partes y se refina la
historia para dejar claros aquellos vacíos que pueda tener.
 INVEST
• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable
 Independiente
• Una historia debe ser independiente de otras (lo más posible). Las
dependencias entre las historias hace que sea más difícil planificar, priorizar y
estimar.
• A menudo, se puede reducir las dependencias haciendo una combinación de
historias, o partiendo historias de forma diferente.
 Negociable
• Una historia de usuario es negociable. La "tarjeta" de la historia es tan sólo
una descripción corta que no incluye detalles. Los detalles se trabajan durante
la etapa de "Conversación". Una tarjeta con demasiados detalles limita la
conversación con el cliente.
 Valiosa
• Cada historia tiene que tener valor para el cliente.
• Apunta a un objetivo claro.
 Estimable
• El equipo de desarrollo necesita poder estimar una historia de usuario para
permitir que se pueda priorizar y planificar.
• Los problemas que pueden impedirle a los desarrolladores estimar una
historia son: falta de conocimiento del dominio (en cuyo caso se necesita más
Negociación / Conversación); o si la historia es muy grande (en cuyo caso se
necesita descomponer la historia en historias más pequeñas, Slicing).
 Pequeña
• Una buena historia debe ser pequeña en esfuerzo, generalmente
representando no más de 2-3 personas/semana de trabajo. Una historia que
es más grande va a tener más errores asociados a la estimación y alcance.
 Testeable
• Una historia necesita poder probarse para que ocurra la etapa de
"Confirmación".
• Un ejemplo de historia no testeable sería: "el software tiene que ser fácil de
usar".
 Notación Gerkins
• Usado para BDD y ATDD.
• Precondición-Acción-Resultado esperado= Given-when-then.
• Se escriben los criterios de aceptación como escenarios. Estos escenarios
deberán ser automatizado mediante pruebas.
 Historias épicas
• Son historias de usuario muy grande, más que una porción de funcionalidad
describe un deseado.
• Por ejemplo:
• Filtros de búsqueda.
• Sistema de búsqueda de texto libre para ofertas de trabajo.
• Presentación de listado con detalle de la búsqueda.
 Ejemplos descripción
• Como usuario de la aplicación quiero pagar mi compra con tarjeta de crédito para poder acceder al producto que
necesito.
• Como usuario de la aplicación quiero interactuar por chat con las personas de soporte al cliente para obtener claridad
sobre mi PQR
• Como persona interesada en ser usuario de la aplicación quiero una sección de preguntas frecuentes para aclarar
aquellos vacíos que no me permiten dar el paso a ser usuario de la aplicación
• Como usuario de la aplicación quiero realizar mis pagos a través de un dispositivo móvil para que la compra se
adapte a mi disponibilidad de tiempo.
• Como usuario de la biblioteca quiero realizar el préstamo de un libro para poder leer la información que requiero a
través de los recursos de la biblioteca
• Como administrador de la biblioteca quiero restringir el préstamo de libros por usuario y tomo para garantizar la
disponibilidad de recursos a los miembros acorde a la capacidad de la biblioteca
 Agenda
• Historias de usuario
• Spike
• Visual Story Mapping
• Bibliografía
 Spike
• Practica adoptada de XP.
• Un Spike es un espacio de exploración que busca dar certidumbre sobre una
necesidad que el equipo de desarrollo requiere atender al cliente.
• Se puede usar para: consultar, generar espacios para definiciones de diseño o
arquitectura de la aplicación.
• Teóricamente no llevan tiempo definido.
 Agenda
• Historias de usuario
• Spike
• Visual Story Mapping
• Bibliografía
 Visual Story Mapping
• Técnica creada por Jeff Patton
• Es una representación visual del sistema completo.
• Permite identificar Historias de Usuario faltantes en el Backlog, planificar
Releases, visualizar cómo se distribuyen las funcionalidades de acuerdo a las
diferentes áreas del sistema.
• Se va a dividir el sistema completo en planes de salida (Releases), se debería
poder sacar versiones a producción en medio del Release.
 ¿Cómo se hace un Visual Story Mapping?
1. Identificar las funcionalidades en las que podemos dividir nuestro sistema
(actividades) de forma secuencias.
2. Descomponer las actividades en las funcionalidades que hace el usuario
(Historias de Usuario)
3. Identificar cuales sub tareas deben ser desarrolladas, las más valiosas.

La fila de grandes funcionalidades serán Historias Epicas y se conocerán con el

nombre de The backbone.
The Walking Skeleton: las actividades más básicas que ofrecen una funcionalidad de
punta a punta en nuestro sistema.
 Agenda
• Historias de usuario
• Spike
• Visual Story Mapping
• Bibliografía
 Bibilografía
• User Stories - Answers On A Postcard http://www.agile-software-development.com/2008/01/user-stories-answers-on-
postcard-please.html
• Gojko Adzic & David Evans, Fifty Quick Ideas to Improve your User Stories, © 2013 – 2014 Nueri Consulting LLP
• Example of a User Story http://www.agile-software-development.com/2008/01/example-of-user-story.html
• Writing Good User Stories http://www.agile-software-development.com/2008/04/writing-good-user-stories.html
• Introducing User Stories http://www.slideshare.net/rsrivastava91/introducing-agile-user-
stories?src=related_normal&rel=4664999
• New to User Stories? http://www.scrumalliance.org/articles/169-new-to-user-stories
• Las 6 características de una buena historia de usuario http://www.dosideas.com/noticias/metodologias/456-las-6-
caracteristicas-de-una-buena-historia-de-usuario.html
• Las historias de usuario son más que una tarjeta http://www.dosideas.com/noticias/metodologias/895-las-historias-de-
usuario-son-mas-que-una-tarjeta.html