¿Relación entre historia de usuario, característica y épica?

En realidad son términos muy genéricos. Hay muchas maneras de interpretarlos, variando en la literatura y cómo la gente los ve. Toma todo lo que digo con un gran grano de sal.

Generalmente, un Epic comprende una funcionalidad muy global y no muy bien definida en su software. Es muy amplio. Por lo general, se desglosa en una historia o característica de usuario más pequeña cuando intenta darle sentido y hacer que encajen en una iteración ágil. Ejemplo:

Epic
- Permitir que el cliente administre su propia cuenta a través de la Web

La característica y la historia del usuario son funcionalidades más específicas, que puede probar fácilmente con las pruebas de aceptación. A menudo se recomienda que sean lo suficientemente granulares como para caber en una sola iteración.

Las funciones suelen describir lo que hace su software:

Característica
- Edición de la información del cliente a través del portal web

Las historias de usuario tienden a expresar lo que el usuario quiere hacer:

Historia de usuario
Como empleado de banco,
Quiero poder modificar la información del cliente
para que pueda mantenerlo actualizado.

No creo que exista realmente una jerarquía entre los dos, pero puedes tener una si quieres o si se ajusta a tu forma de trabajar. Una historia de usuario puede ser una justificación específica para una característica o una forma específica de hacerlo. O puede ser al revés. Una característica puede ser una forma de realizar una historia de usuario. O pueden denotar lo mismo. Puede usar ambas: Historias de usuario para definir qué valor y características empresariales aportan para describir la restricción del software.

Historia del usuario : como cliente, quiero pagar con las tarjetas de crédito más populares. Característica es compatible con el API GOV-TAX-02 XML del gobierno .

También está la cuestión del escenario, que suele ser una forma en que se ejecutará una característica / historia de usuario. Por lo general, se asignan limpiamente a una prueba de aceptación específica. Por ejemplo

Escenario : Retirando dinero
Dado que tengo 2000 $ en mi cuenta bancaria
Cuando retire 100 $
Entonces recibo 100 $ en efectivo
Y mi saldo es de 1900 $

Así es como definimos esos términos donde trabajo . Esas definiciones están lejos de ser una definición matemática o un término estandarizado. Es como la diferencia entre un político de derecha o un político de izquierda. Depende de donde vivas. En Canadá, lo que se considera de derecha puede considerarse de izquierda en los Estados Unidos. Es muy variable.

En serio, no me preocuparía demasiado por eso. Lo importante es que todos en el equipo están de acuerdo en una definición para que puedan entenderse entre sí. Algunos métodos como scrum tienden a definirlos de manera más formal, pero elija qué trabajo le conviene y deje el resto. Después de todo, ¿no es ágil en Personas e interacciones sobre procesos y herramientas y ¿Software de trabajo sobre documentación completa ?

Epic : una historia de usuario muy grande que finalmente se divide en historias más pequeñas.

Historia de usuario: Una definición de un requisito de muy alto nivel, que contiene la información suficiente para que los desarrolladores puedan realizar una estimación razonable del esfuerzo para implementarlo.

enlace

Característica : una característica o capacidad distintiva de una aplicación o biblioteca de software (por ejemplo, rendimiento, portabilidad o funcionalidad).

enlace

Le advierto que no aplique una jerarquía demasiado rígida a estos términos. Tratamos de hacer eso en mi trabajo anterior. Dos veces. Ambos intentos fueron diferentes y las dos veces que descubrimos que nos habíamos limitado innecesariamente. La única constante fue la definición de Historia del usuario . Desde una perspectiva de planificación, una historia es el componente básico de un proyecto. Los términos más grandes (épica, característica, etc.) son efectivamente etiquetas . Las etiquetas son una forma fácil de permitir que exista una historia como parte de múltiples épicas y múltiples características al mismo tiempo. No vale la pena el esfuerzo mental por ser más estricto que eso.

Las etiquetas funcionan para Stack Exchange y también pueden funcionar para usted.

La forma en que trabajamos con Epics, Stories and Features es la siguiente

Al principio del ciclo del proyecto, encontramos Epics . Se trata de puntos de funcionalidad muy importantes, casi centrados en la comercialización. El tipo de cosa que puede usar en un resumen ejecutivo, como por ejemplo,

  

Nuestro nuevo sitio web permitirá a los clientes explorar productos, ver disponibilidad y precios, realizar pedidos y ver su historial de pedidos anteriores

