Agile Estimation and Planning: Demystifying the Black Art

This article is not about how to do estimation and planning in detail for Scrum teams, no magic recipes or silver bullets, it´s not also about numerical models or techniques one hundred percent bullet proof. This is more about what I saw that it works in practice and how this correlates with Agile and Scrum values.

That been said and if still have your attention, let me start saying that I´ve borrowed the phrase "Demystifying the Black Art" from a Steve McConnell´s book. I did this for a very good reason, I´ve read that book many times and my only conclusion is that is impossible to provide accurate estimations for the simple reason that no one can predict the future. Understanding this simple fact prepare us for start doing Scrum estimations. Part of the preparation is, if you´re a manager, that you´ll need to resign to have everything accurately estimated before work even started.

But then what? Are Scrum projects totally chaotic? In a way, yes they are, the great difference though is that Scrum publicly recognizes that chaos is there, embraced it and prepares your mind set to cope with continuous change and adaptation.

Reestimate, Reestimate, ….

So, the new game becomes now not how good am I estimating, but rather how often I reestimate. Estimations in Scrum are not cemented deals, they are negotiable as work progresses through sprints, but then, how I can keep things under control without exhausting my team by adding more and more work? Answer is simple; if you add work then you move less priority work to the backlog and reestimate accordingly.

Again, is not a matter of having precise estimations, is a matter of being prepared to reestimate whenever is necessary. Further, there´s a learning curve that Scrum take full advantage of it. For instance, if you estimate a task and then keep your estimations even if you know they are not longer valid, then there´s no chance to refine them with new information and experience. Scrum on the contrary favors that you look and your estimations and make them up as many times as you feel so.

Last part sounds like nightmare for many managers, but come on, reestimating not only means that the number of hours will increase; frequently reestimations take things in the other direction. After all, everybody knows that people try to be over-conservative when providing initial estimations. So if you reestimate, there´s a fair good chance that you reduce the initial slack that you put just in case things get ugly.

No Black Art Anymore

But wait, estimation is still black art, something is missing and that is how to actually estimate. You can read many good books on the subject written by Mike Cohn, even attend to his seminars if you can afford it, but here´s is my simple and free advice: use group estimation. Estimations that are provided not only by one individual but by a group have more value and more chances to be not so much off the mark, why? Only because group estimations force the group to think it through before putting estimates.

Another piece of free advice, actually this comes from McConnell, estimate using ranges like thinking first in worst case estimates, then in best case estimates and put your more realistic estimate somewhere inside that range. Again, if you think in this as a group exercise you´d have more chances to make it successful, at least it won´t be boring :)

But what if the group can´t come to an agreement? Well you can buy the Cohn´s planning poker decks; note that you´ll need one deck per each individual in your team. I offer you a cheaper and in some cultures more fun solution: just vote using your fingers to indicate numbers, like one finger for one, two fingers for two and so on.

Team Alignment is Key

If we reach this far you’re almost ready to discover the secret behind planning: the truth is that Scrum planning is not more than a short meeting (by short I mean less than four hours) divided in two halves whereas the first half is for understanding what user stories are and the second for providing estimations. Again nothing new here, Scrum has been talking about planning meetings for quite a while now. Understanding what to do seems to be crucial, but wait we´re doing Scrum, aren’t we? Don´t fall in the trap of trying to understand what needs to be done to the last detail even before coding a single line, the only way to truly understand something is when you actually do the work.

What´s the value of having planning meetings? The answer is quiet simple: you get all your team in room and make them talk about their understanding of what needs to be done. That simple exercise will do the magic of aligning everybody´s energy and attention towards a common goal (a.k.a. Sprint goal). Like Jeff Sutherland said "Scrum is all about aligning your team in the same direction" and hence is the true value of planning meetings.

Orlando Scrum Gathering

What a fantastic conference this has been! Check this link for a promotional video

http://www.scrumalliance.org/pages/media

And this other one for the presentations

http://www.scrumalliance.org/resources?tag=2010+Orlando+Gathering

Hope the Scrum Alliance continue organizing such great conferences

Agiles 2010

La conferencia Latinoamericana de Metodologías Agiles ya está en marcha, más información aquí http://agiles2010.agiles.org/lang/es/

Herramientas Electrónicas y Scrum

Veo un tema que se repite una y otra vez en varios foros y grupos de discusión, siempre hay alguien que repite la misma pregunta, ¿cuál es la mejor herramienta para hacer buen planning y tracking con Scrum?

Dependiendo del grado de conocimiento y experiencia de la gente de estos grupos de discusión, las respuestas varían desde herramientas sofisticadas y costosas como VersionOne, Rally o ScrumWorks hasta cosas más simples como Scrumy o algo en el medio como Xplanner o PivotalTracker. Inclusive Microsoft hizo su aporte con su herramienta-super-complicada-apta-para-todo-uso Team Fundation Server.

Desde luego siempre habrá buenos vendedores que recomendaran utilizar sus herramientas ofreciendo soporte, descuento por licencias o quien sabe que otro atractivo. Pero hay algo de más de fondo, ¿qué tan exitosa puede ser una herramienta en un equipo que no crea en su uso? Más aun, las herramientas por si solas no harán ningún bien, más bien complicaran el trabajo de un equipo creando un overhead a la hora de registrar user stories y horas.

Yendo un paso mas atrás, ¿porque se deben utilizar herramientas electrónica para hacer tracking del progreso? La respuesta Scrum a la pregunta es porque tenemos un equipo distribuido, de los contrario deberíamos volver la vieja y efectiva escuela del post-it.

Una paso mas atrás todavía, ¿de qué sirven las herramientas si los equipos nos tienen sólidos principios ingenieriles y de trabajo en equipo? En mi experiencia las herramientas no hacen ningún bien por si solas sino vienen acompañadas de una solida base en Agile, XP, Scrum y otro sabores agiles.

Ahora bien, una experiencia interesante es introducir herramientas en paralelo a la introducción de conceptos agiles. Esto puede tener sentido ya que el equipo recibe la influencia directa de la herramienta y puede corresponderla con los conceptos.

Finalmente, la utilización efectiva y constante de las herramientas dependerá de cuan convencido de su utilidad el equipo este. Los buenos vendedores pueden vender licencias, mas son los coaches los que llevan a los equipos a su utilización efectiva, constante y productiva.

Agile Course Related Blogs

Some of the guys in the last Agile Course have been kind enough to publish in their blogs some notes and comments, check this link