¿Cómo escribes "historias" completables cuando todos los miembros de un equipo tienen una especialidad?

...los puntos de la historia pueden no significar lo mismo para cada área de especialidad

Cuando un miembro del equipo de Scrum estima una historia, no está estimando solo por su contribución a la historia. Lo que están haciendo es escuchar a todo el equipo y decidir el tamaño de la historia en función de la discusión.

Por ejemplo, para una historia en particular, el desarrollo de front-end puede ser simple, pero el desarrollo de back-end es difícil. Los desarrolladores de back-end describen por qué es difícil para el equipo y, como resultado , todo el equipo estimaría un tamaño de historia más grande.

Un miembro del equipo le dijo esto a un colega en una reunión de planificación:

"Acabas de decir que esto es realmente complicado, pero luego estimaste un 3. ¿No deberíamos aumentar nuestra estimación si realmente es tan difícil?"

Usando este enfoque, es posible que los equipos de especialistas realicen estimaciones de manera colaborativa y consistente.

Sin embargo, si tiene un equipo de especialistas, la capacidad de sprint tendrá que calcularse cuidadosamente. He visto equipos como este comenzar con estimaciones de puntos de historia, pero luego hacen estimaciones basadas en el tiempo en subtareas técnicas. Esto les permite verificar que un miembro del equipo en particular no esté sobrecargado. Por ejemplo, el equipo puede tener una velocidad de 30 puntos de historia, pero una selección particular de historias que suma 30 puede sobrecargar una disciplina.

En cuanto a las historias que se completan al final de un sprint, eso suele ser un signo de historias grandes. Intente desglosarlos tanto como sea posible mientras mantiene algo de valor comercial por historia.

Barnaby dijo:

Sin embargo, si tiene un equipo de especialistas, la capacidad de sprint tendrá que calcularse cuidadosamente. He visto equipos como este comenzar con estimaciones de puntos de historia, pero luego hacen estimaciones basadas en el tiempo en subtareas técnicas.

Esta es nuestra situación, y esto es lo que hacemos. Parte de nuestra planificación de sprint implica la coordinación para asegurarnos de que todos estén trabajando en la misma historia aproximadamente al mismo tiempo, y que las tareas se hayan dividido para asegurarnos de que nadie bloquee a los demás. Tenemos una idea aproximada de la capacidad de cada especialidad durante el sprint y elegimos las historias en consecuencia.

También identificamos protocolos de enlace del sistema (es decir, puntos en los que podemos integrar contribuciones de especialistas individuales) lo antes posible, especialmente en todas las API, incluso si eso significa falsificar algunas de las entrañas. Esto ayuda a evitar el problema de "no funciona hasta el final". (Es posible que sus desarrolladores no quieran hacer esto; el mío no. Insistí y ahora todos vemos el valor de tratar de cerrar esos bucles temprano para que podamos detectar los problemas temprano).

En realidad, solo pueden entregar estimaciones para cada especialidad (por ejemplo, datos frente a back-end frente a front-end).

Rechazaría esto. Mi discurso estándar es "está bien, pero has visto cuánto tiempo le tomó a otro equipo hacer algo similar a esto antes, así que calcula en base a eso". Esto fomenta la propiedad del equipo de todo el sprint y también puede ser útil para estimar y transferir conocimientos, por ejemplo:

Desarrollador de Especialidad A, estimando la tarea de Especialidad A: Yo lo llamaría un 4. Desarrollador de Especialidad B: ¿En serio? Tenía eso como un 7, porque suena como que OtherThing que hiciste fue un 7. SpecialtyA Dev: Oh, hm, tienes razón, me olvidé de alguna pieza. O: SpecialtyA Dev: Bueno, es similar, pero implementar OtherThing hizo toda la parte difícil por primera vez. Ahora podemos reutilizar parte de esa maquinaria, por eso es un 4.

Realmente me gusta esta pregunta porque con qué frecuencia me he encontrado lidiando con equipos que luchan con problemas similares. Su pregunta también apunta a un puñado de conceptos de desarrollo ágil muy importantes, como la estimación mediante puntos de la historia, la velocidad y la definición de hecho.

Responderé de la forma más concisa posible.

¿Cómo define las historias de usuario que se pueden completar al final del sprint?

Las historias de usuario son amplias por diseño para fomentar el diseño emergente, la colaboración en equipo en persona y, lo que es más importante, para eliminar el desperdicio, común en la gestión de proyectos tradicional donde los documentos de requisitos se preparan y aprueban antes de que se haga nada más.

Por lo tanto, aliente al propietario de su producto a escribir historias de usuarios de manera tan amplia como ahora. Sin embargo, asegúrese de alentar el refinamiento de la cartera de productos a lo largo del sprint, de modo que antes de la próxima reunión de planificación del sprint, las historias de usuario de alto valor (que el propietario del producto espera que se entreguen durante el próximo sprint) se descompongan con suficientes detalles para cumplir con los objetivos acordados por el equipo. Definición de Listo (DoR) . Luego, durante la planificación del sprint, todo el equipo descompuso aún más cada una de las historias de usuario seleccionadas por el equipo de desarrollo, quien obviamente agregaría las subtareas técnicas como el diseño de la interfaz de usuario, el diseño de back-end, etc.

Al igual que DoR, el equipo también debe acordar la Definición de Listo (DoD) . Las historias que cumplen con la definición de terminado al final del sprint se consideran "terminadas", todo lo demás vuelve a la cartera de productos y podría terminar siendo seleccionada nuevamente por el propietario del producto según las prioridades comerciales. Obviamente, cada historia también puede tener un criterio de aceptación que debería cumplirse como el Departamento de Defensa.

¿Cómo funciona la puntería en equipo donde todos tienen una especialidad?

En primer lugar, supongo que al señalar te refieres a la "estimación" utilizando puntos de la historia. De lo contrario, comente y actualizaré mi respuesta en consecuencia.

Entonces, en ágil, la estimación no se realiza utilizando horas-hombre o días-hombre como con los enfoques tradicionales. Los puntos de la historia son abstractos, nuevamente por diseño. Hay muchos beneficios por usar este tipo de estimación, pero dos de los que me gustan son:

1. Los puntos de historia permiten a los desarrolladores de diferentes antecedentes (junior, senior, UI, back-end, arquitecto, probador, etc.) tener una unidad de medida común, si es posible.
2. Los puntos de la historia fomentan la estimación rápida, por lo que sea que valga, sin perder demasiado tiempo en una actividad que no agrega valor.

Entonces, durante la planificación del sprint, deje que el equipo estime en colaboración. Hacer esto bien o mal no importa. Hay muchas técnicas para permitir esto, siendo el póquer de planificación la más común.

¿Cómo puedes, a su vez, usar este apuntar con velocidad en este caso?

La velocidad es bastante sencilla de calcular. Toma la suma de los puntos de historia completados en el último sprint (o el promedio de los últimos sprints) y eso es todo. Nuevamente, la velocidad simplemente pretende proporcionar un indicador al equipo de cuánto trabajo pueden administrar por sprint. Si hacen más, genial. Si hacen menos, que lo discutan entre ellos. Nada más.

Comentarios adicionales

Su objetivo como Scrum Master debe ser alentar a su equipo a ser cada vez más multifuncional. Esto es excepcionalmente difícil, pero solo un equipo con un mínimo de especialistas se vuelve realmente eficiente y casi sin desperdicio. Debe leer sobre ScrumFall , un problema común en los equipos Scrum/Agile que debe esforzarse por mantener alejado de su equipo.