El equipo estima los puntos de la historia, las empresas quieren tiempo real

15

Estoy seguro de que este no es un tema poco común. Tenemos dos equipos scrum que están haciendo un buen trabajo al estimar historias de usuarios utilizando puntos de historia (las constelaciones actuales del equipo tienen solo unos 8 meses, aunque los miembros del equipo tienen varios años de experiencia scrum). Pero es difícil para la parte comercial de la empresa relacionarse con historias de usuarios; quieren unidades de tiempo reales (o "una fórmula para convertir puntos de historia en horas") para que puedan hacer un plan de cuándo estarán listas las cosas ( "necesitamos saber cuándo podemos decirles a los clientes que la característica X estará en producción") " ).

Yo y mis predecesores de scrum master, por supuesto, hemos explicado que "no hay una relación definida entre los puntos de la historia y el tiempo real" y que "los puntos de la historia se usan para determinar cuánto puede caber el equipo en un sprint", y estoy Seguro que puedes adivinar cuán satisfechos estaban con esa respuesta. Todavía quieren saber, en el tiempo del calendario, cuándo llegaremos a esa 27a historia de usuario en la cartera de pedidos.

En cualquier caso, he estado compilando algunas estadísticas, y nuestras estimaciones de SP se traducen en resultados muy diferentes de tiempo real gastado (medido por nuestro software de tablero de scrum, que realiza un seguimiento de cuánto tiempo pasan los tickets en la columna "trabajando en" ) Para las historias de usuarios de 1-SP, por supuesto, existe un gran sesgo hacia períodos de tiempo muy cortos (con la explosión ocasional), pero especialmente para las historias de 2-SP, están por todas partes: hay un factor de 20 entre las terminaciones "más rápidas" y las "más lentas". Para las historias de 3, 5 y 8-SP, la propagación también es más que un factor de 2.

Esto indica que (a) el equipo debe ser mucho más consistente al estimar las historias de los usuarios de (lo que debería ser) una complejidad similar, y (b) el equipo necesita mejorar su precisión en los informes de tiempo (es decir, recordar sacar los boletos de "trabajando" cuando están en una reunión, en el almuerzo o jugando al futbolín).

Tengo planes de mejorar tanto (a) como (b), pero creo que eso no es suficiente, que el negocio espera "más concreción" de lo que producirán estas iniciativas.

¿Cuáles son algunas buenas estrategias para apaciguar el lado comercial , para que no interfieran demasiado en la forma en que trabajamos (por ejemplo, imponiendo el uso de un seguimiento de tiempo separado, que en mi humilde opinión sería tonto porque en cualquier caso sería menos preciso que el seguimiento "automático" actual), mientras que al mismo tiempo les permite obtener alguna medida de concreción para cuándo se harán las historias?

(Históricamente, durante la planificación, desglosamos las historias de los usuarios en elementos de trabajo que luego se estimaron individualmente en el tiempo de trabajo real , pero de lo que estoy hablando aquí son las historias de los usuarios en el registro posterior que no tendrán ese nivel de detalle o interrupción -abajo.)

Actualización: mi gerente tenía el presentimiento de que había una especie de distribución de curva de campana de horas gastadas por punto de historia, pero los datos que cotejé y los gráficos que hizo lo deshabilitaron completamente de esa noción. :-)

KlaymenDK
fuente
1
De hecho, también tengo curiosidad por esto, porque mi equipo ha estado a punto de saltar a SP. ¿Por qué es tan volátil 2-SP? ¿No le asignas 2-SP porque estimas que la tarea es rápida? Si es así, la volatilidad aún estaría allí, incluso si calculara con el tiempo. Excepto que puede ser visto pasar dos semanas en un boleto donde pensó que tomaría 3 días. Es la misma volatilidad en ambas mediciones, ¿verdad?
Alec
33
Si ya tiene las 27 historias siguientes priorizadas y estimadas, entonces puede decir en qué sprint debería ir la 27a historia, ¿no? Y eso dará a una fecha de entrega estimada. Por supuesto, se demostrará que estás equivocado, pero esa es tu estimación actual. ¿Qué me estoy perdiendo?
Deja de dañar a Mónica el
44
Es por eso que los llaman estimaciones y no predicciones precisas. Se aplican las técnicas estándar para ayudar a salvar su trasero cuando tiene que proporcionar estimaciones. Y si aplica una corrección basada en evidencia objetiva de que sus estimaciones tienen una alta incertidumbre y un sesgo sistemático, ni siquiera cuenta como trampa.
Deja de dañar a Mónica el
33
¿Quizás el 27º elemento necesita ser movido a la máxima prioridad?
Andy
1
@LewisPringle Digamos que quiero hacer una predicción sobre la ubicación de Chuck Norris. Podría decir "1600 Pennsylvania Avenue" y si él está en Whitehouse, sería una predicción bastante precisa y precisa. Sin embargo, si no lo es, entonces todavía es preciso, pero inexacto. Podría decir, "Estados Unidos continental". Mucho menos preciso pero más probable en cualquier momento dado de ser cierto. O podría decir "en la tierra", que es muy probable que sea preciso, pero es tan impreciso como para ser efectivamente inútil. El resultado es que necesitamos conocer la precisión de una estimación para evaluar su exactitud.
JimmyJames

