Estoy escribiendo historias de usuario para un nuevo proyecto. Una de mis epopeyas es:
Como propietario de una empresa, quiero un perfil gráfico para poder construir mi identidad visual .
Y luego hay múltiples historias de usuarios vinculadas a esta epopeya para crear una paleta de colores, diseñar un logotipo, etc. Pero no estoy seguro de qué tipo de detalles debo agregar para la epopeya en sí. ¿Qué debo escribir en la descripción de la misma? ¿Debe la épica tener criterios de aceptación?
Una demanda es que todos los elementos gráficos sean vectores; ¿Debería ser ese un criterio de aceptación para la epopeya? ¿O debería duplicarse para todas las historias de usuarios que pertenecen a esa épica?
Para mí, una épica es una gran historia de usuario, cada vez que llega un requisito a nuestro equipo y parece muy grande (por ejemplo, > 13SP), consideramos llamarla épica en lugar de una historia. Una buena métrica es: ¿encaja en un sprint? Pero como el requisito es completo en sí mismo, simplemente dividirlo en Historias más pequeñas perdería el contexto. Entonces, podría decir que una epopeya es una historia, o mejor llamarlo un contenedor, que incluye varias otras historias.
Atlassian lo describe de esta manera (1) :
Una epopeya es un gran cuerpo de trabajo que se puede dividir en una serie de historias más pequeñas. Por ejemplo, el trabajo relacionado con el rendimiento en una versión. Una epopeya puede abarcar más de un proyecto, si se incluyen varios proyectos en el tablero al que pertenece la epopeya.
Una Epic debe ser menos técnica y más centrada en el valor de los clientes en comparación con Stories (que, por supuesto, también debe tener estos elementos). Trate de brindarles a sus desarrolladores la mayor cantidad posible de información sobre casos de uso. Una épica es más como una visión, las historias y las tareas son las cosas para llegar allí.
Usted decide si necesita criterios de aceptación para su Epic y qué detalles son importantes para realizar todo el Epic. En su caso, podría tener sentido agregar el vector y siempre debe tenerse en cuenta al probar una historia. Todas las Historias juntas deben cumplir con los requisitos de tu Epic.
Quizás estas respuestas también sean interesantes:
Hablando de JIRA: la creación de un Epic tiene un buen soporte en JIRA y lo ayuda a planificar en un nivel más alto de lo que sería posible con varias historias (por ejemplo, Ver el informe de Epic )
¿Qué va a cambiar cuando tengas una identidad visual? Como mides el exito?
Cumplir con los objetivos comerciales, no solo con las características del software
La epopeya debe ser sobre el objetivo comercial, no sobre lo que va a construir para lograr este objetivo. Debe explicar el por qué y cómo se va a medir el logro de la meta. Los detalles de implementación son parte de las historias de usuario.
¿Cuándo se puede dejar de implementar historias bajo la epopeya? ¿Realmente necesitas completarlos todos? Creo que las historias de usuarios son opciones que se pueden entregar para alcanzar el objetivo, tal vez la primera historia ya brinde suficiente valor. Ahora puede dejar de construir las opciones y concentrarse en la próxima epopeya.
Me gusta cómo el mapeo de impacto te ayuda a pensar en objetivos medibles y no en resultados.
Entonces, para responder a su pregunta: las epopeyas deben contener objetivos medibles, no detalles de implementación u opciones para lograr esto. Ciertamente no debe contener información duplicada. . La épica es la misión en la que se encuentra el equipo, es el por qué. Donde la historia de usuario es el qué.
En el mundo ideal, el equipo ahora puede decidir por sí mismo cómo lograr mejor este objetivo. Las personas proactivas y autoorganizadas dan los mejores resultados, sin duda para procesos creativos como el desarrollo de software o diseños.
Respuesta corta:
No existe una definición universalmente aceptada de Epic, así que haz lo que funcione para tu equipo. Son personas inteligentes, pregúntales a ellos en lugar de a extraños en Internet.
Respuesta algo controvertida:
Descubrí que las épicas son más efectivas cuando establecen un objetivo comercial y las métricas que se utilizarán para determinar ese éxito.
Ex:
Aumentar la tasa de clics en nuestra página de inicio en un 15%
¿Notas que no hay señales de una característica o historia a implementar a la vista? Solo hay un objetivo comercial valioso. Esto deja a su equipo libre de restricciones para pensar en formas en que podrían lograr ese objetivo para usted. Cada experimento generado se puede probar y validar con este objetivo. El Epic finaliza cuando el equipo ha logrado el objetivo, o se ha acercado lo suficiente como para que el PO decida que es lo suficientemente bueno y tiene otro trabajo más importante para que lo haga el equipo.
Como señalaron otros, no existe una definición universal de Epic, por lo que lo siguiente se basa en mi experiencia laboral.
Qué no hacer con un Epic
En mi práctica, un Epic nunca se puede agregar directamente a un sprint.
Es demasiado amplio, y una estimación basada en la complejidad sería demasiado inexacta como para tener la posibilidad de saber si encajaría en un sprint.
Por lo general, cubre varias Historias de usuarios, cada una de las cuales debe estimarse y priorizarse de forma independiente, no solo en comparación con otras historias como parte de esta épica, sino también con otras historias (de otras épicas).
El hecho de que Epic sea importante no significa que todas las historias de Epic sean igualmente importantes. En realidad, tal vez no todas las historias pensadas como parte de una epopeya lleguen a formar parte del proyecto, si surgen otras prioridades.
Por la misma razón, no es aconsejable entrar en demasiados detalles para las historias individuales, ya que en el momento de redactar la Epopeya aún no está claro qué historia se convertirá (cuándo) en un sprint y, por lo tanto, en el producto.
Qué hacer con un Epic
Similar a una Historia, una Epopeya debe justificar su existencia en el Backlog, explicando:
Como Epic puede involucrar más de un rol de usuario, potencialmente incluso más de una interfaz. En consecuencia, por su propia naturaleza, es demasiado complejo para escribirlo como una historia lineal.
En última instancia, debe dividirse en varias historias de usuario, ya que solo las historias de usuario bien encapsuladas deben convertirse en un sprint.
Por lo tanto, mi forma favorita de delinear una epopeya es escribir la epopeya como una lista redactada de historias de usuarios, sin entrar en demasiados detalles para cada historia.
Por ejemplo:
Al prepararse para un próximo sprint y es hora de abordar la épica, las historias de usuario se pueden desglosar y especificar en los detalles acordados, priorizar y estimar para el sprint o dejar para el próximo sprint si la velocidad (esperada) no es suficiente para abordar todas las historias a la vez.
En mi experiencia personal, la mejor Epic es la que no comunica más que un mensaje amplio de lo que trata. Una buena epopeya no debe tener el alcance de hacer suposiciones ni debe sonar vaga para alguien que acaba de unirse al proyecto.
Cuando hago una epopeya, trato de mantenerme alejado de los números y la entrega. Durante la planificación, mi epopeya ideal invitaría a tanta discusión como fuera posible dentro del equipo, que luego se documentaría en historias. Si todas las historias se completan con los criterios esperados, Epic ha hecho su trabajo de manera eficiente.
Todd A. Jacobs
andreas
ppasler