¿Cómo estima un equipo (nuevo en el producto y el dominio) las historias de usuario de un producto de diez años?

TL; DR

La falta de conocimiento del producto o dominio es una brecha en el proceso, más que una falla atribuible al equipo. Puede aumentar la precisión de sus estimaciones con una mayor participación del propietario del producto, historias de capacitación y documentación, y picos de historias.

Todas las historias DEBEN ser estimadas

El equipo no tiene la opción de "despejar" las estimaciones. Al final de Sprint Planning, todas las historias aceptadas en el sprint deben tener una estimación.

La estimación debe ser lo más precisa posible dentro del intervalo de tiempo asignado para Sprint Planning. Esta es la razón por la que el propietario del producto debe estar presente durante la planificación del Sprint:

• Para responder preguntas sobre alcance u objetivos.
• Para refinar o aclarar las historias de los usuarios.
• Para eliminar o reemplazar una historia que es verdaderamente inestimable con el conocimiento actual del equipo.

Una estimación no es una garantía, es una "suposición fundamentada" basada en la información disponible para el equipo durante la estimación. Cuando falta información, esta estimación generalmente será incorrecta; eso es simplemente parte del proceso Scrum, y los problemas que causaron una estimación deficiente deben evaluarse (y proponerse las mitigaciones apropiadas) durante la Retrospectiva del Sprint.

Las estimaciones deben incluir la incertidumbre

[E]l equipo no puede averiguar varios lugares donde tienen que agregar/modificar el código. A veces se necesitaban varios sprints para completar una historia de usuario.

Una buena estimación explica el nivel de incertidumbre del equipo. Por ejemplo, supongamos que la historia de un usuario sobre la adición de un widget a un thingamabob implica cambios en un número desconocido de clases de complejidad incierta. ¿Cómo debería estimar eso?

Picos

El primer paso es reducir su incertidumbre tanto como sea posible. Tal vez necesite un par de puntas de historia, como:

1. Estrechar el alcance.

   Como desarrollador,
   me gustaría saber cuántas clases están involucradas en la representación de un widget
   para poder estimar el nivel de esfuerzo requerido para modificarlo.

2. Evalúa la complejidad.

   Como desarrollador,
   me gustaría medir la complejidad de las clases de representación de widgets
   para poder proporcionar una estimación más precisa del esfuerzo de trabajo para cambiarlas.

Si dedica algún tiempo a estos picos, su equipo estará en una mejor posición para ofrecer una opinión informada sobre el esfuerzo de trabajo requerido para completar la historia original. Además, los picos le darán al equipo más confianza de que entienden la parte del sistema que deben estimar.

Factores de dulce de azúcar

Ya sea que haga los picos primero o no, todas las historias incluyen cierta cantidad de incertidumbre. Sin embargo, cuanto mayor sea el cono de incertidumbre , menos precisas serán sus estimaciones. Los picos reducirán el cono, pero no lo eliminarán por completo.

Independientemente del tamaño del cono, siempre se debe considerar el intervalo de confianza al estimar. Esto dará como resultado ajustes en los puntos de la historia basados ​​en el nivel actual de conocimiento del equipo.

• Alta confianza, pequeño cono de incertidumbre

  Por ejemplo, durante la planificación de Sprint, el equipo puede estar seguro de que un cambio se limita a un área conocida del código y, por lo tanto, que la incertidumbre es pequeña. En tales casos, el nivel de esfuerzo puede ser sencillo de estimar.

• Confianza baja, gran cono de incertidumbre

  Por otro lado, cuando la incertidumbre es alta, eso debería reflejarse en la estimación del punto de la historia. Por ejemplo, el equipo podría decir:

  El cambio solo implica cambiar el nombre de "foo" a "bar", pero no estamos seguros de qué clases deberían estar involucradas en el cambio. El cambio en sí es probablemente solo 1 punto, pero averiguar qué clases modificar es probablemente otros 5 puntos. No podemos llamarlo seis ya que no existe tal tarjeta de puntos, así que hagamos de esta una historia de 8 puntos.

Recuerde, las estimaciones puntuales de la historia son una forma de comunicar las limitaciones de recursos al propietario del producto y a la organización. Ajustar el tamaño de una historia en función de la incertidumbre mejora la precisión de las métricas de velocidad y refleja con mayor precisión la velocidad a la que el proyecto puede abordar los elementos de la cartera de productos.

Al hacer que la falta de información disponible sobre el sistema sea un costo visible para el proyecto, le brinda al propietario del producto la oportunidad de priorizar la capacitación, la documentación o las refactorizaciones de código que podrían reducir la productividad del equipo.

Crear historias de entrenamiento

Si falta el conocimiento de los sistemas, este es un problema de proceso que no se puede resolver sin la cooperación del propietario del producto. Debido a que el propietario del producto es responsable de la asignación de recursos en el proyecto a través de la priorización de la cartera de productos, es su responsabilidad agregar historias de capacitación y transferencia de conocimientos a la cartera de productos cuando sea necesario.

Por ejemplo, si yo fuera el Scrum Master en ese equipo, usaría la preparación de la cartera de pedidos como una oportunidad para sugerir que el propietario del producto agregue algunas sesiones de capacitación con un límite de tiempo a la cartera de productos. Además, alentaría activamente la adición de historias de usuarios como esta a la cartera de productos:

Como desarrollador del equipo de mantenimiento,
me gustaría asociarme con uno de los desarrolladores originales para documentar el módulo Foo
para poder comprender mejor el sistema y crear estimaciones más precisas.

Tales historias contribuirían en gran medida a comunicar de manera efectiva los problemas subyacentes del proceso a las partes interesadas. Estas historias también abordarán directamente una brecha de conocimiento que seguirá plagando su proyecto hasta que se enfrente de frente.

Desafíos de trabajar con un equipo de desarrollo extranjero

Basado en mi experiencia trabajando con una configuración similar, aquí están mis sugerencias:

• Haga que una PYME de los EE. UU. viaje a la India y capacite a todo el equipo de manera práctica durante un par de semanas como mínimo.
• Haga que un par de miembros clave del equipo de la India viajen a los EE. UU. para unas semanas de capacitación práctica con las PYME.
• Además del Product Owner, consigue que una SME del equipo de EE. UU. participe en las reuniones de Sprint Planning. Haga que el PO escriba las historias antes de la reunión de planificación. Haga que el equipo de la India planifique cómo van a implementarlos, así como que calcule y resuelva las historias. Durante la reunión de planificación, haga que la PYME de EE. UU. valide si ese es el enfoque correcto.

Dependiendo de su presupuesto y motivación, debe probar algunos, si no todos los anteriores. Los siguientes, por supuesto, son otros imprescindibles:

• Para una mejor comunicación, estas reuniones de planificación deben estar en video, si aún no lo están.
• Sus historias deben tener una lista clara de criterios de aceptación comprobables, si ese aún no es el caso.

Vería las quejas de los últimos años (si se mantuvieron algunos archivos) y si algunos clientes pidieron reembolsos en el pasado + qué parte(s) del producto se rompió o con qué los clientes no estaban satisfechos. Llamaría al servicio de atención al cliente y al soporte técnico de su empresa + aquellos que pueden reparar su producto (incluso si otra empresa lo hace por usted).