Are you using Planning Poker for estimating tasks? Maybe you should reconsider it

If you are using Planning Poker for estimating tasks in the Sprint Backlog, maybe you’d better reconsider it. It’s a tool that can be very useful when estimating user stories or Product Backlog items. But the characteristics of the tasks in the Sprint Backlog are very different from those of the Product Backlog items, and most times Planning Poker, or any other estimation tool based in orders of magnitude, is not adequate for supporting those estimations.

image_thumb[1]

The main reasons of Planning Poker not being a good tool for estimating tasks are:

  • Task estimates are usually given in hours, and because of the very nature of the tasks, they should be in the range of a few hours, from less than one hour to a maximum of 16 hours. That is, tasks estimates not necessarily grow by orders of magnitude, as user stories estimates tend to do, but instead of that, they stand within a small magnitude. Planning Poker only provides a few cards for the range of small estimates, and we also have cards to provide large estimations, which shouldn’t even occur if the tasks had been decomposed properly.
  • As a result of this, when working with Planning Poker we’ll miss some values ​​that are not present (on purpose) in a Planning Poker deck, since for estimating tasks we need a ​​more accurate range of values than for estimating user stories. For example we will not be able to give an estimate of 4 or 6 hours for a task, which a priori should be perfectly possible. I’ve even found teams that were taking more than one card at a time to reach the desired amount for the estimate, which demonstrates the limited usefulness of the tool for this purpose.

Therefore, it would be appropriate to leave Planning Poker, and other methods based on orders of magnitude as T-Shirt Sizing, to estimate user stories. To estimate tasks, we can simply use Wideband Delphi, or even simpler tools such as analogy, decomposition or expert opinion.

