martes, julio 16, 2013

Características de una buena historia de usuario

Nivel del post: Básico

Este es mi lista de verificación al momento de revisar una historia de usuario.

Luego de hacer la CCC (Card, Confirmation, Conversation), definitivamente el 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 User 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.


Si estás interesado en ver  recomendaciones para el Product Backlog ver - http://www.pmoinformatica.com/2013/07/11-reglas-product-backlog-scrum.html



-------------------------------------
JORGE HERNÁN ABAD LONDOÑO
MSc. Ingeniería Informática - Universidad Eafit

ScrumAlliance
Certified Scrum Master
member 000260715

3 comentarios:

  1. Buenos tips Jorge, el tema más importante que mencionas y me parece clave en conseguir buenas historias de usuarios es trabajar con anticipación las historias al detalle para los próximos sprints.

    Durante la reunión de planificación (que debe ser de 8 horas o menos) no da tiempo de hacer un buen trabajo de detallar historias, quedando siempre historias de calidad dudosa y haciendo que el flujo de la información sea problemático durante el sprint.

    Saludos!

    ResponderBorrar
  2. Hola Adrian.

    El planning para un sprint de 2 semanas debe ser de máximo 4 horas (2 de conversación, 2 de estimación - sugieren en www.scrum.org).

    Uno entiende que en el planning aun haya cosas para ajustar de criterios de aceptación, pero el planning no es para escribir.

    Luchar por cumplir ese timebox ha sido dificil pero poco a poco voy llegando a la meta, mis primeros planning eran de 1 día, ahora vamos mas o menos por los 5 horas y bajando; pero en esto nos esta ayudando mucho la reunión de refinamiento.

    Saludos!!

    ResponderBorrar
  3. Hola Jorge,

    Muy buenas las recomendaciones. Ante todo me gusta la simplicidad de la explicación y lo fácil que haces que se vea para implementar estas prácticas en el equipo. Como siempre excelentes ideas y sugerencias.

    Mil gracias!

    ResponderBorrar