#storypoints

En Scrum uno de los conceptos más confusos son los story points o puntos de historia. Sin embargo es la principal medida para las estimaciones de esfuerzo de las diferentes historias de usuario en Scrum. Así como la velocidad del equipo suele medirse en puntos de historia al sprint.

En Scrum la mayoría de los Scrum Master, especialmente cuando saben que su velocidad va a ser medida, utilizan los Story Points para medir estimar el esfuerzo de cada Historia de Usuario. 

¿Por qué los Story Points?

Los Story Points nacen de la dificultad en los proyectos de software de predecir el esfuerzo que va a llevar una tarea. Típicamente calculados en horas, en los proyectos Waterfall las estimaciones solían ser erróneas y retrasarse sistemáticamente. Principalmente porque quien estima tiene una experiencia, puede no haber entendido el problema en toda su complejidad, o quién desarrolla simplemente no está en el mismo punto que el primero. Pero aún siendo estimaciones desarrolladas por la misma persona, también existe el famoso sesgo del yo, que tiende a sobreestimar nuestras capacidades (el 80% de los conductores se declaran mejores conductores que el promedio :-) ), con lo que la insatisfacción se hacía crónica en los proyectos de software complejos.

Los Story Points son una medida relativa del esfuerzo que va a llevar una tarea. Se basan en que 1 Story Point podría ser algo muy sencillo que se hace en poco tiempo y no tiene nunca consecuencias. Se conoce y se ejecuta sin complicaciones. A partir de ahí, el 2º Story Point significa el doble de esfuerzo que el primero, y así sucesivamente. Para dar más claridad a este concepto de las unidades de medida, a veces se utiliza una escala de Fibonacci para hacer más evidente aún que cada paso que se da en la escala el esfuerzo se hace más impredecible.

Lo normal es cuando se definen las historias de usuario, definir la tarea perfectamente con un Definition of Done claro y además otorgarle unos Story Points. Entre 1 y 20 serían los que tendría sentido abordar, más de 20 ya le indican claramente al Product Owner que la Historia se tiene que descomponer en otras más pequeñas dado lo impredecible de la misma. Dependiendo de la longitud del sprint, a veces 12 Story Points ya no caben en un sprint por lo que lo idóneo será trocear o descomponer la Historia en subtareas más manejables.

Finalmente tendremos en el backlog unas historias de usuario con una estimación en Story Points de el esfuerzo que conllevan. El Product Owner basado en la prioridad para el negocio y el menor esfuerzo, introducirá determinasda Historias de Usuario en el Backlog del Sprint siguiente, y así los miembros del equipo de desarrollo podrán ver en detalle qué es lo que se pretende acometer. Se recomienda hacer un refinamiento o incluso un Sprint Poker Session para afinar los esfuerzos de las historias más maduras para así obtener un consenso del equipo a la hora de entregar estas estimaciones. Esto es clave si se quiere dar una velocidad del equipo, que las estimaciones en Story Points de las Historias de Usuario sean de todo el equipo, así podremos abstraernos de las capacidades individuales de una persona, típicamente el más senior de los miembros del equipo de desarrollo Scrum.

Finalmente se entregan unas estimaciones y el Backlog se cierra. Pueden salir determinados temas para abordar de las historias de usuario en un posterior Refinement, pero se aconseja empezar por las tareas más claras y sencillas así como por las que más valor le den al Product Owner.

Al finalizar el sprint, el Scrum Master contabilizará las tareas realizadas según la “definition of done”, y podrá calcular la velocidad de story points que el equipo entrega en cada Sprint, así como la diferencia entre lo estimado y lo finalmente entregado. Esta medida de velocidad le es muy útil al Scrum Master porque puede determinar cuando el equipo es maduro (acierta muchas veces en sus estimaciones en story points respecto a lo ejecutado), y puede detectar problemas en el equipo si la velocidad baja. Para ello es muy importante que el criterio de los Story Points permanezca fijo sprint a sprint, aunque haya cambios en el equipo.

Importante es reseñar que la velocidad de cada equipo en Story Points no es comparable entre diferentes equipos, ya que pueden tener diferentes conceptos de lo que es para ellos 1 Story Point. Al final esta cantidad se acuerda por consenso y se mantiene homogenea en el tiempo con el fin de medir la velocidad, no competir entre equipos diferentes.

Existen otras técnicas de estimación más sencillas como el tamaño de las camisetas (XS, S, M, L, XL, XXL,...) también muy utilizadas por los equipos Scrum. 

