Los secretos que esconden los puntos de historia y la estimación ágil

Una buena estimación ayuda a los propietarios del producto optimizar sus procesos en términos de eficiencia e impacto. Por eso es tan importante. 

Dan Radigan Dan Radigan

Estimation is hard. For software developers, it's among the most difficult–if not the most difficult–aspects of the job. It must take into account a slew of factors that help product owners make decisions that affect the entire team–and the business. With all that at stake, it's no wonder everyone from developers to upper management is prone to getting their undies in a bunch about it. But that's a mistake. Agile estimation is just that: an estimate. Not a blood-oath. 

There's no requirement to work weekends in order to compensate for under-estimating a piece of work. That said, let's look at some ways to make agile estimates as accurate as possible.  

Colaboración con el propietario del producto

In agile development, the product owner is tasked with prioritizing the backlog–the ordered list of work that contains short descriptions of all desired features and fixes for a product. Product owners capture requirements from the business, but they don’t always understand the details of implementation. So good estimation can give the product owner new insight into the level of effort for each work item, which then feeds back into their assessment of each item's relative priority.

When the engineering team begins its estimation process, questions usually arise about requirements and user stories. And that's good: those questions help the entire team understand the work more fully. For product owners specifically, breaking down work items into granular pieces and estimates via story points helps them prioritize all (and potentially hidden!) areas of work. And once they have estimates from the dev team, it's not uncommon for a product owner to reorder items on the backlog. 

La estimación ágil es un trabajo en equipo

Involving everyone (developers, designers, testers, deployers... everyone) on the team is key. Each team member brings a different perspective on the product and the work required to deliver a user story. For example, if product management wants to do something that seems simple, like support a new web browser, development and QA need to weigh in because their experience has taught them what dragons may be lurking beneath the surface.

Likewise, design changes require not only the design team's input, but that of development and QA as well. Leaving part of the broader product team out of the estimation process creates lower quality estimates, lowers morale because key contributors don't feel included, and compromises the quality of the software.

No dejes que tu equipo sea víctima de las estimaciones realizadas en el vacío. Es un camino seguro al fracaso. 

Puntos de historia frente a horas

Los equipos de software tradicionales dan estimaciones en un formato de tiempo: días, semanas, meses, etc. Muchos equipos ágiles, sin embargo, ahora usan los puntos de historia. Los puntos de historia evalúan el esfuerzo relativo del trabajo en un formato a lo Fibonacci: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Puede parecer antintuitivo, pero esa abstracción es útil porque incita al equipo a tomar decisiones más difíciles acerca de la dificultad del trabajo. Estas son algunas pocas razones para usar puntos de historia:

  • Las fechas no tienen en cuenta el trabajo no relacionado con el proyecto que inevitablemente surge en nuestro día a día, como correos electrónicos, reuniones y entrevistas en las que un miembro del equipo puede participar.
  • Las fechas tienen una connotación emocional. La estimación relativa elimina este componente.
  • Cada equipo estima el trabajo en una escala ligeramente diferente, lo cual significa que su velocidad (medida en puntos) será diferente, como es natural. Asimismo, esto imposibilita que se politiquee usando la velocidad como arma.
  • Once you agree on the relative effort of each story point value, you can assign points quickly without much debate. 
  • Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time. 

Story points and planning poker

Los equipos que se estén iniciando en los puntos de historia usan un ejercicio llamado póker de planificación. En Atlassian, el póker de planificación es una práctica habitual en toda la empresa. Los miembros del equipo toman un elemento del backlog, hablan sobre él brevemente y cada uno fórmula mentalmente una estimación. A continuación, todos levantan una tarjeta con el número que refleje su estimación. Si todo el mundo está de acuerdo, ¡estupendo! De lo contrario, dedica algo de tiempo (no mucho, tan solo un par de minutos) para entender el motivo detrás de las distintas estimaciones. Recuerda, sin embargo, que la estimación debe ser una actividad de alto nivel. Si el equipo se va por las ramas, respira hondo y encauza el debate a un nivel más general.

Ready to give it a try? 

Estima con mayor inteligencia, no con mayor esfuerzo

Ninguna tarea individual debe superar las 16 horas de trabajo. (Si usas puntos de historia, puedes decidir que 20 puntos es el límite superior, por ejemplo). Sencillamente, es demasiado complicado estimar elementos de trabajo individuales de mayor duración con confianza. Esa confianza es especialmente importante para los elementos en la parte superior del backlog. Cuando algo se estima por encima del límite de 16 horas (o 20 puntos) del equipo, será una señal para dividirlo granularmente y volver a estimarlo.

Para los elementos que se encuentren más abajo en el backlog, basta con una estimación aproximada. Cuando el equipo empiece a trabajar en esos elementos, los requisitos podrían haber cambiado y la aplicación seguramente habrá cambiado también, de modo que las estimaciones no serán tan precisas. No pierdas tiempo estimando trabajo que posiblemente cambiará. Da al propietario del producto una cifra aproximada que pueda utilizar para priorizar la hoja de ruta del producto adecuadamente.

Aprende de las estimaciones anteriores

Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Many agile tools (like Jira Software) track story points, which makes reflecting on and re-calibrating estimates a lot easier. Try, for example, pulling up the last 5 user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. If not, discuss why. Use that insight in future estimation discussions.

Like everything else in agile, estimation is a practice. You'll get better and better with time. 

Up Next
Métricas