No hay necesariamente una relación directa entre la complejidad de un PBI definido en términos de puntos de historia y el tiempo de desarrollo. Es decir, un PBI o historia de usuario que tiene mayor complejidad en puntos de historia puede terminarse en menos tiempo que un Item que tenga menos puntos de historia. El peligro es llevar a los equipos a un modelo predictivo que este lejos de Scrum afectando la auto organización y el empirismo. Una forma más apropiada es usar métricas Kanban.
En Kanban for Scrum Teams de Scrum.org, https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-04/2018%20Kanban%20Guide%20for%20Scrum%20Teams_0.pdf, una métrica de flujo es el "Cycle Time" que es el tiempo promedio para entregar valor al cliente y recibir feedback. En esta guía no hay métrica "Lead Time", el "Cycle Time" depende del contexto de la definición del flujo, es decir las definiciones del inicio y del final definidos por los dueños de esa parte del proceso. Por ejemplo, un Equipo de Desarrollo puede medir el "Cycle Time" desde que ingresa al Sprint y el Product Owner puede medir el "Cycle Time" desde que inicia el Refinamiento de un PBI o desde que el PBI ingresa al Product Backlog pero todavía no se refina. Las necesidades de medición del flujo llevarán a los equipos auto organizados a buscar la forma de usar el "Cycle Time". En ciertos contextos el "Cycle Time" será igual al "Lead Time" cuando el contexto del flujo sea el mismo. Cuando se trabaja un modelo empírico es mejor métricas basadas en probabilidades como las entregadas por Kanban y evitar las métricas predictivas como La velocidad basada en puntos de historia. Si la velocidad promedio se usa para proyectar la capacidad promedio del equipo entonces el éxito o fracaso en un Sprint puede darse también en el mismo promedio. Para usar estas métricas se considera que los ítems tienen características similares que no impactan en la ley de “Littles”, http://itsadeliverything.com/littles-law-the-basis-of-lean-and-kanban. Los ítems del tablero Kanban pueden servir para representar el Sprint Backlog y lo que fluye dentro del tablero Kanban son unidades de trabajo que entregan valor de negocio, muy probablemente PBIs, generando una mejor visibilidad e hiper transparencia al Equipo de Scrum incluyendo al Product Owner.
En Kanban for Scrum Teams no se define el concepto de “Class of Service” debido a que este concepto puede romper la ley de “Littles” y distorsionar las métricas de Kanban para proyectar la capacidad del equipo. Aunque las métricas de Kanban for Scrum Teams pueden ayudar a mejorar el enfoque “Lean” de los equipos Scrum estos deben usar la auto organización y su enfoque en el objetivo del Sprint para decidir el trabajo a incluir dentro del Sprint.
Gracias a Daniel Vacanti por el gráfico de Tiempo Promedio de Entrega o "Cycle Time" vs puntos de historia.