¿Qué hacer con las historias mal definidas?

TL;RD

No estás haciendo Scrum. Posiblemente esté haciendo algo similar a Scrum, pero su jefe debe leer la Guía de Scrum y el Scrum Master debe desempeñar un papel activo en la educación de este gerente sobre su función (si la tiene) en el proyecto.

Análisis

Quién gestiona la cartera de productos

[M]el gerente de mi equipo insiste en poner historias en el sprint que están mal definidas. Principalmente, lo que contiene la historia es gente con quien hablar para reunir los requisitos... [y] mi jefe insiste en que esta historia debe comenzar en este sprint.

Solo el Product Owner puede gestionar la priorización de historias en el Sprint Backlog. Si su "jefe" (que presumiblemente es la gerencia de línea) también actúa como propietario del producto, esto es un conflicto de intereses. Si no es el propietario del producto, se está excediendo en su papel como parte interesada dentro del marco de Scrum.

Además, mientras que el Equipo de Desarrollo debe trabajar en las historias de usuario de la Lista de Producto en secuencia ordinal, depende únicamente del Equipo de Desarrollo estimar las historias e identificar cuántas de esas historias principales caben dentro de cada Sprint. En otras palabras, acepta la cantidad de trabajo que está seguro de que puede terminar cada iteración; el volumen de trabajo nunca puede ser asignado desde fuera del Equipo de Desarrollo.

Recopilación de requisitos como historias

Nunca es aceptable tener un cambio significativo en el alcance o los requisitos dentro de un Sprint dado, a menos que el propietario del producto solicite una terminación anticipada y un regreso a la planificación del Sprint. Hacer que su organización viole este principio básico es un problema de proceso grave para el equipo y potencialmente rompe el marco.

Además, una de las mayores causas de fallas en el marco es la incapacidad de entregar un Product Backlog refinado a Sprint Planning. El propietario del producto (no la gerencia de línea, las partes interesadas ni nadie más) es responsable de entregar historias procesables a la reunión de planificación de Sprint.

Si bien está bien que el propietario del producto trabaje con Scrum Master y el equipo de desarrollo durante el refinamiento de la cartera de pedidos para aclarar o descomponer historias, la "recopilación de requisitos" no puede ser pragmáticamente una parte integral de una historia de usuario; en el mejor de los casos, se podrían agregar historias de usuarios adicionales sobre la recopilación de requisitos.

Un buen equipo multifuncional podría tener un analista de negocios. Incluso si no, como historia que dice algo como:

Como miembro del equipo de desarrollo,
necesito discutir la función XYZ con marketing
para ayudar a definir el alcance del trabajo de la función para el siguiente Sprint .

Ya sea que llame a esto un aumento de la historia o simplemente la recopilación de requisitos, esta es una historia aceptable porque hace que el costo del proyecto sea claramente visible (por ejemplo, que la recopilación de requisitos no es gratuita) y permite que la historia refinada se incluya en la cartera de productos. durante el Refinamiento del Backlog para ser priorizado por el Dueño del Producto, y eventualmente estimado y aceptado por el Equipo de Desarrollo durante algún Sprint futuro una vez que la historia alcance la parte superior del Backlog del Producto.

Scrum Master como educador y árbitro

El Scrum Master es el árbitro del proceso. Cuando vea "faltas de marco" como esta, debe sacar la tarjeta roja y hacer sonar su silbato metafórico. Además, debe brindar una educación adecuada sobre el marco, sus reuniones y artefactos definidos, y los roles y responsabilidades dentro del marco Scrum y la organización para todos en la organización. Si su jefe es o no correctamente un miembro del equipo es algo que no puedo evaluar (aunque sospecho que no), pero su papel como Scrum Master es trabajar con él para definir formas apropiadas para que interactúe con el equipo. dentro del alcance del marco.

Si no puede hacer eso, o si él no está dispuesto a adaptarse a los requisitos del marco, es posible que desee comenzar a desempolvar su currículum. No importa si el problema es un Scrum Master sin experiencia o un gerente de línea de comando y control; ambos son ingredientes clave que estadísticamente probablemente conducirán al fracaso del proyecto y, a menos que el título de su trabajo sea "chivo expiatorio profesional", no me quedaría en una situación que probablemente conduzca a un choque de trenes en mi carrera.

Como siempre, su millaje puede variar.

CodeGnome tiene un buen resumen de la causa raíz. Su jefe no entiende o no está convencido de cómo funciona Agile. Ese es un problema bastante grande. Eso cae en problemas de adopción ágil, que es una pregunta más importante que hizo.

La solución a corto plazo, para este sprint, es la prueba de aceptación. Tómese unos minutos con su jefe y descubra cuál sería su medida si la función se realiza. Aplique la técnica de los 5 por qué y profundice. Se puede hacer con bastante rapidez, para no "perder" su tiempo. Con una sólida comprensión de lo que él considera un éxito, sus desarrolladores deberían poder descubrir qué construir.

Mejor-

Su jefe probablemente haya identificado la incertidumbre técnica a la que se enfrenta. Para él, es un riesgo. Por eso quiere que la historia empiece ahora; para que este riesgo pueda materializarse.

