Quién, qué y por qué: cómo escribir una historia de usuario

Se espera que los gerentes de productos fomenten y fomenten las relaciones con numerosas personas a lo largo del proceso de desarrollo. Sin embargo, lo más íntimo es el usuario del producto. Debes conocerlos por dentro y por fuera: quiénes son, sus gustos y necesidades. Una forma de construir y mantener esa relación es escribiendo historias de usuarios.

Al igual que los manifiestos y los documentos de visión, las historias de usuarios son una parte integral del desarrollo de productos. Las buenas historias de usuarios son clave para una planificación y entrega eficientes, el compromiso del equipo y la satisfacción del cliente. Las historias de usuarios vagas a menudo indican que el equipo tendrá dificultades para completar las tareas a medida que avanzamos, algo que he presenciado muchas veces en mi rol como gerente de producto.

Mi participación en startups exitosas, y algunas que han fracasado, me ha demostrado de primera mano la importancia de tomarse el tiempo para crear historias de usuarios de calidad. Esta guía lo ayudará a usted y a su equipo a dominar cada elemento y seguir escribiendo historias de usuario de calidad.

¿Qué es una historia de usuario?

Una historia de usuario es un pequeño incremento del producto presentado en términos del valor que proporcionará al usuario final. Un grupo de historias de usuarios crea una epopeya y un solo producto puede abarcar varias epopeyas. Una historia de usuario se puede dividir en tareas que reflejen con mayor precisión el trabajo y describan cómo se completará la historia. Las historias de usuario generalmente usan la fórmula Usuario - Funcionalidad - Valor, que se puede aplicar de manera efectiva a la mayoría de las industrias y negocios.

Por lo general, el gerente de producto es responsable de escribir las historias de los usuarios, pero ocasionalmente esto puede recaer en el propietario del producto, el maestro de scrum o el gerente de ingeniería. Idealmente, cada historia de usuario es revisada por la persona o personas que realizan el trabajo.

¿Cuáles son los beneficios de una buena historia de usuario?

Una buena historia de usuario tiene varias ventajas para el equipo y el producto:

• Definir el "quién" y escribir desde la perspectiva del usuario asegura que el enfoque esté en el cliente y no en lo que el equipo quiere o prefiere.
• La definición de "qué" aclara los criterios para la persona que completa la tarea, el llamado hacedor. Cualquier cosa que no esté incluida en la historia puede considerarse fuera de alcance.
• Definir el "por qué" motiva al fabricante al ayudarlo a comprender el impacto que tendrá el resultado en la vida del usuario.
• Definir el valor del usuario puede ayudar a identificar una característica menos beneficiosa antes de que comience el trabajo en ella, y potencialmente desperdiciar recursos.

¿Cómo es una buena historia de usuario?

Por ejemplo, si está construyendo una casa para su cliente, una de sus historias sería sobre la creación de los muros perimetrales. Una mala historia de usuario podría decir "Necesito paredes", identificando el "qué", pero nada más. Una mejor sería: "Como propietario de una casa, quiero que mi casa tenga paredes que la cierren para evitar que entren los elementos y que el techo no se me caiga encima". Sin embargo, creo que si una historia de usuario realmente cumple su propósito, todos respondan las siguientes preguntas de manera clara y concisa:

• ¿Quién es el usuario?
• ¿Qué quiere el usuario? ¿Por qué el usuario quiere esto?
• ¿Cómo debe interpretar el equipo de ingeniería esta historia?
• ¿Esta historia depende de completar otra historia antes?
• ¿Completar esta historia permite que haya otra historia pendiente?
• ¿Cuál es el alcance (es decir, cuáles son los criterios mínimos)?
• ¿Qué tan grande es esta historia (es decir, dónde cae en la escala de estimación)?

Esta es la plantilla que uso: ha evolucionado con mi conocimiento de gestión de productos y me ha funcionado bien durante muchos años:

Un mito común de la historia de usuario

Cuando se trata de juzgar si las historias de los usuarios son buenas o malas, hay un mito generalizado que me gustaría disipar.

Muchas personas creen que una historia de usuario debe completarse en un solo sprint y, si no es así, fue una mala historia de usuario. Ese no es el caso. Por supuesto, es preferible que una historia de usuario se complete en un sprint (y esto debería ser factible), pero la amplitud del equipo y los factores externos pueden afectar la cantidad de trabajo a realizar, y esto varía de un sprint a otro. Además, las estimaciones generalmente asumen que cada miembro del equipo de desarrollo tiene el mismo nivel de habilidad en todas las áreas; El hecho es que un ingeniero con más experiencia tarda menos tiempo en completar una tarea que un ingeniero junior.

No debe intentar crear historias de usuario cortas solo para hacerlas rápidamente; Más bien, su historia de usuario debe intentar representar un aumento lógico en el valor entregado. No permita que un cronograma dicte la creación de una historia de usuario convincente.

Tenga en cuenta al usuario al frente y al centro

Considero que los proyectos son los más divertidos y exitosos cuando puedo confiar en mi conocimiento del usuario; puede leer más sobre mis experiencias en mi blog personal. Ya sea que esté proponiendo nuevas funciones o decidiendo qué se incluye con mi equipo, saber lo que diría el usuario es la forma más confiable de evaluar mi visión. Sin embargo, es fácil perder el contacto con el usuario, y por lo tanto el "por qué", si no pienso en él con regularidad. Esto es cierto para la mayoría de los gerentes de producto, cuyo enfoque a menudo se cambia a otras funciones y responsabilidades. Escribir buenas historias de usuario puede ayudarlo a usted y a los miembros de su equipo a mantener esa imagen del usuario en su mente e incluso mejorar su relación con ellos.

Más literatura en el blog de productos de Toptal: