¿Cómo administrar los puntos de la historia cuando varios desarrolladores trabajan en 1 historia?

Al estimar las historias de los usuarios, todos deben estimar el esfuerzo total que le llevará al equipo terminar la historia. Por lo tanto, el desarrollador de back-end no solo debe estimar el esfuerzo que le llevará hacer su parte, sino que su estimación también debe incluir el esfuerzo para el front-end, el diseño y todas las pruebas (y similares para los otros miembros del equipo) .
La ventaja de usar puntos de historia aquí es que los valores son relativos al trabajo estimado previamente y la mayoría de las personas pueden estimar si algo es menos/más/mucho más trabajo que una historia de referencia, incluso si no tienen las competencias para realmente realizar el trabajo en sí. De esta manera, el desarrollador front-end puede tener en cuenta el trabajo de las otras disciplinas al hacer su estimación del esfuerzo completo para terminar una historia.

Una vez que tenga a todos estimando el esfuerzo completo, aún es posible que diferentes personas presenten estimaciones diferentes. Las razones habituales para esto son

• Los criterios de aceptación de la historia no son lo suficientemente específicos, lo que hace que algunos desarrolladores vean la historia más amplia que los demás.
• Algunos desarrolladores ven riesgos o esfuerzos adicionales que otros pasan por alto
• A veces, el trabajo con el que no está familiarizado parece engañosamente simple o complejo, y eso se tiene en cuenta en la estimación.

Si hay diferencias significativas en las estimaciones, se debe llevar a cabo una discusión entre el equipo para averiguar de dónde provienen esas diferencias y si todos están en la misma página.
Con su ejemplo, es probable que el desarrollador de back-end haya pasado por alto la cantidad de esfuerzo que se necesita para obtener todas las animaciones correctas (o pensó que sería fácil).

Después de que todos hayan tenido la oportunidad de decir lo que consideraron al llegar a su estimación, puede hacer una nueva ronda de estimaciones para esa historia. Lo más probable es que las estimaciones estén mucho más juntas.

Si solo hay pequeñas diferencias entre las estimaciones, puede optar por elegir solo uno de los valores (por ejemplo, el valor promedio o el valor en el que se encuentra la mayoría de las personas).

Acabo de encontrar esta publicación (bastante antigua).

Estoy gestionando un equipo de frontenders y backenders dedicados. Será un día frío en el infierno, cuando empiecen a hacer el trabajo del otro :-)

Mi preocupación con el puntaje de la comunidad es que le da una velocidad falsa al equipo, en el caso de tener desarrolladores Front-end y Back-end dedicados respectivamente.

EJEMPLO: Digamos que una historia termina en 20 puntos de historia, después de una discusión saludable en Refinamiento. De estos 20 puntos, claramente fueron los desarrolladores de backend los que enfatizaron la complejidad de construir su parte, mientras que los frontenders solo necesitaban implementar una nueva forma. Entonces, los backenders representan el 80% de los puntos de la historia (por así decirlo, son los que subieron el puntaje). Ahora, digamos que el equipo tiene 4 backenders y 2 frontenders. Y hacen la historia anterior en el sprint. Todo está bien, y se podría decir que la velocidad es de 20 puntos de historia por sprint.

Siguiente refinamiento, se cambian las tornas, el frontend es una pesadilla, el backend es muy sencillo, pero aun así suma 20 puntos de historia. Dado que los frontenders ahora tienen que hacer el 80% de una historia de 20 puntos, con solo 2 frontenders para hacerlo, ¿cómo afecta eso a la velocidad?

En aras de la previsibilidad y obtener una velocidad confiable, creo que la puntuación de la comunidad tiene algunos defectos importantes. Desafortunadamente, todavía tengo que encontrar la solución para ellos :-)

Durante la planificación , las sesiones de póquer promedian (redondean hacia arriba) las estimaciones de puntos de la historia que son cercanas entre sí. En su ejemplo, esto sería 2 puntos de historia.

Digamos que usas la escala de Fibonacci :

0 1/2 1 2 3 5 8 13 20 40 100

Cuando las estimaciones estén separadas por más de 3 pasos, diga 1 y 5, luego discuta y vuelva a votar. Cuando las estimaciones estén a menos de 3 pasos, digamos 2, 3, 5, promediarlas redondeando hacia arriba.

La razón para promediar es porque no desea gastar demasiado en discusiones sobre cosas en las que el equipo está relativamente de acuerdo. Como los puntos de la historia se usan como un pronóstico, no es tan importante que sean exactos. El margen de falla compensará en promedio en todas las estimaciones.

Obtuve el promedio del libro Scrum: El arte de hacer el doble de trabajo en la mitad del tiempo , donde Jeff Sutherland sugirió esto. Creo que tiene sentido total.

Respuestas cortas

¿Debo resumir el número total de puntos para 1 historia de usuario?

No. Sumar las conjeturas de los desarrolladores generará esfuerzos mucho mayores simplemente porque más desarrolladores están adivinando.

¿Debo dividir la historia de usuario en 3 historias diferentes? (backend, frontend, diseño)

Probablemente no. Más bien, asegúrese de que cada pieza de trabajo represente un incremento valioso del software con un valor comercial claramente expresado, si es posible.

¿Debería simplemente inclinarme al valor máximo de puntos de historia?

Si y no :). Cuando haya una gran brecha entre las conjeturas de los desarrolladores, anime a los desarrolladores a descubrir por qué sus conjeturas divergen. Con espacios más estrechos, tienda hacia el número más alto.

Resumir

En última instancia, comprométase con la coherencia, la inspección rigurosa y la adaptación en cualquier técnica que adopte. Esto asegura que surjan buenas prácticas y que las malas se queden en el camino.

Aquí están mis dos centavos:

Bart golpeó directamente "la razón esencial de los ' puntos de la historia'" en su primera publicación: que "una sola 'historia'", cuando se analice a los diversos grupos de trabajo reales que van a trabajar en ella, en realidad consistirá en un número separado (y diferente) de pasos, o "puntos", para cada grupo.

Entonces, contaría esto como "cuatro puntos":

• "El diseñador, Dios lo bendiga, realmente no va a hacer el trabajo".
• La gente de back-end cuenta 1 .
• La gente de front-end cuenta 3 .
• Total 4 .

Pero... sé muy consciente de que estás contando manzanas con naranjas. Un "punto" para un equipo de back-end podría ocupar todo el sprint, y cada "punto" para un equipo de front-end podría ser muy diferente de los otros "puntos". La noción de "puntos" es útil como herramienta de estimación, pero solo llega hasta cierto punto. Utilice el mejor juicio. Aquí no hay absolutos.