En lugar de comprometerse a hacer algo, acepte la incertidumbre y comprométase a tener algo sobre lo que pueda obtener retroalimentación. Divida esto en una espiga, con el resto de la historia a continuación.

La adherencia rígida a los principios Agile/Scrum en estas situaciones tiende a empujar los elementos de alto riesgo (y generalmente de alto valor) más abajo en la cartera de pedidos. Incluso tratar de obtener criterios de aceptación claros sobre algo que la empresa nunca ha probado antes puede ser complicado. Por supuesto, tenga la conversación con su jefe, pero hágale saber que pasarán más de dos semanas hasta que termine y que lo mantendrá actualizado con el progreso.

Si, después de esto, su jefe todavía insiste en exigirle estimaciones rígidas frente a la incertidumbre, entonces es un idiota y es hora de encontrar un nuevo trabajo.

Si desea obtener más información sobre el análisis de picos y cuándo hacer cada uno, consulte Cynefin o algunos de los artículos recientes que he escrito sobre BDD e incertidumbre .

Es sencillo.

Sea duro y elimine toda la historia y haga que la persona que la escribió la reescriba correctamente + informe al jefe, al CTO y al CEO. Es lo único que funciona.

Los sabios construyen y destruyen.

Creo que hay un problema más profundo, si tu jefe te dice que hagas algo que no puede definir correctamente. Pero a partir de la poca información que diste, no puedo juzgar qué podría ser o no.

Dicho esto, intentaré abordar tu problema actual:

Si no puede decidir si la historia es épica o no, trátela como si fuera épica. Primero, separe las historias para las cosas que los desarrolladores saben cómo resolver. Tira de estos. Luego separe las historias para una mayor investigación sobre las cosas de las que no están seguros. Calcule cuánto esfuerzo desea dedicar a la búsqueda de soluciones. Saca estas historias también, si encajan. Lo que queda es una historia mal definida con un ominoso "descanso". No puedes tirar de eso.

A medida que los desarrolladores trabajan en el sprint, encuentran soluciones a las historias de problemas, luego el "resto" desaparece, o obtienen, al menos, una mejor comprensión del problema. Si el problema no se resolvió, entonces pueden estimar mejor el esfuerzo restante para el próximo sprint.

El punto crucial ahora probablemente sea cuánto invertir en las historias de investigación. Esto depende de la importancia de las historias para su jefe/cliente (por cierto, ¿quién de ellos es el PO? Solo debería haber uno...). Calcule más esfuerzo, si no está seguro y la parte es crucial. Menos, si es opcional.

¡Espero que esto ayude!

¿Has oído hablar de los 5 porqués ? Vea si puede obtener algo de contexto para las historias que quieren agregar.

¿Es porque su equipo es mucho más consistente en la entrega de valor? Muestre que agregar trabajo conduce a la multitarea que lo ralentizará.

¿Es debido a una dependencia de fecha? Haga que esa información sea transparente y negocie | priorice según el costo de la demora

¿Es porque tu jefe simplemente no sabe cómo escribir historias? Trabaje con ellos para mejorar y comprender que existen criterios de aceptación para el trabajo que se inicia de la misma manera que los hay para el trabajo que se completa.

¿Es porque creen en la presión extrínseca sobre la motivación intrínseca? Numerosos estudios muestran que esto es perjudicial para el rendimiento.

Cambiar la organización , o cambiar la organización.

En mi opinión, si el jefe requiere esta característica con tanta fuerza es porque es algo que realmente necesita para el negocio y, en última instancia, eso es lo que paga el salario de todos.

SCRUM es un gran conjunto de herramientas que ayuda a ser más productivo, pero a veces sus reglas estrictas no se aplican muy bien al mundo real.

Por supuesto, el jefe debe comprender mejor cómo funciona Scrum y tratar de adaptarse a él. Es como si su jefe estuviera tratando de conducir un automóvil pero se negara a usar el volante, el automóvil podría llegar a alguna parte, pero difícilmente a donde se propone.

Aunque estas consideraciones deberían haberse abordado antes, ahora se enfrenta a una situación que parece una emergencia. Si su barco se está hundiendo, puede que no sea suficiente planificar el cierre del agujero durante el próximo sprint, aunque es posible que no se haya acordado cerrar los agujeros en el casco en la planificación del sprint. Mantenerse a flote tiene prioridad en cualquier procedimiento.

Aconsejaría cumplir con la solicitud sobre la base del "mejor esfuerzo", tratar de retrasar la especificación adecuada de la historia para que al menos pueda trabajar en ella sabiendo lo que se requiere de usted. Básicamente intente adoptar Scrum tanto como pueda, pero recordando que esta es una situación de emergencia.

También anotaría todo y en la próxima revisión del sprint lo discutiría con el equipo, trataría de obtener propuestas sobre cómo abordar futuras situaciones similares, y luego es posible que necesite conversar con el jefe para explicarle las consecuencias de su solicitud, y estarás en condiciones de discutir propuestas efectivas (del equipo) y como no vendrán solo de ti, sino de todo el equipo, el jefe no podrá descartar cosas fácilmente.

Tú, el equipo y el jefe estáis en el mismo barco, las acciones de todos tienen consecuencias, todos tenéis el mismo objetivo, pero diferente visibilidad.