People have terrible self-esteem, mostly unconsciously; however, we can try to be more compassionate to ourselves, and accept the dynamic nature of all things that exist, instead of letting our head hit this involuntary human being. Project evaluation is a difficult task. Companies often blend the two main methods of project evaluation: the traditional method of surveying projects in hours or time and the new method of historical scoring.

Although Bacancy Technology uses the traditional clock method when evaluating agile projects, this blog post focuses on historical points and hours. Still, 9 agile scoring methods use the new agile story scoring technology. The nine technologies are:

1. Planning Poker 2. The Bucket System 3. Big/Uncertain/Small 4. TFB / NFC / 1 (Sprint) 5. Dot Voting 6. T-Shirt Sizes 7. Affinity Mapping 8. Ordering Protocol 9. Divide until Maximum Size or Less

Before we attempt to simplify this age-old debate of jira story point vs hours, let us understand the basics of both the traditional estimation method and the story point estimation method.

Traditional time estimation

As developers and connoisseurs, we know that traditional estimation involves a bottom-up approach to produce near-accurate project estimates. With a bottom-up approach, every aspect of the project needs to be examined in great detail to answer the obvious questions that all customers ask themselves: "How long does the project take?

These details usually include the skills of everyone involved in the project. The project work speed, availability, and possibility of emergency. This helps managers to accurately estimate the progress of a particular project in hours or days. Now let us understand the relationship between project history and hours in detail.

Agile story scoring method

The agile scoring method uses the opposite method, called the top-down method. In this case, the score depends on the complexity of the project or the amount of work required to complete it. This evaluation method is based on the principle of relativity. For example, the difficulty of question A depends on the difficulty of question B.

This way, you can give the customer a rough estimate of the difficulty. , The team checks every aspect of the project related to other aspects of the project.

This study measures the difficulty of one story versus another and how much effort is required to complete it.

INDEX

TL;DR

Late to the party

Guilty by association

Inputs vs Outcomes

There is no cake

Are you OK?

How big is small?

Be Precise?

Do you trust me?

TL;DR

Just my 0.02 units of currency - but :

Don't confuse estimation with setting a final project delivery date

Consider estimates as an input into a process, not an outcome/performance

Estimates can help the team plan their work and spot bottle necks/problems before they happen

Estimates can confirm and communicate a shared understanding

Velocity could be the answer - I'm not sure

Don't use estimates to measure output

Trust the team is working hard and the stakeholder isn't out to get you

LATE TO THE PARTY

Yup. But it does look like it's going on all night. The debate still rages, and who doesn't love a heated debate. https://twitter.com/search?q=%23NoEstimates

There are very smart people advocating for no estimates at all. There is a nice post by Malcom Isaacs, called "The #NoEstimate debate", which seems to hit a lot of the high notes and key players.

As I have come to understand it, the origin of this debate was trigged by a 2012 blog post titled No Estimate Programming Series by Woody Zuill, where he outlined the case for #NoEstimates.

No point me rehashing the debate, it's better if you read the debate summary and origin post above. Then I can dive into my own 0.02 units of currency on the topic.

Why am I sharing? Because I want to test my hypnosis. By sharing my thoughts and take on this, I am actively seeking contrary/other/agreeing points of view, so I can be better informed and make the right choices for my self and my team.

GUILTY BY ASSOCIATION

Some criticism of estimation, to me, seem to be linked to other processes people associate with estimation.

Using estimate to set hard delivery deadlines at the start of a project is very unpopular (rightly). Estimation is being associated with that bad practice, but it's not the process of estimation at fault - its how the estimate is being used.

Waterfall vs Scrum vs Kanban vs ?? It is another debate entirely, while making estimates can be a critical component of wider project management frameworks, I think its important we look at estimates on their own merits (or failures) and not taint estimation with our feeling of related (and/or dependent) processes.

INPUT VS OUTCOMES

I consider an estimates to be part of the input, not the output.

Accelerate Metrics have give us fantastic ways to measure software development teams performance/Code Metrics, backed by some impressive research. They measure outcomes and there are a bunch of tools to help make this easy. None of the accelerate metrics, measure input, the book does talk a lot about the inputs - but they don't measure them.

If you start using inputs, as a measure of outcomes, you can get into an ugly place, fast. It sets up (and rewards) all sorts of bad behaviour, like padding estimates and/or you see Parkinson's Law kick in.

THERE IS NO CAKE

I admit, the idea of not doing an estimate is appealing.

Its less work, one less thing to do, before we get to the fun part of creating. It is easy to revert to #NoEstimate in times of stress or urgency - we don't have time, it doesn't add value, just get it done. Right?