Esto lleva a epopeyas como

• Buscar en el catálogo de productos
• Ver disponibilidad
• Ver precios
• Realizar pedido
• Ver historial de pedidos

Se escriben como historias de usuario (p. ej., como cliente, quiero navegar por el catálogo de productos para poder tomar una decisión de compra informada), pero servir solo como punto de partida para diez para lo que realmente se desarrollará y publicado.

Estas epopeyas se dividen en Historias de usuarios . Estos son viajes reales de usuario de extremo a extremo, muy limitados en su alcance y definidos de manera que se pueden estimar y planear independientemente, y desarrollarse , probado y liberado en un ciclo de lanzamiento.

La historia del usuario es la unidad de entrega. Es la historia de usuario que está completa o no está completa, se publica o no se publica.

Una Epopeya puede resultar en un gran número de historias de usuarios, no todas se desarrollarán o lanzarán al mismo tiempo.

Como ejemplo, la épica del Catálogo de productos de exploración puede dividirse en

• Navegar por la jerarquía de categorías
• Buscar por palabra clave
• Filtrar por atributos del producto (por ejemplo, rango de precios, marca, color, tamaño, etc.)

Nuevamente, cada uno de estos se escribiría en el formato, por ejemplo. Como cliente, quiero navegar por la jerarquía de categorías para poder navegar por los productos y profundizar en el producto más adecuado para mis necesidades.

En general, para la mayoría de nuestros proyectos, tenemos decenas de epopeyas y cientos de historias.

Ahora, a medida que avanzamos en el ciclo de vida de la historia, etiquetamos estas historias con Funciones . Por ejemplo, todas las historias de navegación, búsqueda, stock y precios se etiquetarán con, digamos, 'catálogo de productos'. Las historias de orden de pago con tarjeta de crédito se pueden etiquetar con una etiqueta de "tarjeta de crédito" y las que tienen que ver con el pago de PayPal se etiquetarán con una etiqueta "paypal".

Estas etiquetas sirven para agrupar historias que pertenecen, no porque sean diferentes tipos de actividades que realizan la misma actividad (por ejemplo, todas las historias de orden de lugar), sino porque deben publicarse juntas.

Por ejemplo, la historia de "realizar un pedido pagando con tarjeta de crédito" pertenece a la misma epopeya que la historia de "realizar un pedido pagando con PayPal", pero no es necesario que se publiquen juntas.

Mientras que, la historia de "realizar un pedido pagando con tarjeta de crédito", la historia de "procesar un reembolso de devolución en una tarjeta de crédito" y la historia de "permitir a los clientes administrar sus tarjetas de crédito guardadas en su cuenta" parecen pertenecer a otro. Todos ellos habrían sido etiquetados con la etiqueta de la característica "tarjeta de crédito". es decir, todos ellos pertenecen a la función "Tarjeta de crédito". No es muy útil liberar la posibilidad de realizar un pedido pagando con tarjeta de crédito, si no es posible procesar un reembolso de devolución a PayPal, o si no es posible administrar sus tarjetas de crédito guardadas en su cuenta

Nota : como regla general, es decir. Esto es, al final, una decisión de negocios. Si el tiempo de comercialización es importante, puede haber una razón legítima para ir a vivir con uno de estos y no con el otro.

Por lo tanto, las epopeyas sirven para dividirse en historias (relacionadas, pero separadas) que pueden desarrollarse de forma independiente, mientras que las Características sirven para agrupar historias que deben publicarse juntas.

Se podría decir que las epopeyas se descomponen en historias de usuarios, y las historias de usuarios se componen de características. Las historias que pertenecen a una característica son generalmente a través de epopeyas. Así, las epopeyas y las características son ortogonales, no en una jerarquía estricta.

En nuestra forma de trabajar, una vez que las epopeyas se han dividido en historias, pierden su propósito. No estimamos, ni planeamos epopeyas. No rastreamos el progreso en las epopeyas. No lanzamos epopeyas. Estimamos, planificamos y rastreamos historias de usuarios. Y lanzamos Características.

Estoy de acuerdo, como muchas respuestas, en que realmente no hay respuestas correctas, ya que estos son solo términos que pueden variar dependiendo de en qué campamento Agile esté basado y definitivamente puede crear su propio campamento como siempre y cuando todos en su equipo, incluidos los interesados externos, comprendan lo que significan. Es solo una forma de organizar su requerimiento.

