¿Cómo elegir la perspectiva correcta en las historias de usuario?

Una parte clave del propósito de una historia de usuario es comprender la necesidad desde la perspectiva del usuario. Como tal, desea explorar su necesidad. Esta debería ser su perspectiva y centrarse en su necesidad, no en la solución. Por ejemplo, podría escribir una historia de usuario que diga:

Como cliente distribuidor recién registrado para ACME Corp, me gustaría que me enviaran por correo electrónico una confirmación de mi registro para saber si se realizó correctamente.

También es importante recordar que no todos los elementos del backlog deben ser historias de usuarios. Podría decir simplemente:

Vuelva a formatear el correo electrónico de confirmación para que coincida con la nueva guía de marca.

Este tipo de cosas pueden ser útiles cuando tienes que rehacer algo con una solución específica. Alternativamente, si fuera a hacer un nuevo proyecto con correos electrónicos, probablemente incluiría algo en mi definición de hecho que diga:

Toda la comunicación cumple con la guía de estilo de marca.

y nunca sería un elemento pendiente, sino que se aplicaría a todos los elementos pendientes.

Me pregunto cuál de las dos perspectivas es más útil para el equipo de desarrollo que va a implementar mis historias.

¿Con toda honestidad? Ninguno. Lo más útil es la conversación que usted (como PO) tiene con el equipo de desarrollo sobre la historia del usuario , explicándoles lo que se debe hacer y cuál es el criterio de aceptación para esta funcionalidad en particular.

Una declaración larga de una oración de lo que desea generalmente no es suficiente para comprender todo lo que debe implementarse. Las historias de usuario no son requisitos detallados . Expresan lo que el usuario necesita que la aplicación haga por él. Son desde la perspectiva del "usuario", por eso se llaman "historias de usuario".

Siguiendo con su ejemplo, mi idea de una historia de usuario podría ser algo como esto:

Como usuario de la aplicación, quiero recibir correos electrónicos de marketing relevantes para poder beneficiarme de las mejores ofertas.

... o lo que sea.

En ninguna parte de mi ejemplo se especifica "cómo". ¿Cómo se formatea el correo electrónico? ¿Cómo se diseña el correo electrónico? ¿Cómo se envía el correo electrónico? Estas son parte de las discusiones que el PO y el equipo de desarrollo deben tener en torno a la historia del usuario cuando sea el momento de implementarla. Como usuario, realmente no me importa eso, solo quiero que la aplicación lo haga de alguna manera. Tiene sentido comercial que el correo electrónico lleve la marca de su empresa, pero ese es su criterio de aceptación como proveedor de la aplicación, no necesariamente el mío como usuario de la aplicación (esto muestra otro problema con las historias de usuario, a veces no están escritas por usuarios reales, sino por alguien de la empresa que "piensa" que sabe lo que quieren los usuarios reales).

Entonces, no todo lo que está en el backlog tiene que ser una historia de usuario. ¿Qué hay de los errores? ¿Escribes problemas de errores desde la perspectiva del usuario? Es ridículo, ¿verdad? Sin embargo, de alguna manera, las personas intentan forzar todas las características, funciones, requisitos, cambios técnicos e implementaciones, etc. en las historias de los usuarios y piensan que está bien hacerlo. Pero no lo es. Simplemente genera una sobrecarga administrativa porque en lugar de especificar lo que se necesita en un lenguaje natural y luego discutir más detalles en función de eso, las personas dedican mucho tiempo a escribir "la historia de usuario perfecta" en un patrón restrictivo. A veces eso se pasa de la raya y terminas con anomalías como "Como desarrollador, quiero una API de back-end para poder implementar un front-end enriquecido", que está redactado como una historia de usuario, pero no es una historia de usuario.

Un elemento como el siguiente está bien:

Todas las comunicaciones por correo electrónico a los usuarios deben tener el estilo/formato adecuado

No lo pienses demasiado . Siempre que todos entiendan lo que significa y lo que se debe construir (lo que rara vez se entiende a partir de una sola oración; por lo tanto, la conversación que debe tener), no debe forzarse a un "Como [tipo de usuario], yo quiero [alguna cosa] para que [alguna razón]" patrón.

Si le resulta difícil expresarlo desde la perspectiva del usuario, tal vez no lo escriba como una historia de usuario .

Como regla general, las historias de usuarios se escriben desde el punto de vista del valor para el usuario final.

Yo, como receptor de una notificación por correo electrónico, quiero encontrar mis nuevos mensajes con un estilo que permita identificarlos fácilmente como enviados por ACME Corp.

Eso funcionaría si es valioso para el usuario final identificar fácilmente los correos electrónicos.

Yo, como gerente de marca de ACME Corp., ¿quiero que todos los mensajes enviados por correo electrónico apliquen nuestras guías de estilo corporativas?

Por lo general, esto no funcionaría, ya que supongo que a la mayoría de los usuarios finales no les importará si un correo electrónico sigue la guía de estilo corporativa.

Puede parecer que el gerente de marca es un cliente para la historia del usuario, pero en este caso no creo que lo sea. Esto se debe a que el gerente de marca no obtiene valor directo de la historia y no es un cliente interno genuino.

Hay productos que entregan valor directo internamente. Digamos, por ejemplo, que estaba escribiendo una aplicación interna que permitía al director de marketing coordinar sus campañas de marketing. Ese es un producto interno y, por lo tanto, el usuario final es una persona interna.

Recomendaría que escriba historias de usuarios desde la perspectiva de ambos usuarios, ya que ambos tienen necesidades diferentes pero están motivados. Luego vincularía las 2 historias para que los desarrolladores estén al tanto.