Cinco formas de mejorar tu desempeño con historias de usuario

 

Imagen tomada de Pixabay

Las historias de usuario no son para escribirlas

La pregunta que debes hacer no es “¿cómo escribir mejores historias de usuario? El objetivo no debe ser escribir historias de usuario. Cámbiala más bien por ¿cómo mejorar mis conversaciones con historias de usuario? Las historias de usuario son un instrumento de comunicación social y sabemos que la forma más efectiva de comunicar información es la conversación, ojalá cara a cara. La forma más efectiva de evolucionar las historias de usuario es vía conversaciones, primero entre los usuarios e interesados y el Product Owner y luego, entre este y los miembros del equipo.

Puedes leer mi artículo Las historias de usuario como instrumentos de negociación para saber más sobre este tema. Clic aquí para leerlo.

Las historias de usuario te ayudan a encontrar tu por qué

Las historias de usuario son una herramienta para iniciar el descubrimiento del producto con el usuario, consumidor o cliente, no es para finalizarlo. De esta manera, tanto el Product Owner, como los desarrolladores (quienes hacen el trabajo finalmente) deberían ver las historias de usuario como algo que describe el por qué están haciendo lo que hacen, no precisamente qué están haciendo. Como siempre, si un usuario no estuvo involucrado en el descubrimiento y desarrollo de las historias de usuario, estas quizás no sean historias de usuario del todo; quizás sean más bien “quimeras imaginadas”.

Conoce a los usuarios

Por eso, mi primerísima recomendación, concisa, si eres responsable de las historias de usuario, es: habla con las personas que tienen la necesidad, el problema, indaga por el problema detrás del problema, la causa raíz. Esto aumentará tu comprensión de lo que se necesita y por qué. Acompaña esta práctica con un conocimiento profundo y empático del usuario o consumidor: quién es, qué hace, con quién lo hace, qué información intercambia y cómo lo hace, son algunas de las cuestiones a escudriñar si quieres tener éxito con historias de usuario.

En mi artículo Qué hay de "usuario" en las historias de usuario profundizo sobre este asunto. Clic aquí para leerlo.

Las historias de usuario y el product backlog

Una historia de usuario no está sola, aislada del resto del producto. Así que es importante pensar sobre ella como un componente de primer orden del product backlog. Y en este punto, es de mucha importancia considerar la transparencia del backlog. Recordemos que transparencia significa que todos los interesados, usuarios y equipo comparten el mismo significado de las cosas, por ejemplo, qué significa que algo está terminado.

Las cosas así, las historias de usuario deben ser transparentes y estar disponibles para todos los interesados, para que estos tengan visibilidad de lo que está haciendo el equipo, en qué orden y por qué. En particular, resuelve preguntas como:

- ¿Los interesados saben cómo acceder a las historias de usuario?

- Cuando acceden a las historias de usuario, ¿el contenido los ilustrará o los confundirá?

En mi artículo El extraño caso de las historias de usuario técnicas pongo de manifiesto que una “historia de usuario técnica” es una práctica disfuncional. Clic aquí para leer el artículo. Este otro artículo también te puede dar ideas al respecto: Buenas y “malas” historias de usuario. Clic aquí para leerlo.

Desarrollo de producto dirigido por hipótesis y experimentos

Las historias de usuario son hipótesis. Trátalas como tal. Haz experimentos y comprueba esas hipótesis. La última línea de defensa es el consumidor final, el usuario. Mientras tanto, no dejarán de ser eso precisamente: supuestos o conjeturas. En este apartado entran en escena las entregas tempranas y frecuentes y, sobre todo, la retroalimentación directa que logres de los clientes o usuarios. Es de esta manera que podrás adaptarte al entorno y tomar mejores decisiones en el futuro inmediato que beneficien a los usuarios. Para lograrlo, tus historias de usuario deben ser realmente pequeñas. Piensa que solo tienes algunas horas para implementarlas o construirlas, hasta unos muy pocos días, dos o tres a lo sumo.

En este apartado, una anotación especial para desarrolladores de software: si todavía te encuentras con el escenario de “mini cascadas”, es decir, primero un “subequipo” desarrolla la historia y luego otro “subequipo” prueba la historia, entonces tus historias de usuario deben ser aún más pequeñas. No te imaginas cómo sufren los analistas de prueba mientras esperan a que desarrollo les entregue las historias para empezar a probar cuando el final del sprint ya está encima. Como siempre, el mejor antídoto contra todo esto, es empezar a cambiar radicalmente las técnicas de desarrollo, incursionando en TDD, BDD y automatización, entre otras. Pero tengo que confesarlo, esto es más fácil decirlo que hacerlo. Por eso hago toda esta recomendación especial.

Quieres saber más

Estos y otros temas de interés hacen parte de mi curso de historias de usuario. En febrero estaré facilitando una nueva edición del curso. Toda la información en https://bit.ly/cursohu.