Características de una buena historia de usuario

Un poco más allá del INVEST

29 August 2013


A continuación comparto mi lista de verificación al momento de revisar una historia de usuario.

Luego de hacer la CCC (Card, Confirmation, Conversation), definitivamente el más criterio más importante que uso es cumplir INVEST:
  • Independiente: No requiere de otra
  • Negociable: Se puede reemplazar por otra de diferentes prioridad
  • Valor: Que sea necesaria y de valor para el proyecto
  • Estimable: Que el equipo se sienta tranquilo y seguro estimandola
  • Small (pequeñas): Que no sean grande, funcionalidades pequeñas
  • Testeable (verificable): Que se le puedan realizar pruebas
Yo añadiría, aclararía y uso los siguientes:
  • que su tamaño no supere los 3 a 4 días de una persona enfocada desarrollándola.(Asociado al criterio de Small). Obvio hay excepciones pero al máximo trato que durante un planning no se supere este criterio.
    • Razón: He observado que historias mas grandes quedan mal estimadas por mas buena intención que tenga el equipo de desarrollo, el equipo se siente seguro con este tamaño de historia. Determine cual es el rango para su equipo.
  • que su implementación toque todas las capas o que el resultado de su implementación tenga sentido para el Product Owner o al Cliente. Me explico, en caso de hacer desarrollos asociados exclusivamente a la Base de Datos o a temas complejos por ejemplo que no logran verse reflejados facilmente por el product owner, sugiero crear historias técnicas en las cuales se le explique al Product Owner el valor asociado a las mismas en el proyecto. (Asociado al criterio de Valor).
    • Razón: Evito al máximo historias técnicas pues son de difícil justificación -- aunque no imposible, pues si son necesarias se hacen -- pero la razón principal es que este tipo de historias habilita el crecimiento orgánico.
  • que tenga a lo sumo entre 3 y 7 criterios de aceptación.(Asociado a los criterios de Small, Testeable y Estimable).
    • Razón: Más de 7 criterios, se puede  dividir la historia, menos de 3 se puede agrupar con otra.
  • que se pueda dividir cuando sea muy grande (Asociado a los criterios de Small, Testeable y Estimable).
    • Razón: La gran mayoría de las historias grandes se pueden dividir, esto permite más maniobrabilidad al equipo al momento de implementación.
  • preguntar lo más que se pueda sobre la necesidad de la historia de usuario (Asociado al criterio de Valor). 
    • Razón: Después de varios sprints y coach que me han hecho, he aprendido a preguntar para ciertas historias que percibo innecesarias (validaciones de negocio excesivas, autocompletar recargados, etc.):
      • ¿ok es de valor, pero es necesaria?
      • ¿cuántas personas la usarán?
      • ¿cuántas veces la usarán en el año?
      • ¿es realmente útil? 
      • ¿prefieres al equipo trabajando en esa "validación xxxx " -- por poner un ejemplo --  que en esta otra historia de usuario que agrega más valor al negocio?
      • ¿podemos postergar esto para el final y hacer otra cosa más urgente sobre la que tenemos clara la necesidad de implementación? (principio de LEAN - aplazar las decisiones, ver más aquí)

      Respecto al Sprint
      • Busco siempre trabajar con  al menos hayan 6 historias de usuario por sprint.
        • Razón: De esta forma el equipo tiene en que trabajar, con pocas historias de usuario se estarán obstaculizando entre sí.
      • Trabajo junto con el Product Owner para que existan al menos otras 6 historias adicionales
        • Razón: Tener backlog para posibles reemplazos y/o negociaciones.
      • Trabajo junto con el Product Owner para que se tengan definidos al menos historias de usuario al detalle para los próximos 2 Sprints (completamente elaboradas, cumpliendo INVEST) y un 3er sprint con Historias de Usuario sin mucho detalle.
        • Razón: Tener claro hacia donde va el producto.
      • La evolución del producto esta guiada por el Visual Story Mapping (ver más aquí)el cual tiene los objetivos de cada Release y las historias épicas que contendrá.
        • Razón: Tener claro hacia donde va el producto y saber cuan cerca estamos de hacer una liberación o release.

Article Rating

Current rating: 1.8 (12 ratings)

Comments

Jorge Hernán Abad Londoño, CSM, 8/29/2013 6:29:16 PM
Link del original: http://lecciones-aprendidas.blogspot.com/2013/07/caracteristicas-de-una-buena-historia.html

You must Login or Signup to comment.