Respuestas:

16

Tienes razón, no hay una fórmula para convertir puntos de historia en horas. Puede obtener una conversión sin pérdidas de metros a pies, y viceversa, pero no puede decir que una historia de 3 puntos tomará X horas, por lo que una historia de 5 puntos tomará Y horas (resuelva para Y).

HorusKol tocó en la siguiente parte. Su velocidad de sprint como equipo puede ayudar con los entregables a largo plazo. Digamos que su equipo tiene 50 puntos por sprint, y cada sprint es de 2 semanas. Entonces, 50 puntos por sprint multiplicados por 50 semanas en un año (suponiendo que las personas se tomen 2 semanas de vacaciones), entonces su equipo actual puede hacer un máximo de 2,500 puntos en 12 meses.

Entonces, el negocio se te acerca con 170 puntos de historias y epopeyas. Divide eso por la velocidad histórica del equipo de 50 puntos (un promedio de cada sprint hasta ahora) y obtienes 3.4 sprints. Como estamos haciendo una estimación, redondee eso a 4 sprints: 8 semanas. Dos meses, básicamente. También me gusta tomar los últimos 3-4 sprints y hacer otra estimación. Digamos que su equipo en los últimos 3 sprints ha logrado 53, 67 y 55 puntos respectivamente. Eso resulta en 58 puntos, que a ese ritmo son 2.9 sprints, así que básicamente 3 sprints. Parece que su línea de tiempo para esos 170 puntos se ve como 6 a 8 semanas.

Dile al negocio 2 meses. No les diga 6-8 semanas, porque solo escucharán "6 semanas". Ni siquiera les diga 8 semanas, porque la mayoría de los meses tienen alrededor de 4.5 semanas, y cuando las personas escuchan "4 semanas", piensan instantáneamente "1 mes". Una vez que una estimación alcanza las 4 semanas, se convierte en 1 mes. Entonces solo trabaja en meses. Si llega a un año o más, honestamente, simplemente no calcule ese trabajo. Carece de sentido. Demasiado puede cambiar en un año.

He descubierto que esta es una forma bastante precisa de convertir puntos de historia en horas ... bueno, de todos modos.

Obtendrá una variación en la cantidad de tiempo que lleva completar historias individuales. Algunos desarrolladores trabajan más rápido que otros. Poner todos los puntos de la historia en un tazón y encender la licuadora para trabajar con promedios ayuda a aliviar esas inconsistencias.

Ah, y no olvides la parte más importante:

Redondeo. Siempre.

Greg Burghardt
fuente
Sería genial si pudiera usar algún conocimiento de estadísticas para definir sus intervalos de confianza del 90%, 95% y 99%. Esto debería funcionar mejor que la velocidad promedio, especialmente cuando los datos históricos no son muchos y la varianza es grande.
Hosam Aly
8

Probablemente ya tenga una conversión inherente de los puntos de la historia a las estimaciones de tiempo: ¿cómo decide que ha elegido suficiente trabajo para su sprint? Probablemente hayas dicho algo como "el equipo puede manejar 20 (o 40 o lo que sea) puntos por semana". Después de algunos sprints, deberías poder revisar eso en función de la finalización, por lo que ahora son 15 o 25 (o 35 o 50 o ...) puntos por sprint: esta es la velocidad de tu equipo .

