ESCRIBIENDO USER STORIES EN AGILE

Las metodologías ágiles proponen iteraciones cortas para desarrollar software de manera incremental. En cada iteración los requerimientos a desarrollar se expresan mediante user stories. Una user story se expresa mediante una oración simple, siguiendo un formato clásico y busca mostrar las necesidades del usuario para con el uso del sistema de manera directa y precisa. Dicho formato es el siguiente: “Cómo quiero para ”. Cada user story es acompañada de criterios de aceptación, los cuales detallan qué condiciones debe cumplir el código que implementa la user story. Los criterios de aceptación serán utilizados tanto por los desarrolladores como por los testers para validar la conformidad de la aplicación con los requerimientos funcionales.

Escribir buenas user stories no es trivial. Es un ejercicio que requiere tiempo y experiencia. En particular, existen un tipo de user-stories que requieren especial atención: son aquellas denominadas “técnicas” o de investigación. Sobre las mismas surgen voces a favor y en contra. A continuación se detallan consejos para redactar buenas user-stories, y se da un panorama sobre las user-stories de investigación.

El arte de redactar

En la referencia [1] se detallan los cinco errores más comunes a la hora de redactar User Stories. En primer lugar se menciona el problema de describir user-stories muy generales, del estilo “Como usuario quiero manejar distintas cotizaciones para poder seleccionar la más conveniente”. Si bien a primera vista cumple el patrón esperado de una user-story, el rol de la misma no está bien especificado. ¿Quién es el usuario observando las cotizaciones? Es distinta la funcionalidad detrás si es el administrador del sitio, o un usuario visualizando datos.

Es fundamental por lo tanto especificar lo más detalladamente posible el usuario detrás de cada user-story. De manera similar para una user-story que comienza con “Como Product Owner….” o “Como desarrollador”. Una buena user-story refleja la visión desde el punto de vista del usuario del producto final, y no desde el líder o integrante del equipo de desarrollo.

Otro error común es ignorar la parte de para qué quiero la funcionalidad de la user-story. Parece trivial, pero poder justificar la funcionalidad pedida es un ejercicio útil para mejorar el proceso de identificar requerimientos. Si no es posible formular de manera simple para qué se quiere una determinada funcionalidad del producto, es probable que no sea necesaria implementarla. Finalmente, se destaca la necesidad de especificar criterios de aceptación. Una manera de verlos es como casos de prueba para el código que implementa la user-story, y por su papel debe prestarse atención en su formulación. Por ejemplo, para una user story que describe la funcionalidad de buscar un determinado producto en un catálogo, un criterio de aceptación podría describir el escenario donde no se encuentre el producto al realizar la búsqueda y especificar en este caso que se espera que aparezca en pantalla un texto del estilo “Actualmente no se posee el producto en stock. Vuelva a consultar pronto!”

User-stories técnicas o de investigación

En repetidas ocasiones surge la necesidad de contemplar user-stories un tanto particulares, donde no se refleja la necesidad de un usuario final, sino del equipo de desarrollo. Si el equipo necesita emplear avanzadas técnicas de encriptación de datos para desarrollar un producto seguro, ¿es una buena práctica ágil agregar una user-story “interna” del equipo donde se refleje la necesidad de estudiar técnicas de encriptación? En este sentido hay voces a favor y en contra.

En las referencias [2,3] se manifiestan en contra de su utilización. Los argumentos son que en realidad son requerimientos que se alejan de la noción de user-stories, lo cual produce un product backlog entremezclado y confuso. Proponen en cambio incluir los requerimientos técnicos como tareas dentro de user-stories, introduciéndolos de manera gradual y fiel a los conceptos ágiles.

Las voces a favor (ver [4,5]) argumentan que en determinadas ocasiones es provechoso tener explícitamente historias que reflejen la necesidad de investigar una tecnología, realizar un prototipo, etc. En especial, cuando son actividades críticas para el producto. Por ejemplo, si el equipo está desarrollando un proyecto de e-commerce es crítico que el equipo sea experto en cuestiones de seguridad. En caso de no contar con la suficiente experiencia, es posible emplear user-stories técnicas o de investigación que reflejen la inversión en tiempo y esfuerzo del equipo en investigar técnicas y herramientas de seguridad y encriptación. Muchas veces estas stories se conocen como user stories de tipo “spike”.

Conclusiones
Como siempre, mucho depende de la experiencia y del equipo llevando adelante el proyecto. Para redactar buenas user stories, el mejor consejo es seguir fielmente el patrón propuesto:“Cómo quiero para ”. El mismo es un proceso que tiende a mejorar a medida que se adquiere más experiencia. Sobre las user stories técnicas, son buenas en la medida que se justifique su utilidad, y tenga un output concreto. Por ejemplo, el algoritmo de encriptación que mejor se adapta al proyecto es un buen entregable de una user story técnica.

Referencias:

[1] https://www.scrumalliance.org/community/articles/2011/august/5-common-mistakes-we-make-writing-user-stories
[2] http://xprogramming.com/articles/technical-stories-we-dont-need-em/
[3] http://www.industriallogic.com/blog/as-a-developer-is-not-a-user-story/
[4] http://programmers.stackexchange.com/questions/140065/is-it-proper-to-have-investigation-task-in-sprint
[5] http://agileatlas.org/articles/item/spikes-in-scrum-the-exception-not-the-rule