Estimación de un error notificado por un cliente

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

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 del proceso: reproducir el error con los datos del cliente, redactar un informe posterior al incidente, 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 desarrollo.

Calcule dos aspectos: la solución y la respuesta. La solución consiste en el «planning poker» habitual. La respuesta, en cambio, resulta poco habitual 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 responsable de atención al cliente solicita un análisis de la causa raíz (RCA) 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?
• ¿Hay otras cuentas afectadas y cómo podemos averiguarlo?
• ¿Debemos conceder un abono, realizar un reembolso o ampliar el 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?

Divisió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 extensa.

Consulte los errores habituales en el Planning Poker sobre el riesgo de votar sobre tareas que no son responsabilidad del equipo. Eche un vistazo a los demás ejemplos prácticos de estimación, o organice una sesión gratuita de Planning Poker con ambas historias preparadas.