La historia de usuario es ya parte del análisis y debería estar bien definida y concretada cuando se va a comenzar un sprint. Es cierto que en ocasiones, cuando el equipo de trabajo comienza a realizar la tarea puede encontrarse con dudas o puntos que no tienen claro. Debería bastar con una llamada al Cliente o una breve reunión para resolverlo.

Es un punto complejo éste. Es cierto que es habitual que el desarrollo pisa al análisis y llegue la hora de desarrollar funcionalidades que aún no están bien analizadas. Para esto es bueno mantener reuniones frecuentes con el cliente para ir avanzando y concretando tareas previstas para más adelante de forma que a la hora de planificar el sprint éstas funcionalidades estén listas para comenzar. Si aún así el desarrollo sigue encontrando tareas que aún no están bien descritas quizás deba dedicarse una parte mayor del equipo a analizar y concretar estas tareas en lugar de a desarrollar.

Bueno, en principio, se supone que la diferencia salarial corresponde a su nivel de experiencia y saber hacer en su trabajo por lo que los junior cobran menos. Conocen aún poco sobre la tecnología o el producto y que, a medida que van aprendiendo y adquiriendo experiencia esta diferencia se acorta o desaparece.

Si algún miembro del equipo entiende que no cobra a razón de lo que está aportando es cierto que puede perder el ánimo o las ganas de trabajar. Aquí entramos en un asunto de recursos humanos en lugar de Scrum pero yo le aconsejaría que comente con sus responsables el trabajo que ha realizado y lo que ha podido aportar y vea con ellos si tienen la misma percepción sobre esto y consideran que en algún momento puede hacerse una revisión de su salario.

Yo no pondría valor a los votos del equipo de trabajo. A veces la mejor idea puede venir del que lleva menos tiempo en el trabajo, aunque lo habitual sea que los senior sean los que más aporten en la discusión que llevará a la decisión técnica que finalmente se tome.

Algo que he utilizado a veces es escribir en una pizarra las ventajas e inconvenientes de cada solución. A veces, nada más terminar de escribir esos pros y contras todos nos damos cuenta de cuál es la solución que más conviene ahora. Otras veces esto no está tan claro y hay que apostar por una aunque no haya consenso.

Cuidado si la opción por la que se apuesta es siempre la de ‘hay que hacerlo así ahora porque no tenemos tiempo‘. Es verdad que a veces es la solución que se debe tomar ante una urgencia. Explícale bien al equipo de trabajo el por qué de esta decisión en estos momentos pero explícale también al Cliente que ahí ha quedado un asunto por resolver que deberá ser programado para un próximo sprint si no queremos que esa deuda técnica nos acumule más errores pronto. Si no hacemos esto, con los años, el proyecto se nos puede convertir en uno de esos proyectos en los que todo el equipo de trabajo está resolviendo bugs y no nos queda tiempo para desarrollar nuevas funcionalidades.Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría