El problema no es el tamaño. El cliente es el tamaño.

Un error notificado por un cliente conlleva un alcance que el equipo no puede apreciar solo a partir del ticket. La solución técnica podría consistir en una sola línea de código. Sin embargo, el trabajo que la rodea suele constituir la mayor parte de la tarea: reproducir el error con los datos del cliente, redactar un informe de análisis posterior, elaborar la respuesta, decidir si se debe abonar el importe en la cuenta y comunicarse con otros clientes afectados. Nada de esto figura en el ticket. Todo ello merma la velocidad de trabajo.

Calcule dos aspectos: la solución y la respuesta. La solución consiste en el «planning poker» habitual. La respuesta, en cambio, resulta poco familiar para los equipos de ingeniería y suele subestimarse sistemáticamente; de ahí que los errores de los clientes parezcan prolongarse a lo largo del sprint, incluso cuando la votación con las cartas ha dado un resultado bajo.

Lo que se dice en la sala

Backend: «La corrección consiste en una sola línea».

PM: «¿Qué cuenta lo ha publicado?»

Asistencia técnica: «Su gestor de servicios al cliente solicita un análisis de la causa raíz para el viernes».

Pregunta principal: «¿Hay otras cuentas afectadas? ¿Debemos enviarles un correo electrónico?»

Pregunta de control de calidad: «¿Podemos reproducir el problema con sus datos, o necesitamos una exportación depurada?»

Preguntas que conviene plantearse antes de votar

  • ¿Quién lo ha notificado y cuál es su ARR, SLA o estado contractual?
  • ¿Se debe realizar una evaluación de la respuesta al cliente (RCA) o un análisis a posteriori de forma externa?
  • ¿Se han visto afectadas otras cuentas y cómo podemos averiguarlo?
  • ¿Debemos conceder un abono, un reembolso o una prórroga del periodo de prueba?
  • ¿Quién redacta la respuesta dirigida al cliente? ¿Y figura esa respuesta en este ticket?
  • Reproducción: ¿datos del cliente, volcado depurado o datos sintéticos?

La separación resulta útil: la corrección es una solicitud, la respuesta es otra. Ambas pasan por el «planning poker»; solo una de ellas tiene carácter técnico.

Calcule la corrección y la respuesta por separado. El nombre de la cuenta es lo que hace que la respuesta sea tan grande.

Consulte los errores habituales en el «planning poker» relacionados con el modo de fallo que se produce al votar sobre tareas que no son responsabilidad del equipo. Eche un vistazo a los demás ejemplos de estimación ya realizados o inicie una sesión gratuita de «planning poker» con ambas historias preparadas.