Actualmente, hemos dividido la "Reunión de planificación de Sprint" en dos partes:
SPM1: esto lo hacemos el primer día del sprint. El propietario del producto analiza las historias que han llegado al sprint actual desde Backlog. Todas las historias ya se analizan en Backlog, por lo que no tenemos mucho aquí. Principalmente discutimos si algo estaba pendiente o no estaba claro en la cartera de pedidos. Publicar esta reunión, PO se asegura de que el equipo tenga 100% de claridad sobre las historias.
SPM2: esta es una discusión puramente técnica. No incluimos PO aquí. Dividimos las historias en la tarea comprobable para que el miembro del equipo obtenga una visión general amplia de lo que debe ejecutarse, lo que se espera de cada tarea y facilite el desarrollo paralelo.
Los problemas a los que nos enfrentamos:
Algún contexto adicional:
¿Estamos haciendo algo mal aquí? ¿Deberíamos dividir la "Reunión de planificación de Sprint" en dos partes como esta, es una práctica estándar de scrum? ¿Cómo debemos resolver estos problemas?
Tiene varios problemas de proceso. Los problemas de proceso tienen un costo. Esos costos deben ser visibles, y el costo de solucionar los problemas debe imputarse al proyecto para garantizar la transparencia.
Puede abordar su conjunto actual de problemas de proceso al:
El resto de esta respuesta realmente larga explica por qué y cómo debe hacer estas cosas.
Tienes varios problemas diferentes. Tal como lo veo, sus problemas secundarios se derivan de estas declaraciones que hizo en su publicación original.
El equipo no está convencido de la agenda exacta de la reunión[.]
Esto se debe a que el Refinamiento del Backlog y la Planificación de Sprint no se están aprovechando adecuadamente.
Nos cuesta crear tareas a partir de historias.
Es probable que esto se deba a que las historias no cumplen con los criterios de INVEST , tienen un tamaño o una estimación inadecuados, o porque su equipo y sus sprints carecen de cohesión.
El resto de las dependencias que sugirieron se pueden discutir por correo electrónico, etc.
Este es un gran olor a proyecto. Ignora el principio ágil de que "[e]l método más eficiente y efectivo de transmitir información a un equipo de desarrollo y dentro de él es una conversación cara a cara". También indica que al equipo le falta cohesión y no encuentra valor en la reunión de planificación tal como está estructurada actualmente.
Sin embargo, los problemas anteriores son en realidad problemas X/Y. Son síntomas de un problema de proceso mayor. Según la información proporcionada, veo varios problemas principales.
En resumen, si analiza todos los problemas, básicamente se reduce a una falla en aprovechar completamente el proceso Scrum y a la incapacidad de unirse como un equipo cohesivo en lugar de una colección de personas asignadas al mismo proyecto. Veamos algunas posibles soluciones.
Las siguientes soluciones abordan su proceso subyacente y los problemas de equipo y, por lo tanto, también deben abordar los problemas específicos de seguimiento que planteó en su publicación original. Sin embargo, las situaciones varían, así que adáptelas según sea necesario.
Todo su equipo debe participar en el refinamiento de la cartera de pedidos. Si bien los equipos más maduros a veces pueden salirse con la suya solo con el Scrum Master y el Product Owner involucrados en la reunión, la falta de cohesión en sus sesiones de Planificación de Sprint podría abordarse asegurándose de que todos abandonen Backlog Grooming con un objetivo claro en mente y una agenda establecida. .
El refinamiento de la cartera de pedidos es el momento para que el equipo se reúna con el propietario del producto para determinar qué características probablemente estarán dentro del alcance del próximo Sprint y para ayudar al propietario del producto a:
Si el equipo sale de la reunión de Refinamiento de Backlog con un Sprint Goal y un grupo de historias de usuarios potenciales para el próximo Sprint, ¡tienes una agenda!
Asigna menos tiempo para tus sesiones de Planificación de Sprint. Como regla general, descubrí que la mayoría de los equipos necesitan alrededor de 4 horas por semana de duración del sprint para la planificación. Obviamente, esto variará según la complejidad del proyecto y la madurez del equipo, pero si dedica más de 6 a 8 horas a planificar un sprint de dos semanas, es posible que tenga otros déficits de proceso, marco o habilidades en juego.
Al comienzo de la Planificación de Sprint, el equipo debe estimar su capacidad para el Sprint actual. Esta suele ser la velocidad, ajustada a las condiciones actuales (p. ej., vacaciones, cambios en la composición del equipo o complejidad de la fase actual del proyecto). Esta estimación de capacidad se usa para limitar el trabajo que se planificará para el sprint y para dar forma al pronóstico que se crea a través de Sprint Planning.
La primera mitad de Sprint Planning requiere que todo el equipo revise el Sprint Goal y trabaje con el Product Owner para seleccionar historias de la parte superior de Product Backlog que encajarán en un solo sprint. Esto puede implicar algunas discusiones, estimaciones, regateos y una nueva priorización sobre la marcha (por parte del PO) del Product Backlog. Ya sea que el equipo extraiga una historia o varias, el equipo es responsable de destacar las historias de la parte superior del Product Backlog en función de la capacidad estimada del equipo para el sprint.
La segunda mitad de Sprint Planning también requiere de todo el equipo, incluido el Product Owner. Esta es la parte donde el equipo desarrolla el Sprint Backlog, que son las tareas y dependencias necesarias para llevar cada historia a la Definición de Hecho. Si bien los equipos muy maduros a menudo pueden combinar los dos pasos, la mayoría de los equipos necesitan que este paso sea explícito.
El objetivo aquí no es hacer una estructura tradicional de desglose del trabajo. En cambio, es para definir las tareas necesarias para implementar la historia, o identificar lagunas de información sobre el alcance o la Definición de Listo para una historia en particular. En otras palabras, necesita un bosquejo aproximado de lo que se debe hacer para que se entiendan los criterios de aceptación de la historia antes de comenzar a trabajar.
Como ejemplo, imagina que tienes una historia como:
Como usuario,
quiero poder cambiar mi nombre de usuario en el sistema
para no tener que llamar al soporte técnico para corregir errores tipográficos simples que se cometieron durante la creación de la cuenta.
Una buena historia tiene un consumidor de valor (el usuario), una característica (cambiar el nombre de usuario) y un contexto para restringir el alcance de la implementación. Una gran historia suele ser lo suficientemente granular como para que las tareas de la historia sean evidentes. Si no lo son, es posible que deba revisar los criterios INVEST para el desarrollo de la historia.
Durante la definición de Sprint Backlog, el equipo debe averiguar en colaboración:
¡Eso es! Si la reunión comienza a desviarse hacia discusiones detalladas sobre cómo un desarrollador planea ampliar un widget, es probable que el equipo haya perdido el punto y el Scrum Master necesita arbitrar mejor el proceso.
Si su equipo carece de cohesión, madurez o experiencia con Scrum efectivo, entonces los problemas deben identificarse y discutirse durante la Retrospectiva del Sprint. Luego, el Dueño del producto debe crear historias de usuario en la Lista de pedidos del producto para que el equipo pueda asignar capacidad para abordar los problemas del proceso.
Por ejemplo, si el equipo tiene dificultades para escribir historias que cumplan con los criterios de INVEST , los problemas o las lagunas de conocimiento deben señalarse en la retrospectiva. El propietario del producto podría crear una historia de usuario como:
Como miembro del equipo Scrum,
quiero aprender cómo definir elementos de la cartera de productos (PBI) que sean más independientes
para que haya menos dependencias entre los PBI durante la planificación de Sprint.
Luego, la historia debe estimarse, priorizarse y asignarse a un sprint futuro como trabajo . Los problemas de proceso no se pueden tratar como trabajo oculto o sobrecarga; deben hacerse explícitos, y cualquier tarea asociada con ellos debe contarse explícitamente contra la capacidad del equipo como trabajo estimado o como deuda de tecnología/proceso no abordada que reduce la capacidad disponible.
En otras palabras, los problemas de proceso tienen un costo. Esos costos deben ser visibles, y el costo de solucionar los problemas debe imputarse al proyecto para garantizar la transparencia.
Me parece que el problema 2 es uno de un nuevo proyecto o equipo.
Con un poco de software existente, o un antiguo equipo incorporado, todos conocerán la arquitectura general del proyecto. Preguntas como "¿dónde pondremos esta lógica de negocios?" o "¿qué tecnología usaremos para resolver este problema" se respondieron hace mucho tiempo y no es necesario discutirlas.
Con un nuevo equipo o proyecto, lo mejor es resolver la estructura básica antes de comenzar. es decir. 'estamos creando un sitio web ac# mvc 4, alojado en AWS y utilizando una base de datos mssql. tal y tal framework JS, etc etc'
Haga que todos estén en la misma página arquitectónicamente para que tenga un marco para discutir preguntas técnicas cuando surjan.
Dividir el SPM en dos partes es el enfoque clásico. Primera parte, acuerdo sobre el backlog del sprint y el objetivo del sprint (involucra PO/Team). En la segunda parte, el equipo de desarrollo discute cómo cumplir los requisitos en la acumulación de sprint.
Problema SPM1 - Hay menos cosas que discutir. El equipo no está convencido de la agenda exacta de la reunión, dicen por qué no discutimos el tema completo solo en Backlog. (Tenemos dos backlogs en un sprint). El resto de las dependencias que sugirieron se pueden discutir por correo electrónico, etc.
Lo siento, pero no entiendo completamente tus problemas. Como escribí, esta parte está hecha para obtener un entendimiento común y un acuerdo sobre la acumulación y el objetivo del sprint. ¿Quizás el problema es que los requisitos que deben cumplirse en el sprint no se discuten en absoluto?
Problema SPM2: nos cuesta crear tareas a partir de historias. No tenemos una idea clara de hasta qué profundidad se deben discutir las cosas. ¿Debería incluirse en la discusión qué capa de código, es decir, BL, DAL, UI, qué código se colocaría O cómo se conectarían los diferentes sistemas entre sí, es decir, rompiendo la funcionalidad y dejando descansar al desarrollador?
Lo importante en la segunda parte es refinar los requisitos para tareas individuales, llegar a un acuerdo sobre quién es responsable de una tarea y definir cuándo se realiza una tarea.
Si las decisiones de diseño/técnicas se discuten en esta reunión o no, depende del equipo y la complejidad de los requisitos. También es posible envolver tales decisiones en tareas individuales.
Supongo que el mayor problema que tienes es que no has encontrado una estructura común y regular que todo el mundo respete y siga. Habla con tus compañeros de equipo y trata de acordar un procedimiento que aclare qué decisiones se toman en SPM2 y cuáles están fuera del alcance.
Sr. Hinsh - Martin Hinshelwood
disidente
Todd A. Jacobs