Para las historias de usuarios de 1-SP, por supuesto, existe un gran sesgo hacia períodos de tiempo muy cortos (con la explosión ocasional), pero especialmente para las historias de 2-SP, están por todas partes: hay un factor de 20 entre las terminaciones "más rápidas" y las "más lentas". Para las historias de 3, 5 y 8-SP, la propagación también es más que un factor de 2.

Una variación en el tiempo para completar historias específicas está bien dentro de los valores de los puntos: la velocidad se ocupa de esa incertidumbre al ser un promedio sobre la historia reciente.

Sin embargo, es posible que deba analizar detenidamente cómo está asignando puntos, especialmente esos indicadores de 2 puntos si obtiene una fluctuación tan grande. Se supone que las tareas de puntos más altos son inciertas (y deben desglosarse), pero las tareas tan pequeñas como un puntero de 2 puntos deben ser bastante consistentes.

Dado que todas las tareas asignadas al mismo valor de punto deberían necesitar un esfuerzo similar, no tiene sentido que haya un rango de veces para completar.

Entonces, mire el puntero de 2 puntas que tomó más tiempo en su retrospectiva. ¿Por qué algo que probablemente debería haber tomado una mañana se convirtió en un trabajo de 10 días? ¿Podría haber sido marcado algo esa primera mañana para decir "esto tiene que volverse épico y dividirse en tareas más pequeñas"? Tan pronto como eso suceda, por supuesto, el trabajo adicional necesario debe colocarse en la cartera de pedidos y no interferir con el resto del sprint.

Además, intente ver cómo el equipo subestimó ese elemento: ¿podría mejorar en futuros artículos que lo hayan revisado?

Sí, la fecha de entrega se enviará en consecuencia, o la lista de características para una actualización podría revisarse para que la entrega no se vea afectada. Pero el objetivo es mejorar las estimaciones puntuales futuras y también obtener una línea de tiempo más precisa.

HorusKol
fuente
Sí, algo está mal con esas tareas de 2 SP. Iba a decir que los desarrolladores ponen esas estimaciones cuando ven una tarea difícil y predecible. Pero, ¿por qué adivinar si puede analizar esas tareas y descubrir la razón
Max630
3

Es como el pronóstico del tiempo: cuanto más lejos, menos confiable. Esa es una analogía que todos entenderían. Se acumulan errores en las estimaciones.

Las ventas deben aprender a hablar en términos Scrum a los clientes. Scrum no tiene sentido de forma aislada, se supone que se aplica verticalmente en toda la empresa y preferiblemente se extiende al ámbito del cliente.

Usted como equipo de desarrollo debe ser firme en esto. Puede darles expectativas y conjeturas, pero no permita que sean compromisos que extiendan un solo sprint.

Martin Maat
fuente
55
"Las ventas deben aprender a hablar en términos de Scrum a los clientes. Scrum no tiene sentido de forma aislada, se supone que debe aplicarse verticalmente en toda la empresa y preferiblemente se extiende al ámbito del cliente". Eso suena bien, y sin duda facilitaría mucho el desarrollo, pero los clientes a veces tienen restricciones genuinas que los anclan al calendario. Es posible que necesiten un despliegue a tiempo para una conferencia importante, o puede haber un requisito legislativo para tener sistemas obligatorios establecidos en una fecha particular.
Charles E. Grant
2
@ Charles: ¿Entonces? Lo mejor que puede hacer en una configuración de Scrum es poner ese (conjunto de) características en un sprint antes de su fecha límite. No tiene sentido decir "Sí, hacemos scrum, pero solo mientras a nadie le importe".
Martin Maat
¿El objetivo es cumplir con los requisitos del cliente o adherirse fielmente a una metodología de desarrollo? En cada empresa en la que he trabajado, Scrum es un medio para un fin, no un fin en sí mismo.
Charles E. Grant
1
@ Charles ¿Estás sugiriendo que las posibilidades de entregar a tiempo mejorarán al no etiquetar lo que estás haciendo Scrum? De cualquier manera, un grupo de personas se compromete a una tarea. La única diferencia es que lleva más tiempo reconocer y comunicar que no cumplirá con la fecha límite de su cliente, si ese fuera el resultado.
Martin Maat
1
@Charles: los plazos estrictos del calendario son un componente de lo que el propietario del producto debe tener en cuenta en la prioridad de la cartera de pedidos. Si hay una fecha límite, depende de la orden de compra colocar esa característica en la cartera de pedidos en una posición en la que exista la certeza de que se puede alcanzar o retrasar ese requisito.
Dan Ray
3

