13 User Stories

User Stories

Parte: Proceso de desarrollo

Sección de la Metodología Ensamble.

Las User Stories & Backlog se centran en cómo refinar el entendimiento de la funcionalidad detectada durante la fase de Product Discovery, descomponiéndose en incrementos de funcionalidad que se utilizarán para planificar y construir el producto incrementalmente.

User Stories

  • Historia y Propósito:
    • Kent Beck sugirió que la forma tradicional de especificar un producto era ineficiente.
    • Las User Stories buscan capturar la funcionalidad desde la perspectiva del usuario, generando conversaciones entre usuarios y desarrolladores para refinar el entendimiento. Lo importante no es la tarjeta en sí, sino la conversación que genera.
    • Ron Jeffries capturó los componentes de las User Stories en la fórmula de las 3C's: Tarjeta, Conversación y Confirmación (Card, conversation, and confirmation).
  • Atributos Esenciales:
    • Deben estar escritas en el lenguaje del usuario final.
    • Deben explicar el "qué" en lugar del "cómo".
    • Deben contener alguna funcionalidad visible para el Product Owner.
    • Deben ser gestionables, es decir, dividirse en ítems pequeños para reducir la incertidumbre. Se prefiere que puedan completarse en 2 a 5 días.
  • Formato Clásico:
    • El formato clásico para escribir User Stories es:
      • Como <rol>
      • Deseo <funcionalidad>
      • Para <obtener algún valor>
    • Ejemplo:
      • Como cajero
      • Deseo ingresar un producto manualmente
      • Para seguir con la compra en los casos en que el escáner no funcione
  • Criterios de Aceptación:
    • Se utilizan para ampliar la descripción de la User Story, incluyendo ejemplos de uso, reglas que deben cumplirse o mockups de las pantallas.
    • Los criterios de aceptación deben ser lo más concretos posible, evitando la subjetividad.
    • Se pueden utilizar mockups para describir visualmente la funcionalidad esperada.
  • Herramientas Adicionales:
    • Se pueden utilizar workflows de estados o flujos de navegación de pantallas para complementar las User Stories.
    • Es importante evitar la duplicación de especificaciones.
  • Proceso de Descubrimiento:
    • El resultado del Product Discovery sirve como base para identificar la funcionalidad necesaria para escribir las User Stories.
    • No se debe preocupar por entender el alcance exacto de cada User Story al principio, ya que se refinarán a medida que avance la construcción del producto.
  • Example Mapping:
    • Es una técnica para estructurar la conversación al escribir User Stories, utilizando tarjetas de diferentes colores para el título, reglas, ejemplos y preguntas.
    • El objetivo de los colores es poder visualizar ciertos problemas en las historias.
  • Partiendo User Stories:
    • Es posible trabajar en incrementos pequeños de funcionalidad eficientemente, usando buenas prácticas de desarrollo de software.
    • Se pueden partir las stories usando agrupaciones lógicas, separando el manejo de condiciones excepcionales, separando las distintas operaciones o separando desde la GUI.

← Maximizar el valor de negocio · Índice · Backlog →