Puntos de historia para días ideales

TL; DR

Los puntos de la historia miden el esfuerzo; las horas miden el tiempo. No son intercambiables. Será mejor que calcule las horas-hombre, las horas ideales o los días calendario desde el principio.

Es posible que Scrum tampoco sea adecuado para usted. Kanban o Lean podrían ser un mejor enfoque dadas las limitaciones de su gobierno de TI.

Los puntos de la historia no se ajustan a su organización

Su proceso organizativo no se ajusta bien a los puntos de la historia. No está permitido usar medidas relativas para la planificación, por lo que los puntos de la historia no serán una herramienta útil. Si bien las historias de usuarios pueden seguir siendo una herramienta útil para capturar los requisitos a un alto nivel, la necesidad de estimar en horas y libras puede significar que en realidad necesitará una estructura de desglose del trabajo (WBS) más detallada que la que las historias de usuarios pretenden proporcionar por sí mismas. .

Un enfoque de estimación alternativo

Todo esto es para decir que debería considerar seriamente algo más como lo siguiente:

1. Defina un cambio como una historia de usuario para capturar el requisito de alto nivel.
2. Divida la historia en tareas, con una estimación basada en el tiempo asociada para cada tarea. Ya sea que use horas ideales, días calendario o alguna otra métrica de tiempo, depende totalmente de usted; algo de experimentación puede estar en orden.
3. Envíe la WBS y la estimación basada en el tiempo a través de su proceso de control de cambios.

Incluso en Scrum, las historias finalmente se dividen en tareas que (generalmente) son de 4 a 16 horas cada una. Si bien esta granularidad puede variar, es parte del mecanismo de control para determinar el deslizamiento dentro de un sprint. Dado que las historias están "terminadas" o "no terminadas", cada tarea necesita un cuadro de tiempo, y 1/2 día a 2 días es generalmente un tamaño manejable para tales cuadros. Su millaje puede variar, pero es un buen punto de partida.

Es posible que Scrum no se ajuste a su organización

Su "Lista de pedidos del producto" es en realidad un registro de solicitud de cambio impulsado internamente, con aprobación externa de las estimaciones. Si bien Scrum ciertamente proporciona información del equipo a través del Dueño del Producto a la Lista de Producto, el proceso que usted describe está completamente al revés desde la perspectiva de Scrum.

Ya sea que esté utilizando puntos de la historia o no, en realidad parece que su organización en particular se beneficiaría más de un marco de gestión de proyectos diferente. Si bien aún puede usar cuadros de tiempo para administrar su WBS, no creo que Scrum como marco de proceso se ajuste a la forma en que su organización planifica o controla las desviaciones del cronograma. Por necesidad, se encontrará asignando procesos internos a la Gobernanza de TI externa con tal regularidad que no necesariamente le comprará nada usar un marco diferente internamente.

Como alternativa, Kanban podría ofrecerle un proceso interno para administrar el trabajo con una cadencia confiable que no se basa en el bloqueo de tiempo. En mi opinión, Kanban ofrece un marco que se adapta mejor cuando el trabajo es continuo o depende de la demanda, y tiene un enfoque más estricto en la cadencia del equipo que en el tiempo limitado. Todavía tendrá que reasignar su proceso cuando interactúe con su marco de gobierno de TI, pero puede ser un proceso interno más sostenible para usted que Scrum.

No estoy sugiriendo necesariamente que abandones Scrum, adoptes Kanban o cambies a cascada. Realmente solo estoy sugiriendo que analice detenidamente su proceso de gestión de proyectos y decida si realmente está funcionando para usted. Si no, ¡busque una alternativa que le quede mejor!

Siempre existe la tentación de asignar puntos de la historia a horas (o, en última instancia, a días). Le recomendaría que evite que el mapeo como puntos de la historia sea una escala relativa de esfuerzo que no tiene nada que ver con las horas en su proceso de estimación. Por ejemplo, si tiene una historia de línea de base y luego todos los puntos de la historia se miden con respecto a esa línea de base, un punto de historia de "2" significa que esta historia es 2 veces más difícil que su línea de base.

Dicho todo esto, el mejor enfoque es hacer un sprint real y luego calcular la velocidad del equipo. A continuación, puede utilizar datos y medidas reales (puntos restantes de la historia, puntos medios de la historia añadidos después de cada sprint, velocidad real del equipo) para calcular los "sprints estimados hasta la finalización". Si haces sprints de 2 semanas y luego tus sprints estimados hasta la finalización son 10, entonces deberías tardar 20 semanas en completar el proyecto. Después de unos 3 o 4 sprints, este número se vuelve cada vez más preciso. Me gusta este método ya que le brinda la forma más precisa de "mapear" los puntos de la historia en el tiempo. La desventaja es que la gerencia generalmente quiere una estimación de tiempo por adelantado y en su sistema Plan Driven tendrá que hacer algo más.

Asumiendo que ya tienes una velocidad de equipo, esto no es un problema. En el paso 4 anterior, convierta el trabajo en el número de sprints (o si la solicitud es pequeña, el porcentaje de un sprint). Por ejemplo:

Estimación del elemento de trabajo: 20 puntos de historia Velocidad del equipo: 100 Tiempo de sprint: 2 semanas Costo de sprint: $ 10,000 Costo de los 20 puntos de historia: $ 2,000

Este no es un sistema perfecto, pero debería funcionar. :)

Por último, eche un vistazo a Kanban, ya que el sistema Plan Driven que describe funcionaría bien con él.

Espero que esto ayude.

Evitaría a toda costa mapear puntos a horas.

Abordé esto anteriormente usando una sesión similar a su taller de requisitos iniciales para dividir el trabajo en épicas razonablemente grandes (generalmente pasos de flujo de trabajo desde la perspectiva del cliente).

Luego estimaremos esos fragmentos en semanas de esfuerzo dando una estimación a intervalos y tomando nota de las suposiciones que estamos haciendo. Cuando el rango proporcionado por el equipo sea grande, profundizaremos más en los riesgos para tratar de descubrir dónde radica la incertidumbre.

El rango total, así como los supuestos y riesgos, se pueden presentar al comité. Si hay demasiada incertidumbre (el rango es demasiado grande) para que se comprometan con el proyecto, puede pedir tiempo para investigar algunos de los riesgos y suposiciones para ver si puede obtener más certeza.

Esto le permite obtener una estimación de costos por adelantado y deja muy claro a todos los involucrados qué cosas (previsibles) afectarán ese costo sin llegar al nivel de crear todas sus historias por adelantado o tener que convertir de puntos a horas.

Aquí está el resultado de sesiones similares que mi equipo hizo hace un tiempo:

Finalmente, es posible que desee ver qué tan dispuesto estaría el comité a cambiar ligeramente el proceso. Ahora les pedimos a las personas que aprueban el presupuesto de trabajo que nos digan, en función de los beneficios esperados del trabajo, cuál sería el máximo que estarían dispuestos a invertir.

Luego, el equipo técnico puede analizar el trabajo y decidir si seríamos capaces de cumplir con los requisitos básicos con esa inversión. Este tipo de aprobación de beneficios me parece más saludable, ya que evita arreglar el alcance por adelantado y ayuda a enfocar a todos en el objetivo final en lugar de los detalles.

Sin respuesta, solo un consejo. Lleve un registro de estas historias y el tiempo dedicado a analizarlas, refinarlas, estimarlas y debatirlas. Cuente los comités también. Luego, publique cuántas horas se pierden en historias que, al final, no se iban a construir. Hay ahorros fáciles para su organización.