Hago algunas cosas cuando recibo preguntas como esta.

En primer lugar, respondo preguntas sobre el futuro describiendo el pasado. Diría algo así como Pasamos sobre dos de estas historias por semana. Entonces, si nada cambia, esperamos terminar con la historia 27 en aproximadamente 14 semanas.

En segundo lugar, quiero que el cliente que se enfrenta a las personas asuma la responsabilidad del horario de negociación frente al riesgo. Diría algo como Recordar, el equipo de ingeniería trabaja en base a estimaciones de 50/50. Si nada cambia, hay una probabilidad de 50/50 de que la función 27 esté lista en 14 semanas. Presumiblemente, no desea informar algo con ese nivel de riesgo a un cliente. ¿Quieres que elabore una estimación en la que tenemos, digamos, 90% de confianza? Luego, deberías revisar tu evidencia histórica y decir algo como: Hay un 90% de posibilidades de que la historia 27 se termine en 25 semanas .

Por último, recuérdele a su colega que una vez que hace un compromiso externo, la empresa queda inmovilizada. Hacer promesas externas sobre la historia número 27 quita toda la agilidad de la compañía. Entonces estaría comprometido con un curso de acción particular. Cada vez que alguien llega a usted con una solicitud de cambio, ahora debe responder. Nos hemos comprometido a terminar la historia 27 antes de la fecha. Solo puedo hacer este cambio si contacta al cliente y le dice que nuestro compromiso ya no es válido. Básicamente, asumir compromisos específicos para trabajar más de un mes más o menos en el futuro conlleva muchos problemas.

John_C
fuente
"Hacer promesas externas [...] quita toda la agilidad de la compañía" - Sí, los vendedores nos han golpeado varias veces vendiendo algo que sabían que no podíamos hacer, y tuvimos que luchar para lograrlo. No es exactamente ideal.
KlaymenDK
En esa situación, la clave es dejar en claro causa y efecto. Dígale a la gente: no podemos trabajar en la tarea X o corregir el error Y porque estamos comprometidos a cumplir un plazo de ventas . Si la venta es lo suficientemente valiosa, entonces la decisión correcta fue alentar al equipo. Si la venta es menos valiosa que otro trabajo, aclare por qué no se está haciendo el trabajo más valioso.
John_C
3

Ya tienes una conversión (muy cruda): los
sprints de Scrum son (generalmente) dos semanas.
Sabes que puedes terminar, digamos, alrededor de 20 puntos de historia en características en esas dos semanas (¿o de qué otra manera determinas qué y cuántas características se agrupan en un solo sprint?) Y tus sprints anteriores confirman esa estimación (digamos terminaste 18, 21, 23, 19 y 20 puntos de historia en características en los últimos cinco sprints).

Digamos que la característica X (y todas sus dependencias) se han estimado en 47 puntos de historia.
Por lo tanto, puede estimar que si pone la implementación en la máxima prioridad, debería tomar alrededor de 3 sprints, es decir, 6 semanas (pero asegúrese de que sus estimaciones tengan en cuenta quién puede hacer qué, si 35 de esos puntos son DB trabajo y solo tiene en DB guy necesita revisar su velocidad estimada para tener eso en cuenta).

Dicho esto, comunique firmemente que esas son estimaciones crudas, hay una razón por la cual los sprints son dos semanas y no seis. Cuantas más cosas deba cubrir su pronóstico, más incertidumbre y error se introducirán. También comunique firmemente el costo, es decir, esto significaría poner la tarea en la máxima prioridad, lo que significa que no se trabajará en otras tareas. De lo contrario, podría encontrarse con el escenario de:

"¿Cuándo se hará la función Y ?"
"Si nos enfocamos en eso el próximo ... 12 semanas"
"¿ 12 semanas?!? Dijiste que tomaría 4".
"Sí, pero nos dijo que priorizáramos la función X , que le dijimos que vincularía todos nuestros recursos y tardaría 8 semanas".
"¿No puedes trabajar en la función X y la función Y al mismo tiempo?"
" gemido "