Apart from this, it might even be questionable whether it is better to estimate tasks in groups or individually. Ken Schwaber himself recommends the latter (http://kenschwaber.wordpress.com/2010/10/, Example 2), although this would be a good subject for another discussion.

And finally, remember that sometimes it’s even better to not estimate the tasks. Estimates are not value that we can deliver to the customer, but rather they can represent waste, and if we can properly do planning without doing the effort of estimating, we will earn this time to advance in the delivery of value. Some teams simply break down the work into tasks of a similar size, so that planning can be based on counting the tasks that we’re going to be able to finish.

I’m leaving you with the slides from my session on agile estimation at the last TechEd Middle East, it’s mainly about estimation for user stories, but the concepts can be useful in a wider sense.

¿Usas Planning Poker para estimar tareas? Quizá deberías pensarlo mejor

¿Estás usando Planning Poker para estimar tareas en el Sprint Backlog? Quizás deberías replanteártelo. Es una herramienta que puede ser muy útil a la hora de estimar historias de usuario o elementos del Product Backlog. Pero las características de las tareas en el Sprint Backlog son bien distintas de las de los elementos del Product Backlog, y por lo general Planning Poker, o cualquier otra herramienta de estimación que se base en órdenes de magnitud, no es adecuada para dar soporte a estas estimaciones.

image

Las principales razones por las que Planning Poker no es una buena herramienta para estimar tareas son:

  • Las estimaciones de tareas se dan por lo general en horas, y por la propia naturaleza de las tareas, deberían estar en el rango de unas pocas horas, desde menos de una hora a un máximo de unas 16 horas. Es decir, las estimaciones de las tareas no crecen necesariamente en órdenes de magnitud, tal y como lo suelen hacer las estimaciones de las historias de usuario, sino que se mantienen en una magnitud pequeña. En Planning Poker tenemos sólo unas cuantas cartas para el rango de estimaciones pequeño, y además tenemos cartas para dar estimaciones grandes, que no deberían ni siquiera aparecer si las tareas han sido descompuestas adecuadamente.
  • Como consecuencia de lo anterior, al estimar tareas con Planning Poker vamos a echar en falta algunos valores que no están presentes (a propósito) en una baraja de Planning Poker, ya que para estimar tareas necesitaremos un rango de valores más preciso que para estimar historias de usuario. Por ejemplo no vamos a poder dar una estimación de 4 o de 6 horas para una tarea, lo cual a priori debería ser perfectamente posible. Me he encontrado con equipos que estaban incluso sacando más de una carta cada vez para poder llegar a la suma deseada para la estimación, lo cual demuestra la poca utilidad de la herramienta para este fin.

Por lo tanto, lo adecuado sería dejar Planning Poker, y otros métodos basados en órdenes de magnitud como T-Shirt Sizing, para estimar historias de usuario. Para estimar tareas podemos usar simplemente Wideband Delphi, o herramientas incluso más simples como analogía, desagregación u opinión del experto.

Aparte de esto, incluso podría ser discutible si es mejor estimar tareas en grupo o hacerlo individualmente. El mismo Ken Schwaber nos recomienda lo segundo (http://kenschwaber.wordpress.com/2010/10/ , Ejemplo 2), aunque esto daría para mucho debate.

Y por último, recuerda que a veces lo mejor es ni siquiera estimar las tareas. Las estimaciones no son valor que podamos entregar al cliente, sino más bien desperdicio, y si podemos permitirnos planificar adecuadamente sin tener que hacer el esfuerzo de estimación, estaremos ganando ese tiempo para avanzar en la entrega de valor. Algunos equipos simplemente descomponen el trabajo en tareas de un tamaño similar, con lo que la planificación se puede basar en contar las tareas que vamos a ser capaces de sacar adelante.

Os dejo con las slides de mi sesión sobre estimación ágil en el último TechEd de Oriente Medio; habla más bien de estimación para historias de usuario, pero los conceptos son útiles en sentido general.

Defining “Done” at XP2011

Although it can seem obvious, sometimes it’s difficult to state when we’ve finished working on a feature or characteristic during a project. It usually happens by omission; that is, we leave apart undone things when time is short or because we don’t consider that they are important. The problem is that these things usually return soon after, as bugs, technical debt or simply pending work, and most times it represents a bigger inconvenience and effort than if we had solved them in the right moment.

Defining explicitly what means that anything is “Done” (and trying to stick to that definition), is essential in order to avoid these situations. This is what I tried to stress during my Lightning Talk last Thursday, 12th at XP2011 conference; I believe that the slides show the idea quite well:

Definiendo “Hecho” en XP2011

Aunque pueda parecer evidente, en ocasiones es difícil determinar cuándo hemos terminado de trabajar en una funcionalidad o característica durante un proyecto. Suele ocurrir especialmente por omisión; es decir, nos dejamos cosas sin hacer cuando se echa el tiempo encima, o porque no las consideramos importantes. El problema es que todo esto suele retornar al cabo del tiempo en forma de defectos, deuda técnica o simplemente trabajo pendiente, y en muchas ocasiones supone un inconveniente y un esfuerzo mucho mayor que si lo hubiésemos solucionado en su momento.

Definir explícitamente qué significa que algo esté “Hecho” (e intentar cumplir esa definición), es fundamental para evitar estas situaciones. Es lo que intenté resaltar en mi Lightning Talk del pasado jueves 12 en la conferencia XP2011; creo que la presentación refleja bastante bien el concepto:

The Spanish version of the Scrum Guide is now available

The Scrum Guide, written by the Scrum creators Ken Schwaber and Jeff Sutherland, represents the official Scrum Body of Knowledge, and is an essential resource if you want to begin learning about the framework, or to clarify any occasional doubt.

It has been translated to no less than 20 languages, and, although it was already available in Spanish, it has just been released a new version which represents a significant improvement on the translation, and which has been brought up to date according to the last English original.

It has been a pleasure for me to take part in the translation effort, and I hope that the outcome will be valuable for many people… so I encourage you to visit scrum.org and have a look to the Scrum Guide in Spanish.

 

Scrum.org-small2[5]

Ya está disponible la Guía de Scrum en Español

La Guía de Scrum, escrita por los creadores de Scrum, Ken Schwaber y Jeff Sutherland, constituye la Base de Conocimiento oficial de Scrum, y es un recurso imprescindible para comenzar a aprender sobre el marco de trabajo, o como herramienta de consulta puntual que ayude a despejar dudas.

Ha sido traducida a más de 20 idiomas, y aunque ya estaba disponible en Español, acaba de ser liberada una versión que supone una mejora sustancial en la traducción, y que ha sido puesta al día a partir del último original en Inglés.

Ha sido un placer para mí poder colaborar en dicha traducción, y espero que sea de utilidad para mucha gente… así que te animo a que entres en scrum.org y eches un vistazo a la Guía de Scrum en Español.

 

Scrum.org-small2