División de historias de usuarios en historias más pequeñas

8

He estado leyendo varias técnicas para dividir historias de usuarios grandes de maneras útiles, como por el flujo de trabajo del usuario a través del sistema, etc. Lo que estoy luchando es cómo redactar estas historias más pequeñas si todo lo que logran es facilitar el siguiente paso en el procesar y no entregar el beneficio principal de la aplicación al usuario.

Por ejemplo, si mi nuevo sistema se divide en 3 historias más pequeñas en la línea de;

  1. Crea una nueva cuenta en línea

  2. Crear ciertas entidades contra mi nueva cuenta en línea

  3. Haga que mi dispositivo móvil consulte estas entidades contra mi cuenta y actúe sobre ellas

El sistema solo proporciona realmente una funcionalidad útil para el usuario final cuando todas las historias están completas. Entonces, si sigo el tradicional "Como [Usuario], me gustaría [Funcionalidad] para poder [Beneficio]" El beneficio de la primera y segunda historia es simplemente facilitar las historias posteriores y no proporcionar realmente al usuario la pieza principal de funcionalidad ( Lo épico). ¿Es esta la forma correcta de hacer esto?

agile user-story SeeNoWeevil
fuente

Respuestas:

6

Aquí tiene tres historias que deben hacerse (probablemente en una secuencia) para lograr un objetivo, poder consultar contra las entidades desde un dispositivo móvil es una característica que entregará un objetivo comercial, no parece ser el negocio objetivo en mi humilde opinión.

Aquí está mi sugerencia, exprese el objetivo comercial que su épica tiene que lograr y defina historias como esta

Como usuario, me gustaría registrarme en el sistema para poder [objetivo comercial]

Como usuario registrado, me gustaría crear entidades en mi cuenta para poder [objetivo comercial]

Como usuario registrado con entidades de cuenta, me gustaría actuar en consultas contra mis entidades desde un dispositivo móvil para poder [objetivo comercial]

Anadi Misra
fuente
Una pregunta interesante con una respuesta interesante. +1 para ambos. Como una pregunta secundaria: ¿qué hacer si, por ejemplo, solo dos de las historias de usuarios anteriores pueden caber en un sprint? Quiero decir, al final del sprint no está agregando ningún valor comercial tangible al producto: la función completa (y el valor comercial) solo estará allí en un sprint futuro. ¿Esta bien?
Giorgio
1
Buena pregunta, Giorgio. Yo diría que siempre y cuando gestione las expectativas para el negocio correctamente, de hecho seguirá agregando valor al negocio al entregar solo un subconjunto de funcionalidades en el primer sprint. El valor proviene de poner la funcionalidad frente a los usuarios que luego pueden proporcionar comentarios para el desarrollo futuro.
smstanton
0

La mejor manera sería tratarlo como una epopeya, y el alcance de las historias en sprints a partir de entonces. Mi respuesta utiliza el mismo enfoque (historias como parte de una epopeya).

Anadi Misra
fuente