La importancia de llamar a las cosas por su nombre

Una recomendación que os quiero hacer, y que nos ayudaría, nos evitaría confusiones, nos potenciaría mejorar y, sobre todo, nos ayudaría a saber dónde estamos y qué nos queda, sería llamar a las cosas por su nombre… más que llamarlas por el nombre que desearíamos que tuvieran.

Por ejemplo, vamos con un caso muy típico, contexto ágil, modelo de referencia Scrum, etc., no hace falta más datos, tenemos un Product Backlog y, por defecto, a todo lo que hay allí le llamamos «Historias», como simplificación de «Historias de Usuario», pero, a ver, ahora, si miro bien y despacio ese Product Backlog… eso que hay ahí no son todo «Historias», ojalá, ¡ahí hay de todo!

Una cosa es una Tarea, otra cosa es una»Historias de Usuario», otra cosa diferente es un Spike, etc., no todo lo que hay en un Product Backlog o en la columna número 1 de un tablero, por defecto, por el simple hecho de estar ahí… ya es una «Historias de Usuario».

Ojalá todo lo que hubiera en un Product Backlog, o la mayoría, fueran «Historias de Usuario»: funcionalidad mínima, «end to end», etc. (no me extiendo, te dejo post ¿Por qué las Historias de Usuario deben ser lo más pequeñas posible? o incluso el curso online de Product Owner)

Si un Item del Product Backlog no es una Historia de Usuario… no ayuda que lo llames Historia de Usuario. Confunde, crea falsa seguridad, nos hace pensar que lo hacemos bien y que ahí no hay nada que mejorar, etc. Mala idea.

Y así podríamos seguir con más ejemplos. Más allá de la»Historias de Usuario», podríamos seguir con muchos más casos, algunos más fáciles de ver, otros no tanto. Por ejemplo, el famoso «producto potencialmente entregable», ese con el que se espera que se termine un Sprint, que como bien indica su nombre es… «potencialmente entregable», si no se entrega o libera es porque el Product Owner piensa que no es el mejor momento, etc.

Pero llamar «producto potencialmente entregable», por defecto, a todo aquello en lo que termina un Sprint… no siempre es correcto ni ayuda. Productos parcialmente terminados, el clásico de productos no del todo Testeados, productos a los que les queda aún un trecho para poder asegurar que pueden, técnicamente hablando, salir a producción, tareas que nunca verá el usuario, etc., no son «productos potencialmente entregables», entonces… no los llamemos así por defecto, porque, de nuevo, nos da una falsa complacencia, la idea de que ya tenemos todo hecho, etc.

Y así, podríamos seguir con muchos ejemplos.

Sí, quizá pienses que «es que aún estamos lejos de llegar poder tener verdaderas Historias de Usuario», o «sí, pero es que aún estamos muy lejos de poder llegar a tener productos potencialmente entregables», y eso se entiende, pero llamar a las cosas por un nombre que no les corresponde… no te va a ayudar, más bien te hará olvidar que debes seguir trabajando para tener verdaderas «Historias de Usuario», «productos potencialmente entregables», o lo que sea.

Así que, consejo… llama a las cosas por su nombre, que además es lo lógico, sensato y razonable.

4 comentarios en “La importancia de llamar a las cosas por su nombre”

  1. En cualquier framework, buenas prácticas, metodología o lo que sea, una de las grandes ventajas es el establecer un vocabulario común. ¿Cual es la diferencia entre una incidencia, un bug, una tarea,…? Simplemente semántica. Pero compartirla mejora mucho nuestra comunicación.
    Así que, tal y como dices, llamemos a las cosas por su nombre.

  2. Ya, pero es que en este país de … Hay que ser positivo y optimista…
    Lo que tú pides es que que alguien reconozca que su patata no es entregable…
    Mal lo veo que inundemos de negatividad o realismo negativo el honorable trabajo de los equipos de perfectos profesionales.
    Muy muy mal

  3. Ver la realidad «tal y como es» es el primer paso para comprender los fenómenos y, en su caso, mejorarlos. Parece obvio, trivial… Pero la práctica demuestra que no lo es. Al contrario, «llamar las cosas por su propio nombre» ya denota madurez; es muy buen punto de partida. Implica valores de honradez y coraje: especialmente cuando la realidad dista de lo deseado (o ideal, o socialmente aceptable, etc.).

    Veo continuamente como ante la dificultad de elevarnos a un altura deseada (ej.: Scrum), preferimos bajar nuestro supuesto objetivo: renombrando lo que hacemos (ej.: lo «de toda la vida» con tres arreglos nuevos) con el nombre (molón) de lo que querríamos hacer.

    ¡Muy buena reflexión!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba