El equipo está estimando puntos de historia, el negocio quiere tiempo real

Tienes razón, no hay una fórmula para convertir los puntos de la historia en horas. Puede obtener una conversión sin pérdida 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 (resolver 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 está en 50 puntos por sprint, y cada sprint es de 2 semanas. Entonces, 50 puntos por sprint se multiplican por 50 semanas en un año (suponiendo que las personas se toman 2 semanas de vacaciones), entonces su equipo actual puede hacer un máximo de 2,500 puntos en 12 meses.

Así que el negocio se acerca a ti con 170 puntos de historias y epopeyas. Divida eso por la velocidad histórica del equipo de 50 puntos (un promedio de cada sprint hasta el momento) y obtendrá 3.4 sprints. Ya que estamos haciendo una estimación, redondea eso a 4 sprints: 8 semanas. Dos meses, básicamente. También me gusta tomar los últimos 3-4 sprints y tomar otra estimación. Digamos que su equipo en los últimos 3 sprints ha hecho 53, 67 y 55 puntos respectivamente. Eso equivale a 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 parece de 6 a 8 semanas.

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

Descubrí 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 se tarda en completar las 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:

Redondear hacia arriba. Siempre.

Probablemente ya tengas una conversión inherente de puntos de historia a estimaciones de tiempo. ¿Cómo decides que has elegido el trabajo suficiente para tu carrera? Probablemente haya dicho algo como "el equipo puede manejar 20 (o 40 o lo que sea) puntos por semana". Después de unos pocos 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 un sprint: esta es la velocidad de tu equipo.

  

Para las historias de usuario de 1-SP, hay, por supuesto, una gran tendencia hacia períodos de tiempo muy cortos (con el estallido ocasional), pero especialmente para las historias de 2-SP, están por todas partes: hay una 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.

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

Sin embargo, es posible que tenga que analizar detenidamente la forma en que asigna los puntos, especialmente los 2 puntos si está teniendo una fluctuación tan grande. Se supone que las tareas de puntos más altos son inciertas (y deberían desglosarse), pero las tareas tan pequeñas como un 2-puntero deben ser bastante consistentes.

Dado que todas las tareas asignadas al mismo valor de puntos deben requerir un esfuerzo similar, no tiene sentido que haya un intervalo de tiempo para completar.

Por lo tanto, mire el puntero de 2 puntos que le llevó más tiempo en su retrospectiva. ¿Por qué algo que probablemente debería haberse tomado una mañana se convirtió en un trabajo de 10 días? ¿Se podría haber señalado algo esa primera mañana para decir "esto tiene que convertirse en algo épico y dividido en tareas más pequeñas"? Tan pronto como eso suceda, por supuesto, el trabajo adicional que se necesita se debe colocar en el registro y no interferir con el resto del sprint.

También, intente ver cómo el equipo subestimó ese elemento. ¿Podría hacerlo mejor 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 de puntos futuros 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. Los errores en las estimaciones se suman.

Las ventas deben aprender a hablar en términos de Scrum a los clientes. Scrum no tiene sentido de forma aislada, se supone que se aplica verticalmente en toda la empresa y se extiende preferentemente 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 amplíen un solo sprint.

Hago algunas cosas cuando recibo preguntas como esta.

En primer lugar, respondo preguntas sobre el futuro describiendo el pasado. Yo diría algo como Terminamos con 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 de los horarios de negociación frente al riesgo. Yo diría algo como Recuerde, el equipo de ingeniería trabaja sobre la base de estimaciones de 50/50. Si nada cambia, hay una posibilidad de 50/50 de que la característica 27 esté lista en 14 semanas. Es de suponer que no desea informar algo con ese nivel de riesgo a un cliente. ¿Quieres que calcule una estimación en la que tengamos, digamos, un 90% de confianza? Luego deberías revisar tu evidencia histórica y decir algo como: hay una probabilidad del 90% de esa historia 27 se realizará en 25 semanas .

Por último, recuérdele a su colega que, una vez que se comprometa de manera externa, la empresa queda inmovilizada. Hacer promesas externas sobre la historia número 27 quita toda la agilidad de la compañía. Entonces estarías comprometido con un curso particular de acción. Cada vez que alguien acude a usted con una solicitud de cambio, ahora debe responder Nos hemos comprometido a finalizar la historia 27 antes de la fecha x. Solo puedo hacer este cambio si se pone en contacto con el cliente y le dice que nuestro compromiso ya no es válido. Básicamente, los compromisos específicos para trabajar más de un mes en el futuro conllevan muchos problemas.

Ya tienes una conversión (muy cruda):
Los sprints de Scrum son (usualmente) dos semanas.
Sabes que puedes terminar, digamos, alrededor de 20 puntos de historia de características en esas dos semanas (o ¿de qué otra manera determinas qué & cuántas entidades se empaquetan en un solo sprint?) Y tus sprints anteriores confirman esa estimación digamos que terminó con 18, 21, 23, 19 y 20 puntos de historia en las características de 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 implementa eso en la prioridad más alta 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 trabajo de DB y usted solo tiene en DB DB, 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 que los sprints son de dos semanas y no de seis. Cuantas más cosas deba cubrir su forcast, mayor será la incertidumbre y los errores de error. 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 puede trabajar en otras tareas. De lo contrario, podría encontrarse con el escenario de:

"¿Cuándo se realizará la función Y ?"
"Si nos centramos en ello las próximas ... 12 semanas"
" ¿12 semanas?!? Dijiste que tomaría 4."
"Sí, pero nos dijo que prioriemos la función X , que le dijimos que uniría todos nuestros recursos y tomaría 8 semanas". "¿No puedes trabajar en la función X y la función Y al mismo tiempo?"
" gemir "

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

Todo lo que transcurra más de 4 semanas está sujeto a cambios y las empresas pueden hacer una hoja de ruta que no se establece en horas. Eso debería planearse por sprint, digamos algo de épic1 (épica como en el grupo de historias agrupadas de jira) y epic2 debería hacerse en sprint 47 y 48 y epic3 debería hacerse en sprint 49. Las épicas estimo aproximadamente en horas por mi cuenta ver si uno o dos cabrán en un sprint, la línea de tiempo se deslizará de todos modos. Si las funciones no funcionan, los negocios tienen que reducir el alcance o aceptar soluciones no perfectas que puedan mejorarse más adelante según sea necesario (eso debería ser ágil, abrazar la realidad en lugar de seguir el plan).

Puedes hacer un bonito diagrama de Gantt (eso es lo que a la empresa le gusta) con futuros sprints y temas principales / épicas para ellos.

Me gusta lanzar cada sprint y luego preparo el lanzamiento con lo que se terminó en sprint (o las cosas que se firmaron para ser lanzadas por el negocio, aunque no eran perfectas), las cosas no terminadas van al próximo sprint. De esta manera, tengo una entrega predecible en un plazo de aproximadamente 2 a 3 semanas (una semana para posibles arreglos en el lanzamiento 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. Su 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 se pueden ver antes de comenzar con el desarrollo. En el mejor de los casos, esos riesgos pueden requerir un tiempo adicional, pero en el peor de los casos, el proyecto también puede fallar. La razón de ello es la complejidad del desarrollo de software en sí mismo.

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

Como la estimación de tiempo es casi imposible, no hay 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 de la cartera de pedidos antes de cada sprint. Por lo tanto, el maestro SCRUM no puede dar estimaciones para más de un sprint. Él no sabe qué elemento del backlog puede ser importante en el próximo sprint.

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

A la publicación inicial:

Ya eres muy bueno si administras la división de 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 adquiere más experiencia. Pero si siempre hay partes nuevas, desconocidas, en elementos nuevos, tienes que vivir con la inexactitud.

Como sus desarrolladores normalmente pasan algo de tiempo sin trabajo de desarrollo (por ejemplo, reuniones), no debe planificar con 8 horas de desarrollo por cada día, pero menos, por ejemplo. 6 horas. Luego obtiene una reserva para otras tareas o para que los elementos de trabajo tomen más tiempo.

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