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

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. :-)

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.

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.

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.

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.

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 "

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.

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.