La respuesta que me gusta es del campamento de Mike Cohn y es bastante simple.

enlace

• Epic es solo una gran historia (jerárquica)
• El tema es solo un grupo de Historias (como la etiqueta)

En realidad, evita el término "Característica". Supongo que es principalmente porque era un término común en el mundo tradicional de la cascada. Muchos campamentos ágiles tienden a usar diferentes términos para enfatizar las diferencias.

Entonces, en la definición de tu PM, la característica está en algún lugar en medio de la jerarquía de historia épica.

Aquí está mi info-gráfico de esta definición de mi artículo de InfoQ enlace ;-)

Las características y las épicas no son lo mismo.

• Una característica no es una historia de usuario.
• Una epopeya es una historia de usuario.
• Una historia de usuario puede ser una Epopeya.
• Una historia de usuario puede contener muchas características.
• Una característica puede cumplir de 1 a muchas historias de usuarios.

En las fases de planificación, las discusiones dan como resultado Historias de usuarios que normalmente se identifican como Epopeyas porque el esfuerzo por implementar soluciones para ellas es demasiado grande para lograrlas en unos pocos dias. Las características del producto se identifican durante esta fase. Pero eso es sólo un subproducto de la discusión. Las características se utilizan para planificar una hoja de ruta del producto, que es una discusión separada.

Los Epopeyas se toman y analizan más a fondo, lo que da como resultado Historias de usuarios para cada Epic. Las características y épicas se usan para impulsar las discusiones en las sesiones de refinamiento de la acumulación y Sprint Planning . En ese momento, las Historias de usuarios que salen de esas discusiones son refinadas , priorizadas y, en Sprint Planning , aceptado en sprints para su implementación.

Es solo descomposición del problema. Solo son historias, excepto con diferentes tamaños.

Personalmente prefiero no etiquetar sus tamaños, pero si lo haces también está bien. Pregúntele a PM cuál es la definición en su área de trabajo.

La jerarquía de backlog del producto depende en gran medida del tamaño del producto y de su modularidad (número de áreas de producto definidas).

Para proyectos pequeños: épico > La historia es más que suficiente; y llamas a la "característica".
Los grandes proyectos pueden parecerse a: Novel > Tema > Épica > Característica > Historia

El mejor ejemplo podría ser el siguiente:
Novel = MS Office
Theme = MS Word / MS Excel ...
Epic = Tablas / Directorio de fuentes ...
Características = Tabla básica / Esquema de color de tabla / Operaciones con celdas ...
Historias (para la característica 'Tablas básicas' dentro de 'Tablas' épicas) = Agregar tabla / Dibujar tabla / Insertar sin formato / Insertar columna ...

Lo que creo que es beneficioso tener en cuenta al definir su propia escala para el retraso es:
1. Historia: a) siempre posible dentro de un sprint; b) no siempre es comprobable para usuarios finales
2. Epic / Característica: a) no se ajusta a la duración de un sprint y debe descomponerse; b) siempre debe ser comprobable para los usuarios finales; c) Siempre se puede enviar, se puede monetizar: obtenga el ROI calculado para él 3. Al considerar agregar o no, Epic > Función en la sección o apégate a Epic > Historia: recomendaría insertar Característica entre Epic e Historia solo cuando: Epic no encaja en 1 Lanzamiento, por lo que debe definir el elemento enviable que se ajustará a 1 duración de Lanzamiento .

Espero que esto sea útil.

En nuestra organización tenemos lo siguiente:

Tema = Se usa para agrupar una colección de historias

Epic = Describe una gran historia de usuario (en realidad, un requisito) que debe dividirse en historias de usuario

Features = hace lo que dice en la lata, describe una característica del producto requerido

Historia de usuario = Este es el nivel de detalle más bajo del que se derivan las tareas.

Nuestra organización tiene más de 2,000 desarrolladores, por lo que la respuesta a esta pregunta es importante para una comunicación fluida y clara entre los cientos de equipos Agile que trabajamos juntos en nuestro producto común. Para una organización muy pequeña, puede tener una estructura muy simple que ni siquiera necesita ser jerárquica (como han respondido otros). Sin embargo, para las grandes organizaciones, definitivamente existe la necesidad de una jerarquía organizada, escalada y coherente, y ahí radica el problema de esforzarse por crear una jerarquía a partir de algo que no sea estrictamente jerárquico.

