Estimación de historias de usuario con story points
Por Eder Montaño
Nota del editor: Este artículo forma parte del volumen 01. Descarga la revista para descubrir más contenido sobre testing y soft skills en español.
¿Alguna vez has usado un “Story Point”? ¿Qué es? ¿Y para qué sirve? Son algunas de las preguntas que contestaremos el día de hoy. Pero antes que nada, quisiera recordar uno de los eventos más importantes bajo el marco de trabajo de SCRUM: el evento de planeación.
El evento de planeación es donde el Scrum Team, junto al Product Owner y el Scrum Master, definen qué elementos se trabajarán durante el próximo sprint. Uno de los aspectos que se debe tener en cuenta durante este evento es evitar incluir más historias de usuario de las que se puedan terminar en el sprint. Es por esta razón que necesitamos puntuar las historias de usuario antes del evento de planeación, para que durante este ya tengamos una idea más cercana a la realidad de cuánto se está comprometiendo el Scrum Team para que pueda cumplir con las expectativas que se impone a sí mismo.
Entonces, ¿quiénes puntúan las historias de usuario? El mismo Scrum Team. Es importante señalar que, de acuerdo a la última versión de la SCRUM GUIDE 2020, se usa el término "Scrum Team" para referirse a todo aquel individuo que participe en la construcción del producto, en este caso de software, incluyendo a diseñadores, programadores, testers, etc. Es el Scrum Team el que, de manera conjunta, debería puntuar la historia de usuario, teniendo en cuenta su experiencia en actividades o features como los que solicita la historia, pensando en las posibles dependencias y los riesgos que puedan presentarse durante la etapa de desarrollo. En otras palabras, de manera subjetiva, el equipo intentará darle un valor objetivo para que este sirva de referencia en un futuro y lograr comprometernos solo a lo que podemos terminar durante el sprint.
Es importante señalar que esto no es una receta de cocina. Al final, el marco de trabajo de SCRUM reconoce que hay una curva de aprendizaje en los equipos, y el esfuerzo del equipo debería ir orientado hacia la mejora continua. De tal manera que, en los primeros sprints, es probable que nos sobrecarguemos de trabajo o nos subestimemos, pero es cuestión de práctica y experiencia lo que, poco a poco, le dará al equipo la habilidad para realizar la planeación de forma más eficaz.
¿Pero cómo puntuar las historias de usuario? Existen dos métodos: el Story Pointing, y el de t-shirt sizing (medición de camiseta).
Comencemos con el Story Pointing. Usaremos puntos de historia, o también llamados “story points”, para medir su complejidad. Sin embargo, estos no siguen la secuencia numérica general (1, 2, 3, 4, 5, 6…), sino la secuencia Fibonacci, es decir, 1, 2, 3, 5, 8, 13… Así, el uno indicará aquella historia que resulte muy simple para el Scrum Team, y el 13 representaría una historia muy compleja, que quizá haya que dividir en dos historias o más para que sea más eficiente el trabajo en ella y podamos completarla en un sprint.
También podemos usar el t-shirt sizing o medición de camiseta. Haciendo uso de las tallas en las que encontramos las playeras o camisetas, medimos qué tan compleja es una historia, siendo Pequeña (Small) la más sencilla y la Extra Extra Grande (XXL) la de mayor dificultad.
Tanto el método por puntos de historia como el de medición de camiseta pueden ser abrumadores, pues no se está midiendo algo tangible u objetivo, sino que estamos midiendo complejidad, algo subjetivo, que dependerá directamente de las habilidades del Scrum Team. Por esta razón, en ocasiones, hay equipos que establecen marcos de referencia para puntuar las historias. Por ejemplo, suponiendo que hay una historia que trata de cambiar el look and feel a un banner en términos de color y tipo de fuente utilizada, quizá represente un solo punto de historia, pues no tenemos ninguna dependencia con algún otro equipo para implementar el cambio. Además, este puede ser efectuado de manera sencilla, pues se conocen bien cuáles son los elementos o herramientas para lograrlo, y además ya se ha hecho. En cambio, podríamos tener otra historia en la que necesitamos cambiar una API, pero no tenemos permisos sobre esta o desconocemos cómo hacer la implementación para cambiarla. Entonces, quizás necesitemos dividir más esta historia o, dependiendo de la experiencia del equipo, puede ser que sea factible incluirla en el sprint, aunque puntuándola con mayor complejidad.
En ocasiones, es complicado que el Scrum Team logre ponerse de acuerdo en cuánto debería medirse una historia, entonces se usa una técnica llamada “Planning Poker”, donde se pide a todos, de manera individual, votar por lo que consideran que debería ser el tamaño de la historia. De manera presencial se usan tarjetas, en donde todos abren su votación al mismo tiempo y se selecciona la más votada. En formato remoto, hay aplicaciones móviles y de escritorio que pueden ser usadas de igual manera; incluso software de mensajería como Slack tiene implementada una pequeña herramienta para hacerlo. ¿Qué pasa si no hay una mayoría en la votación? Se dan argumentos entre las puntuaciones más votadas y se repite la votación.
Como recomendación, sugiero que si no trabajan así en tu equipo de trabajo, no pierdas la calma. Recuerda que uno de los principios de SCRUM es "las personas sobre los procesos", entonces tienes la oportunidad de observar cómo funciona, y respaldándote con la teoría del marco SCRUM, puedes sugerir nuevas formas de trabajo, buscando siempre el objetivo común de todos, el cual es: entregar de forma eficiente mejores productos de software.
Soy Eder Montaño y trabajo como Business Analyst Jr.
Después de más de 10 años de experiencia como ingeniero de pruebas en la industria tecnológica, decidí orientarme hacia roles más tácticos y de management.
Actualmente, trabajo en una empresa farmacéutica, donde participo en la entrega de sitios web y campañas para algunas de las marcas más importantes.