Historias de usuario al empezar de cero

Una historia de usuario no le dará un producto liberable

que representa algún valor para un usuario final

Esta cláusula se agrega para superar la mentalidad de las prácticas Waterfall anteriores. Hacer análisis solo o hacer diseño solo no es una historia de usuario válida. La historia debe dar como resultado algún código que se pueda enviar, que es lo que representa valor para el usuario.

se puede entregar durante un sprint

Esta cláusula se agrega para mantener las historias pequeñas para que puedan completarse completamente dentro de un sprint.

Lo que buscas es lo que popularmente se conoce como Producto Mínimo Viable (MVP). MVP es un producto con las funciones suficientes para atraer a los primeros clientes y validar una idea de producto al principio del ciclo de desarrollo del producto. Hay muchos ejemplos de MVP como este sobre Zappos.

Entonces, adelante, formule su MVP y escriba tantas historias de usuario como necesite para eso. Puede leer más sobre cómo dividir las historias de usuario en otras más pequeñas, escribir condiciones de satisfacción, etc. aquí.

No se obsesione con escribir la historia de usuario perfecta. En cambio, si se trata de un nuevo producto que está creando desde cero, concéntrese en:

• definir un panorama general de lo que debe hacer el producto;
• divide esa visión en partes, acciones y actores (puedes usar una técnica llamada User Story Mapping para eso, y crear epopeyas e historias de usuarios);
• coloque estas epopeyas e historias en una cartera de pedidos y priorícelas y ordénelas en función de lo que traería el mayor valor primero;
• haga una reunión de refinamiento para dividir la parte superior de la cartera de pedidos en partes más finas;
• calcule cuántas de esas piezas de la parte superior de la cartera de pedidos podría caber en un sprint (si está haciendo iteraciones) o en una cantidad de tiempo razonable. Esta es la verdadera razón por la que desea dividir las historias de usuario en la "menor cantidad de trabajo" o para que tengan la propiedad INVEST , de modo que entregue cosas de trabajo a un ritmo rápido y constante.
• Al principio, es posible que las historias de usuario que identificó tengan que ser algo creado con datos simulados, o estructuras alámbricas en lugar de una interfaz de usuario completamente funcional, o simplemente un flujo de usuario que funcione mínimamente, etc. La idea es tener algo que funcione y se pueda mostrar. partes interesadas con el fin de recopilar algunos comentarios para que aprenda y utilice el aprendizaje para descubrir qué construir a continuación. Como menciona la respuesta aceptada, el propósito no es necesariamente construir un producto liberable desde el principio. Si tiene un producto complejo que requiere que existan algunas funciones para poder utilizarlo, es posible que no obtenga algo completamente funcional en los primeros sprints, pero puede construir algo de todos modos.
• enjuague y repita para agregar funcionalidad de forma incremental además de eso y obtenga algunas versiones que puede lanzar a los usuarios.

Algunos ejemplos de historias de "sprint 1" para un sitio de comercio electrónico:

• Como nuevo cliente, quiero tener la posibilidad de registrarme en una cuenta para poder comprar
• Como cliente potencial quiero consultar un catálogo de productos

Algunos ejemplos para una aplicación de recursos humanos:

• Como usuario de recursos humanos, quiero poder iniciar sesión
• Como usuario de recursos humanos, quiero recuperar los detalles de un empleado por número de empleado

Crear algunas tablas básicas para respaldar estas historias solo toma una o dos horas. Crear una interfaz de usuario lleva un poco más de tiempo, pero ciertamente se puede lograr algo perfectamente utilizable en un sprint de 2 semanas. Estos son incrementos de valor muy pequeños pero, sin embargo, son esenciales para el producto.

Otro punto relevante es que empezar completamente desde cero es bastante inusual. Por lo general, tiene datos, servicios, bibliotecas de códigos y otros activos técnicos existentes sobre los que puede desarrollar.

Parte del problema es definir qué significa "entregado". ¿Significa integrado y demostrado? ¿Significa desplegado? ¿Significa que se ha habilitado un indicador de función? Dependiendo del contexto en el que esté trabajando el equipo, podría significar cualquiera de estos. La definición también podría cambiar con el tiempo a medida que el equipo refina su capacidad para diseñar, desarrollar, probar, implementar y operar el sistema.