CharonX
fuente
En lugar de "gemido": "Claro que podemos. X tomará 16 semanas e Y tomará 8 semanas".
gnasher729
1

Sprint es tiempo definido, digamos 2 semanas. No puedes predecir que alguna historia se realizará más allá de 2 sprints, como si tuvieras tu sprint actual y el próximo. Supongo que ha preparado historias que se discuten con el equipo para el próximo sprint y fueron priorizadas por las empresas. Lo mejor que puede decir con seguridad son las próximas 4 semanas de trabajo.

Todo lo que dure más de 4 semanas está sujeto a cambios y las empresas pueden hacer una hoja de ruta que no esté establecida en horas. Eso debería planearse por sprint, digamos algo épico1 (épico como en un montón de historias agrupadas) y épico2 debería hacerse en el sprint 47 y 48 y épico3 debería hacerse en el sprint 49. Épicas calculo aproximadamente en horas por mi cuenta para ver si uno o dos caben en un sprint, la línea de tiempo se va a deslizar de todos modos. Si las funciones no funcionan, las empresas deben reducir el alcance o aceptar soluciones no perfectas que puedan mejorarse más tarde según sea necesario (que deberían ser ágiles, adoptar la realidad en lugar de seguir el plan).

Puede hacer un buen diagrama de Gantt (eso es lo que le gusta a los negocios) con futuros sprints y temas / epopeyas principales para ellos.

Me gusta hacer el lanzamiento cada sprint y luego preparo el lanzamiento con lo que se terminó en sprint (o cosas que se firmaron para el lanzamiento de la empresa, aunque no fueron perfectas), las cosas sin terminar van al siguiente sprint. De esta manera, tengo una entrega predecible en un plazo de 2-3 semanas (una semana para posibles soluciones en la liberación del candidato).

Esa es mi experiencia con un equipo pequeño, una pequeña cantidad de dependencias externas y lo que creo que es un negocio razonable. Tu kilometraje puede variar.

Mateusz
fuente
0

Para las nuevas funciones es casi imposible estimar el tiempo requerido.

La experiencia con el desarrollo de software muestra que en la mayoría de los casos hay detalles que no puede ver antes de comenzar realmente el desarrollo. En el mejor de los casos, esas detecciones pueden requerir algo de tiempo adicional, pero en el peor de los casos el proyecto también puede fallar. La razón de esto es la complejidad del desarrollo de software en sí.

Esta es la razón por la cual SCRUM solo estima la complejidad del problema (puntos de la historia), pero no el tiempo. La única posibilidad que tiene es dividir características de alta complejidad en otras más pequeñas. De esta manera puede minimizar el riesgo.

Como una estimación de tiempo es casi imposible, no existe una fórmula que convierta puntos de historia en estimaciones de tiempo. La velocidad solo puede ser una estimación muy cruda, no más.

En SCRUM, el propietario del producto puede cambiar las prioridades de los elementos pendientes antes de cada sprint. Por lo tanto, el maestro SCRUM no puede dar ninguna estimación para más de un sprint. No sabe qué elemento de la cartera de pedidos puede llegar a ser importante en el próximo sprint.

SCRUM no es un método para hacer cosas imposibles (planificar lo imprevisible) o acelerar el desarrollo. Es un sistema de alerta temprana si el desarrollo se está agotando. Permite reaccionar rápidamente ante nuevos requisitos.

A la publicación inicial:

Ya eres muy bueno si logras dividir la mayoría de tus tareas en historias de 1 SP a 5 SP. Las estimaciones de velocidad podrían mejorar si las tareas son similares y su equipo tiene más experiencia. Pero si siempre hay partes nuevas y no conocidas en elementos nuevos, tienes que vivir con la inexactitud.

Como sus desarrolladores normalmente pasan algún tiempo con trabajos que no son de desarrollo (por ejemplo, reuniones), no debe planificar con 8 horas de desarrollo por día, sino menos, por ejemplo, 6 horas. Luego obtienes una reserva para otras tareas o para elementos de trabajo que toman más tiempo.

Si sus colegas de negocios desean tener estimaciones precisas (lo cual es una contradicción en sí mismo), explíqueles los problemas inherentes al desarrollo de software. Luego muéstreles las ventajas de los métodos ágiles.

bernie
fuente