Es de sobras conocido que la estimación es una de las áreas más problemáticas en todo proyecto de software. Pero en esta entrada no quiero centrarme en los problemas más habituales cuando estimamos (cómo conseguir estimaciones lo más cerca de la realidad posible), sino en un punto directamente relacionado con SCRUM. Un punto en el que he visto, muchas veces, que hay confusión.
Por si fuera poco con los problemas intrínsecos de la estimación, cuando estamos empezando a trabajar con SCRUM surgen dudas, que yo llamo "logísticas", sobre cómo vamos a estimar. ¿En horas? ¿En puntos de historia? ¿Qué relación hay entre las unidades de estimación y estimar en tareas o historias de usuario?
Voy a explicar mi punto de vista, basado en mi experiencia. Pero quiero dejar claro que no hay un método estándar. Es cierto que algunas herramientas (estoy pensando en TFS) pueden predeterminar cómo entrar las estimaciones (por ejemplo en horas), pero no hay una fórmula mágica. Y esto es bueno, porque es flexible.
SCRUM te da la posibilidad de adaptar cómo estimamos a nuestra necesidad. En general, las historias de usuario se estiman en puntos de esfuerzo mientras que las tareas en horas.
Las historias de usuario forman el Product Backlog. Del Product Backlog, las escogeremos para nuestro Sprint (el Product Backlog está ordenado por prioridades del negocio) y compondremos con él el Sprint Backlog.
En la reunión de Sprint Kickoff, analizaremos las historias de usuario y refinaremos su estimación. Aquí es donde yo suelo descomponer las historias de usuario en tareas y asignar horas.
Es decir:
Las estimaciones de las historias de usuario son más globales y las utilizo para dar estimaciones al negocio. Es muy útil en el caso que el negocio necesite tener buenas estimaciones del proyecto en sí: cuando, por ejemplo, es crítico cumplir plazos.
Las estimaciones en horas por tareas las utilizaré para controlar el Sprint, con el Burndown Chart.
Esta es una forma de hacerlo, pero no la única. Por ejemplo, en un proyecto que realicé tuvimos suficiente con las estimaciones de historias de usuario, puesto que eran pequeñas, (de 1 o 2 días de duración), y no valía la pena dividirlas en tareas. Como en ese caso tampoco utilizábamos ninguna "herramienta sofisticada" para llevar el tracking del proyecto (nuestro Sprint Backlog era un fichero excel y nuestro Burndown Chart, un gráfico derivado de dicho excel), pudimos cambiar nuestro "modus operandi" y trabajar con puntos de esfuerzo sin mucha complicación.
En general es importante entender los conceptos básicos (historias de usuario, tareas, etc.), pero es más importante aún saber adaptarlas a tu entorno (necesidades del negocio, equipo, etc.). Y, muchas veces, cambiar: A veces el equipo puede tener dificultad estimando en puntos de esfuerzo por estar muy habituado a estimar en horas, mientras que otras veces, al cabo de poco, estimar en puntos de esfuerzo resultará más afinado.
It is widely known that estimation is one of the most problematic areas in any software development project. But in this post, I don't want to focus on the most common problems of estimation (how to obtain estimates as close to reality as possible), but on a question related to SCRUM that I've seen many times.
As if the problems of estimating were not difficult enough, when we begin to work with SCRUM a lot of questions on how to estimate arise. Questions which I like to call "logistical". Do we estimate in hours? In history points? What is the relationship between tasks and user stories?
Let me explain my point of view, based on my experience. But let me make clear that there is no standard method. It is true that some tools (I'm thinking TFS) can predetermine how to set the estimates (for example in hours), but there is no magic formula. And this is good, because it is flexible.
SCRUM gives you the ability to adapt how you estimate to your real needs. In general, user stories are with history points while tasks are estimated in hours.
User stories compose the Product Backlog. Then, every Sprint some user stories are chosen and compose the Sprint Backlog (the Product Backlog is sorted by business priorities).
In the Sprint Kickoff meeting, the user stories will be analyzed and assigned, and the estimations will be "refined" to make them more accurate. This is when I usually break the user stories into tasks and assign hours to them.
That is:
Estimates of user stories (history points) are more global and I use them for the business. This is very useful when the business has the need for good estimates of the project itself: When, for example, is critical to meet deadlines.
Estimates of tasks (hours) are more specific and I use them to track the Sprint (Burndown Chart).
As said, this is a scheme that has worked for me, but it is not the only one. In one project I worked, we had enough with user stories estimates, since they were small, (1 or 2 days), and it was not worth splitting them into tasks. As in that case we used no "sophisticated tool" to track the project (our Sprint Backlog was an excel file and our Burndown Chart, a graph produced from that excel), we changed our "modus operandi" and worked with history points without much hassle. But, I repeat, each case is unique.
In general, it is important to understand the basics (user stories, tasks, etc.), but it is more important to learn how to adapt it to your environment (business needs, team, etc.). And don't be afraid to change: Sometimes, the team might have difficulty estimating with history points as they are used to estimate in hours, while other times, after a short period of time, estimation with history points becomes simpler and more accurate.