También hay formas de dividir el trabajo de diferentes maneras que pueden facilitar la demostración y la retroalimentación rápida. No necesariamente necesita una experiencia de extremo a extremo para obtener comentarios. Usando el ejemplo de "ordenar una lista de productos", puede demostrar una interfaz de usuario en una pantalla o página en particular que tiene datos precargados en el front-end. Puede ir un paso más allá y hacer que el front-end cargue datos desde un back-end, pero use una fuente de datos más fácil de leer, como un archivo de texto, para conectar la API entre un componente front-end y back-end. O podría dar un paso más y tener datos preestablecidos en una base de datos. Cualquier otra cosa podría requerir la capacidad de agregar y/o editar datos en la base de datos, que probablemente serían otras historias.

No recomendaría usar historias de manera diferente al principio que al final. Me daría cuenta de que puede haber otros tipos de historias además de las historias de usuarios, como diferentes tipos de historias de habilitación técnica. Una historia, fundamentalmente, es solo un marcador de posición para una conversación. Las historias de usuarios se centran en el cliente o el usuario final, pero no hay razón por la que no pueda tener marcadores de posición para conversaciones técnicas sobre la creación de bases de datos, API y rendimiento. También recomendaría centrarse en estrechar el ciclo de comentarios, ya sea recibiendo comentarios de los usuarios sobre la interfaz de usuario o de los desarrolladores sobre las decisiones técnicas para asegurarse de que está en el camino correcto.

Creo que también es justo decir que: "a veces las historias de los usuarios (y el scrum en general) están a la altura de esos ideales, y otras veces simplemente no". El concepto de una "historia de usuario" es realmente solo una guía para ayudarlo a dividir el trabajo en pequeñas unidades y vincular esas unidades muy de cerca con las cosas que el usuario final realmente observará. Pero, especialmente en las primeras etapas de un proyecto sustancial que se inicia desde cero, a veces eso no tiene mucho sentido. Y, eso está bien.

Por ejemplo: construir una casa. ¿Cuál es la "historia de usuario" de todos esos bloques y piezas de tubería de PVC cuidadosamente colocados que sobresalen por todas partes? Bueno, hay planos de casas cuidadosamente hechos, pero no demasiado como una "historia". Todo el trabajo que ven tendrá un propósito eventual y absolutamente debe colocarse allí ahora, y muy precisamente donde están. Pero las "historias de usuario, por sí solas" no serían una buena manera de planificar o ejecutar ese proyecto en estas primeras etapas fundamentales. En cambio, tiene una "cascada", planeada con mucha anticipación por un arquitecto con licencia. Porque eso es lo que tiene más sentido en este momento.

La metáfora de las "historias de usuario" sigue siendo muy útil e importante, incluso en las primeras etapas, pero no pueden guiar estrictamente el proyecto hasta que se hayan sentado las bases.

El problema que está encontrando es que está comenzando con una solución en mente. Entonces estás rompiendo esa solución en sus pedazos. El problema que está planteando no es realmente uno con las historias de los usuarios. Es: cómo resuelve rápidamente una parte de la necesidad de un usuario para que pueda aprender más sobre esa necesidad.

La semana pasada, terminé una aplicación de encuestas de mercado en 5 horas. No usé una historia de usuario, pero si lo hiciera, se vería así:

Como analista, me gustaría presentar a los clientes potenciales 2 afirmaciones sobre la capacidad del producto y hacer que seleccionen la que más resuena con ellos para que pueda ver qué capacidades son las más importantes para mi mercado.

Esta fue la base de datos, la lógica, la interfaz de usuario, la implementación.

Lo usamos para una demostración interna a la mañana siguiente y es potencialmente entregable en el sentido de que si elijo realmente usarlo con clientes de lectura, podría hacerlo.

He trabajado con varios equipos que entregan nuevas aplicaciones en tan solo uno o dos días. Ahora, puede haber muchas cosas en su entorno que le impidan lograr eso y debe decidir si poder entregar eso rápido le brinda un beneficio que vale la pena el costo de habilitar eso en su contexto. Pero absolutamente se puede hacer.