Tenemos una historia "pesada" que no se puede descomponer en historias más pequeñas. Abarcará varios sprints.
Podemos descomponer la historia en tareas, pero las tareas parecen ser abstracciones que duran solo unas pocas horas.
Lo que necesitamos es una abstracción que impulse cada sprint, con un resultado bien definido (similar a una historia, pero interno), estimación de puntos, etc. ¿Qué es más pequeño que una historia, pero más grande que una tarea? ¿Cómo se suele manejar algo así?
En las ocasiones en que esto ha sucedido con mis equipos, buscamos las porciones comprobables más pequeñas que podamos hacer, incluso si sabemos que no las publicaremos. Por ejemplo, nos estábamos integrando con un tercero y queríamos hacer un inicio de sesión único entre ellos y nuestro sitio. Nuestra historia fue:
In order purchase products on the 3rd party site
As a registered customer
I want to log in using my existing information
Es un poco difícil de romper, por lo que todavía tiene algún valor para el cliente, pero se necesitaron un par de semanas de esfuerzo para que el inicio de sesión único funcionara, mucho más de lo que aceptaríamos en un sprint.
Terminamos con una serie de historias más pequeñas que, si bien eran bastante técnicas, tenían un resultado que podíamos demostrar a un propietario de producto no técnico. Para llegar allí, observamos qué pasos debía tomar el equipo para llegar allí técnicamente e identificamos dónde había resultados que la OP estaba feliz de verificar.
Sin embargo, todavía teníamos un par de fragmentos grandes sin un resultado verificable. Para evitar esto, creamos una página web dentro de nuestra aplicación que mostraría cosas como ID de usuario, roles de usuario, etc. que se pasan a la tercera parte para que el PO pudiera ver que la aplicación estaba haciendo algo y obtener la información correcta, aunque todavía no estaba haciendo nada con los datos.
También codificamos por colores las historias separadas que formaban parte de la gran historia, de modo que pudimos ver el progreso de toda la función en nuestro tablero.
No es lo ideal, pero ese es el mejor enfoque que hemos logrado hasta ahora.
Lo que necesitamos es una abstracción que impulse cada sprint[.]
Esto se conoce comúnmente como el Sprint Goal. El Sprint Goal es un componente esencial (pero a menudo pasado por alto) de las implementaciones exitosas de Scrum.
Tenemos una historia "pesada" que no se puede descomponer en historias más pequeñas. Abarcará varios sprints.
Esto le causará dolor a largo plazo. Es muy raro que una epopeya no se pueda descomponer en historias del tamaño correcto, pero puede suceder si:
Su historia "pesada" probablemente sufre de más de estas áreas problemáticas, y sospecho que podría clasificarse como una historia compleja . En User Stories Applied Mike Cohn dice:
A diferencia de la historia compuesta, la historia compleja es una historia de usuario que es inherentemente grande y no se puede desagregar fácilmente en un conjunto de historias constituyentes. Si una historia es compleja debido a la incertidumbre asociada con ella, es posible que desee dividir la historia en dos historias: una de investigación y otra de desarrollo de la nueva función.
En otras palabras, tales historias ciertamente se pueden descomponer, pero el nivel adecuado de descomposición puede requerir primero cambios en la forma en que construye historias o administra la Lista de Producto. Definitivamente vale la pena investigar estos cambios si la alternativa es comprometerse con una epopeya que ignora los principios iterativos básicos del marco.
Podemos descomponer la historia en tareas, pero las tareas parecen ser abstracciones que duran solo unas pocas horas.
Esto esta bien. La granularidad es una cuestión de gustos, pero aquí hay algunos principios de granularidad de Scrum ampliamente aceptados:
Si las tareas se vuelven mucho más grandes, se vuelven difíciles de estimar con precisión. Hágalos demasiado pequeños y solo aumentarán la sobrecarga del proceso.
Sin embargo, cualquier historia de usuario determinada debe caber en un solo sprint antes de que se acepte. De lo contrario, ignorará el principio de la caja de tiempo y caerá en la trampa de que "el 80% de la historia está terminada en un 20 %".
Lo que necesitamos es una abstracción que impulse cada sprint... [hacia] un entregable bien definido[.]
Este es el propósito principal del Sprint Goal. Cada sprint, el propietario del producto y el equipo deben acordar un objetivo de sprint general que capture el espíritu del incremento mínimo liberable para el sprint. Las historias que no abordan el Sprint Goal probablemente deberían ser filtradas o despriorizadas por el propietario del producto durante la preparación del backlog o la planificación del Sprint.
Otro uso del Sprint Goal es proporcionar la medida fundamental del éxito del Sprint. Por definición, cualquier sprint que satisfaga su Sprint Goal es un sprint exitoso.
Tampoco es raro tener sprints que no producen una función liberable (por ejemplo, sprints dedicados a requisitos no funcionales, cadenas de herramientas o mejoras de procesos, o picos de historias). En el caso de picos de historia, por ejemplo, un Sprint Goal como:
Revise la literatura disponible sobre la efectividad de agrandar un Jabberwock.
podría ser perfectamente apropiado. Tal objetivo es medible, posiblemente demostrable y, sin duda, un candidato para un marco de tiempo rígido.
Scrum sin Sprint Goals es algo parecido a volar sin un avión: puede ser conceptualmente más simple agitar los brazos, pero es poco probable que llegues a tu destino previsto.
¿Estás seguro de que no puedes dividir la historia?
Si tiene, por ejemplo, alguna historia sobre "el usuario puede suscribirse para recibir correos electrónicos semanales", puede dividirla en algo como "el sistema puede enviar correos electrónicos", "el sistema puede registrar a los usuarios para recibir correos electrónicos" y luego "el usuario puede suscribirse". o algo así.
¿No puedes separar tu historia de manera similar?
kthxbai
Lo que necesitamos es una abstracción que impulse cada sprint...
Por lo general, las historias se utilizan para impulsar el sprint. Las historias deben tener criterios de aceptación claros para que todos los involucrados puedan comprender el estado de la historia. El PO debe aceptar una historia lo antes posible (no al final de un sprint o en la revisión del sprint).
Por lo general, cada historia se divide en tareas que duran aproximadamente entre 1h. -1 penique Con esto, puede realizar un seguimiento de sus tareas de sprint-burn-down usando un gráfico . Esto te ayuda a reconocer patrones como acelerar o ralentizar para impulsar tu sprint. Si comienza con 100 tareas para un sprint de 2 semanas, mide cada día cuántas aún están abiertas (incluidas las nuevas).
Algunos equipos muy maduros incluso no usan tareas, solo historias , que queman como lo describe Jeff Sutherland. Tienen alrededor de 100 a 200 historias que rastrean en un gráfico de quemado de historias.
Otro factor es la grandeza de una historia . Siempre me aseguro de que las historias se calculen (con planificación de póquer o similar) usando el llamado rango de Fibonacci 1,2,3,5,8,13,... Luego dejo que el equipo elija el límite superior de división: generalmente un Es necesario dividir una historia de tamaño 13 u 8 (verticalmente, no como por capa de sw-arch) antes de que se pueda trabajar en un sprint.
Con respecto a las estrategias de división de historias, consulte:
Te daré una respuesta directa: no hay nada más pequeño que una historia pero más grande que una tarea .
La buena noticia es que casi no hay historias que no se puedan desglosar.
Por ejemplo, digamos que su historia es "como usuario, quiero poder frobnicar el jimjab", y eso es definitivamente un mes de trabajo para varias personas. ¿A qué te dedicas? Probablemente, hacer esto requiere un cambio en la base de datos. Entonces, escribe una historia: "como desarrollador, necesito que se cambie la base de datos para poder implementar la historia de "frobnicate".
Tal vez necesite mejorar el arnés de prueba para que pueda validar los jimjams: "como probador, necesito que se modifique el arnés de prueba para poder probar la historia de "frobnicate".
Tal vez la superclase de la clase Jimjam deba extenderse: "como desarrollador, necesito que la clase MasterJab se extienda para poder implementar la historia de" frobnicate ".
Y así.
Dedique tiempo de calidad a pensar en ello, y estoy seguro de que puede dividir su historia (que en realidad es una epopeya) en historias del tamaño de un sprint. Dígase a sí mismo que puede hacerlo, y sucederá.
Si la historia es demasiado grande para caber en un sprint, entonces debería ser épica . Luego dividiría esta epopeya en historias más pequeñas y luego las dividiría en tareas. De esa manera, puede distribuir la finalización de la épica en varias iteraciones y, al mismo tiempo, poder completar las historias que la componen (y, por lo tanto, alcanzar su objetivo de sprint).
Si no puede dividir la historia en partes lo suficientemente pequeñas como para completarlas en una iteración, entonces hay un problema con la forma en que se escribió la historia o con las técnicas que está usando para descomponerla. No importa (desde mi punto de vista) si las tareas solo tomarán unas pocas horas, pero si cree que son demasiado pequeñas, puede intentar agrupar algunas tareas relacionadas para que no sienta que está midiendo algo que es demasiado pequeño para medir significativamente.
Ziffusión
voluntad