Por ejemplo, tenemos dos épicas, 'Gestión de usuarios' y 'API de SSO', que se desglosan adecuadamente. Se crea una historia de usuario para la funcionalidad de contraseña perdida, pero la historia es relevante para ambas epopeyas.
¿Se puede asociar esta historia de usuario único sobre contraseñas con múltiples epopeyas?
No puede tener una API SSO sin una administración de usuarios subyacente, eso es una dependencia, primero debe realizar la administración de usuarios.
Tu historia pertenece a la gestión de usuarios y debe hacerse en esa épica.
La implementación de la API para que sea compatible con la funcionalidad puede ser otra historia en la epopeya de SSO.
Por lo tanto , una historia de usuario no debe asociarse con más de una épica.
La conexión entre una épica y las historias de usuario es de uno a muchos, por lo tanto, una historia de usuario puede pertenecer a una sola épica. Puede tener la historia de usuario en la primera epopeya y hacer que la segunda epopeya dependa de esta historia de usuario; no se puede continuar ni finalizar hasta que finalice la historia de usuario en cuestión.
Esta planificación basada en dependencias es una característica común de la gestión de proyectos en general y no se limita solo a metodologías ágiles. Sin embargo, parece muy aplicable al problema de planificación ágil que ha descrito.
Una epopeya puede depender de otra epopeya o historia, por lo que, en realidad, su diagrama de dependencia podría parecerse más a esto:
+------------------+
| |
| Common Story |
| |
+--+------------+--+
^ ^
| |
+------------+-----+ +--+---------------+
| | | |
| Epic 1 | | Epic 2 |
| | | |
+------------------+ +------------------+
Entonces, en lugar de tratar de poner la misma historia en más de un lugar, o tratar de descomponer sus épicas de una manera que se sienta artificial, simplemente puede hacer que la historia común o épica sea un requisito previo.
Tiago Cardoso