But. From the Original Post that started it all:

Ask Boss to select one “small” thing that she felt was very important.

Quite a bit to unpack here:

"Small" is an estimate.

So now we are talking about degrees of estimation, not #NoEstimation. Right?

How does the team/pm/dev know what "small" is? Relative to other tasks? Relative to total time of the project?

Why pick a small thing? Why not just the very important thing?

Even in #NoEstimate, we still expect estimates.

Even if you remove the word "Small" and used any story without some kind of understanding of size, then there is the question of what's the right size for a story? How do you know when to break a story down more or leave it alone? What becomes our unit of work?

So we do estimate, the question is more about WHAT we do with the estimates.

ARE YOU OK?

If we do have estimates (and we do), what should they be used for? I would argue, as in input, they should be used to make sure the team members are OK.

By that I mean:

Is the team member stuck on their current task?

Does the team/team member have too much work?

Does the team/team member have enough work to be happy/busy?

It's hard to answer the above, without some metric or measure of input.

Looks like Mike has been on the same task for a week - is that OK?

Task was expected to be completed quickly = No, he may need help. We also may need to re-assess similar work in the future, what did we miss?

Task was expected to take a whole = OK, keep going, don't interrupt.

5 tasks, no estimates, is that enough work for Jane for the next 2 weeks?

All tasks are small, expected to be completed quickly = Probably not, may need more - by why does she only have small tasks?

A mix of small/large = Yes, probably

All tasks are huge and complex = More than enough, perhaps we need to see about sharing out the work better?

If we use estimates as a way to keep teams happy and productive (not as a measure of output/outcomes), I think we can keep a lot of the value from estimation, its when estimates are used as a tool to measure output and/or fix deadlines, that we get into trouble.

HOW BIG IS SMALL?

"It depends" → "It doesn't matter"

But then why bother at all?

Because, I would argue, the value is in coming from an agreed group understanding on complexity/likely time to deliver. Doesn't really matter how you measure it: hours, story points or story count - it doesn't matter. The value here is in (as a team) exploring and communicating what needs to be done and how hard it might be to do it, before you start doing it.

The process of estimation is high value. Estimating work means dedicating time to understand it, agreeing on that understanding and then communicating that understanding in a standardized way.

That act of discussing, and then estimating can tease out unexpected or overlooked complexity, miss-understandings and gaps in understanding. If 3 devs agree, but one other has a very different estimate, that is something to be discussed.

Small? I've found that once a single task gets over a few days, all bets are off, so we should break it down and/or get more context. For me, an upper bound on tickets should be a few days.

What metric you use is much less important than the act of discussing and agreeing. And, once you have that agreement, that metric can be communicated to others, who can take it into consideration when deciding on the importance of any give task or group of tasks to achieve an outcome.

BE PRECISE?

Precise estimates and other logical fallacies.

Another key criticism of estimates is they are not accurate, and so they are not worth the time. As I discussed above, I don't think this is true. The value is in the process, as much as the output. Refining the accuracy of the estimates is useful in as much as it helps the team communicate and coordinate and better manage their own time/and input, not output.

They get even less precise if they are used as a measure of output, as they are easy to game, pad or otherwise manipulate.

WHY NOT VELOCITY?

In many #NoEstimate posts, they point to looking at velocity (tasks/stories completed) as an alternative to estimating.

Velocity is not without its drawbacks, it can be manipulated and may incentivize the wrong behaviour depending on how the metric is used.  

But, even if you skip estimation and use velocity, you are still actually estimating on the front, to slice up the work into "small" story units to work on. But you lose resolution, A 1 line type-o fix in a field label vs adding a new database abstraction layer - both could be a single story, but with very different estimates and are not equal.

It feels like trying to measure an input, with an outcome. And you are going to miss out on the other benefits of estimation, if you skip the process. But perhaps its fine - I'm not sure.

DO YOU TRUST ME?

The final key criticism of estimates I want to consider, is fear. Fear that the estimate they create, will be used as a tool to punish or pressure them to do things that are unsustainable, unreasonable or unachievable and which then cause undue stress and disappointment.

Story points – a tool for better planning. Does relative estimation and story point work? Here are some cases of applying it in the real world!

Traditional exhaustive estimation sessions are on the rebound within development teams. They have started adopting relative measures, known as Story Points, in order to become more effective in the estimation session and more precise in planning their releases. Story points are a relative measure that can be used for agile estimation of size. The team decides how big a point is, and based on…