Scrum: ¿cómo deberíamos discutir el enfoque de las historias de usuario?

La belleza de los equipos autoorganizados es que su equipo puede decidir cómo organizar el trabajo. Si el equipo siente que una forma diferente de organizar el trabajo es mejor, el equipo es libre de cambiar la forma en que se organiza.

El momento ideal para discutir esto es durante la retrospectiva del sprint, donde

El Equipo Scrum inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definición de Terminado.

y

El Equipo Scrum identifica los cambios más útiles para mejorar su efectividad. Las mejoras más impactantes se abordan lo antes posible.

Adelante con tus preguntas:

¿Existen mejores prácticas para mantener estas discusiones con todo el equipo?

No hay prácticas que siempre sean las mejores, porque diferentes equipos operan en diferentes circunstancias y, por lo tanto, pueden tener diferentes necesidades. Es por eso que Scrum otorga a los equipos la autoridad para decidir qué funciona para ellos, en su proyecto particular.

Pero si el equipo piensa que estas discusiones serían mejores con todo el equipo presente, el equipo puede hacerlo. Al igual que decidió mantener estas discusiones con algunos miembros del equipo, puede decidir mantenerlas con todos los miembros del equipo :-)

O podría decidir dividir la discusión, discutiendo las cosas importantes (para alguna definición de "importante" su equipo resolvería) con todo el equipo y los detalles en una reunión más pequeña.

De esta manera, todo el equipo podría consultar sobre las cosas importantes, dejando los detalles al cuidado de los miembros del equipo que realmente hacen el trabajo.

Otras ocasiones son cuando se discute un cambio durante el stand-up, donde aparece algún requisito adicional para una historia.

Eso suena potencialmente problemático. Si el cambio fue lo suficientemente importante como para justificar la discusión del equipo, es probable que sea lo suficientemente importante como para afectar la planificación del trabajo y, en cuyo caso, debería haberse discutido antes del sprint, y posiblemente con el propietario del producto, que está a cargo del comercio de costos/características. fueras Mi equipo trataría de identificar y luego discutir dichos cambios en la reunión de refinamiento del backlog, donde se estiman las historias de los usuarios y se hacen compensaciones de costo/función.

¿O estoy demasiado involucrado y debería centrarme en el código en sí, no en el enfoque?

Al contrario: Scrum requiere que los miembros del equipo miren más allá de su propio trabajo. ¿De qué otra forma podría organizarse el equipo y seguir perfeccionando su forma de trabajar para adaptarse mejor a las necesidades del proyecto?

Lo que citó y lo que está diciendo no parece estar en conflicto conmigo. En general, cuando las personas dicen que las historias de usuario son un marcador de posición para una conversación, se refieren al equipo y la persona que solicita la función.

En cuanto a la conversación dentro del equipo, Scrum siempre la agradece. Ciertamente, el equipo debería discutir los elementos de la cartera de pedidos que ingresan al equipo tanto en el refinamiento de la cartera de pedidos como en la planificación de Sprint. Pero nada dice que deba detenerse allí.

Lo que escucho de usted es que el proceso del equipo es menos que ideal y lleva a gas en la comunicación. No hay grandes preocupaciones, ya que el proceso de cada equipo tiene estos y siempre hay margen de mejora. El mejor consejo que podría dar es plantear esto en la Retrospectiva y proponer que el equipo experimente con diferentes formas de resolver estos desafíos.

La reunión de planificación es una oportunidad para que todo el equipo discuta juntos las historias que planean hacer en el próximo sprint. También podrían tomarse este tiempo para repasar cada historia en detalle, tal vez incluso dividir cada una en tareas concretas. Tal enfoque ayuda a reunir la experiencia y puede ayudar a abordar los primeros dos ejemplos que brinde.

Con respecto al tercer ejemplo, los requisitos perdidos que se notan en algún lugar a mitad del sprint generalmente no se agregan al sprint actual, para combatir el avance del alcance y mantener las estimaciones en el buen camino. En cambio, se crea una nueva historia para ellos, que se puede iniciar en el próximo sprint. (Pero, por supuesto, esto puede depender de cuán crítico sea el requisito). En cualquier caso, una reunión de planificación más exhaustiva debería reducir la posibilidad de que se pierdan los requisitos en primer lugar.

1. Historias construidas por dos miembros del equipo.

No es tu problema. La idea detrás de SCRUM es no tener a todo el equipo trabajando en comité, y los equipos efectivos no tienen todas las historias revisadas por todos.

El propietario del producto se asegurará de que se entierren las historias no valiosas, si da un paso atrás y deja que hagan su trabajo.

2. La solución aumenta la deuda técnica

No es lo mismo deuda técnica que funcionalidad adicional.

La deuda técnica es cuando se compromete código que debe probarse manualmente, ya que ahora incurre en un costo que se repite independientemente de la solución. La deuda técnica es cuando se escribe una solución que se sabe que requiere una reescritura, porque se basa en bibliotecas y marcos obsoletos.

La funcionalidad añadida es el proyecto, y el propietario del producto prioriza la adición de funcionalidad ocultando las cosas que no se necesitan o cancelándolas por completo.

3. Cuando se discute un cambio durante el stand-up, a veces aparece un requisito adicional para una historia.

La historia no se preparó lo suficiente antes de ser aceptada. Esto sucede y, a menudo, no es un bloqueo real, pero la persona que lo informa solo quiere mostrar que está trabajando duro. Intenta ignorarlo.

En los casos en que el problema se convierte en un verdadero obstáculo, la historia no se entregará; y el equipo recibe un golpe de medición por aceptar una historia que no pudieron entregar (y no detallaron lo suficiente en la preparación de la historia).

Si una persona quiere comenzar a detallar la historia, se debe crear una nueva historia para capturar los detalles. Esta historia "detallada" debe tener criterios de aceptación para saber cuándo se realizará, y debe puntuarse por el esfuerzo como todas las demás historias. Tomarlo durante un sprint es un avance del alcance en el sprint, y este tipo de avance del alcance a menudo se denomina "pico". La historia anterior debe establecerse en un estado bloqueado y debe permanecer en el sprint, ya que es parte de la promesa de entrega del sprint.

Esto hace que el sistema funcione bien porque está diseñado para crear fallas que brindan retroalimentación al equipo cuando el equipo no es efectivo. En retrospectiva, con un recuento honesto de las fallas, el equipo debe notar que la causa raíz de la falla fue que la historia no estaba bien arreglada y que deben tener especial cuidado para asegurarse de no comprometerse con historias mal arregladas sin primero programar una historia para mejorar la preparación (o realizar la preparación durante el tiempo de inactividad en el sprint cuando todas las demás tareas están completas).

Un par de sugerencias muy rápidas que pueden ayudar con algunos de sus problemas:

• Reuniones de refinamiento : si actualmente no está utilizando las reuniones de refinamiento de Sprint, esto podría ayudar a difundir el conocimiento de las historias de los usuarios, así como a acordar un diseño técnico de alto nivel.
• Planificación de Sprint : aquí es cuando puede dividir las historias de usuario en tareas, lo que nuevamente crea visibilidad de lo que se está haciendo.
• Reuniones de refinamiento técnico : también he visto equipos que tienen sesiones periódicas de "refinamiento técnico" en las que un campeón asignado por el equipo a cada historia de usuario presenta el enfoque técnico al equipo y se acuerda.