Por cierto, nos referimos a cada uno de estos niveles dispares como "elementos de trabajo". Algunas organizaciones (incluidos algunos de los encuestados anteriores) se refieren a niveles dispares como Historias o Historias de usuarios (y también lo hemos hecho en el pasado), pero esto nos pareció demasiado ambiguo, por lo que ahora nos referimos a ellos de forma genérica como Elementos de trabajo.

Lo mejor que hemos hecho "oficialmente" hasta ahora es seguir la estructura SAFe de Temas de inversión y epopeyas comerciales de Dean Leffingwell, que se encuentra en la parte superior (y la segunda desde la parte superior) de la jerarquía, luego las funciones debajo de eso, y finalmente las historias debajo Caracteristicas. Según Agile, las Tareas siempre están en Historias, por lo que tenemos cuidado de no reutilizar ese término más arriba. Elegimos seguir SAFe para tener al menos ALGUNA consistencia en todos nuestros equipos.

Pero esto sigue siendo insuficiente para nuestras necesidades. Definimos una característica como un producto claramente valioso para un consumidor de nuestro producto de software (es decir, enumeramos estas características en nuestros anuncios de próximas versiones). Y definimos una historia como una cantidad más pequeña de alcance y trabajo que puede entregarse en un solo Sprint por un solo equipo de desarrollo ágil. Ahora también estamos EMPEZANDO a seguir la definición de SAFe de tema de inversión y épica comercial a nivel de cartera (y no por debajo de este nivel). Y estamos EMPEZANDO A NO usar nuestras definiciones ANTIGUAS de "Tema" y "Épico".

Ahora estamos evolucionando lentamente en esta dirección, pero las ruedas del progreso avanzan lentamente. Todavía estamos luchando con la manera de dividir el trabajo en trozos pequeños para que podamos definir el trabajo y realizarlo sin problemas por parte de varios equipos. Para hacer esto, vemos la necesidad de una "Subcaracterística" que es más pequeña que una Característica pero más grande que una Historia. Las subcaracterísticas se pueden usar para los trozos de trabajo realizados en una característica por CADA equipo INDIVIDUAL, o los trozos de trabajo realizados por un equipo INDIVIDUAL en diferentes momentos (en diferentes Sprints, o incluso diferentes Releases).

También necesitamos múltiples niveles jerárquicos entre Feature y Business Epic, pero aún no hemos resuelto este, más que simplemente llamarlos "Temas", que sabemos que no es el término correcto, ya que se confunde fácilmente con SAFe Temas de inversión. Para algunos proyectos grandes (lanzamientos) tenemos de 5 a 8 niveles jerárquicos diferentes, cada uno de los cuales divide el trabajo en partes cada vez más pequeñas. Puede pensar que estos Temas son "Grupos de funciones", pero ese no es necesariamente el término correcto.

Creo que es importante tratar de usar términos que ofrezcan claridad en lugar de ambigüedad. Por lo tanto, cualquier persona que se refiera a una Historia significa la unidad de trabajo más pequeña que se puede realizar en un solo Sprint (excepto las Tareas bajo la Historia), y Sub-Feature significa la unidad de trabajo más pequeña en una Característica que puede realizar una sola equipo. Del mismo modo, un grupo de características es un nivel jerárquico por encima de la característica. Por encima de eso, se pone un poco borroso, por lo que solemos llamarlos Temas, y permitimos que los Temas sean padres e hijos de otros Temas. Intentamos restringir los niveles de Característica, Subcaracterística e Historia a un solo nivel cada uno (Las características no deben ser hijas de otras características) pero aún no tenemos el 100% de éxito en la restricción de esto.

Sé que podríamos usar "Etiquetas" para organizar algo de esto, pero las etiquetas no nos dan la estructura de desglose del trabajo organizacional que necesitamos para clasificar el trabajo entre todos nuestros equipos. Por definición, las etiquetas son ambiguas (relaciones de muchos a muchos), pero una jerarquía es estrictamente de uno a muchos.

La conclusión es que esto sigue siendo un trabajo en progreso para nosotros, y todavía estamos luchando con él. ¡Pero seguir las definiciones seguras de Tema, Épica, Característica e Historia nos hace avanzar en la dirección correcta!