Definition of Done and Acceptance Criteria

It is always useful to share a common vocabulary in a team, and some terms lead to confusion, as it happens with Definition of Done and Acceptance Criteria.

In an agile project the work to be performed is described in User Stories, for example:

“As a premium user I want to check the special offers addressed to me so that I can purchase them”

Every User Story can have a set of “conditions of satisfaction”, things that must be satisfied in order to consider the User Story finished:

• The premium user can list the special offers addressed directly to him
• Each offer has a price, and it’s shown in the user’s currency
• If the list is empty the user is notified about it and he can see the conditions
• Every item has link so it can be purchased

These conditions are the Acceptance Criteria and are set per User Story, and are meant to remove ambiguity. In Scrum terminology they are the Product Owner's expectations.

The Definition of Done (DoD)  is a term used in Scrum but can also used in other methodologies. DoD is a set of conditions that every developer must satisfy in order to say he has completely finished with a User Story, so that it’s potentially shippable. It's a statement on quality, and it’s meant to avoid “Technical debt”. You cannot say “it’s done, just some documentation pending”.

Every team defines their own requirements for Done. The obvious one is “all Acceptance Criteria pass” but other teams must choose some of the following:

• All code has been reviewed (if not pair-programmed)
• Code has been deployed using Continuous Integration
• Documentation updated
• Systems Administrators notified about changes
• Training manual updated
• No pending bugs
• Performance tests passed
• All code under version control
• All code needs to have automatic acceptance test
• Business Analyst accepted
• Unit Tests pass
• Code coverage over 70%

If a User Story is not done, it must pass to the following sprint.

In Scrum you can have a Definition of Done for a User Story, for a Release and for a Sprint Planning.

Definition of Done is a team commitment on quality. Acceptance Criteria sets the minimum validations to check on a User Story completion.

There are some practices to include Acceptance Criteria in the development process, like BDD (Behavioural Driven Developmen) and ATDD (Acceptance Test Driven Development), but that’ll be another day.

El secreto del éxito de los freelance

No soy un artista, ni un freelance (autónomo) pero soy un fan de Neil Gaiman y cuando vi en el blog de Olaf Lewitz que había dado un discurso a unos graduados en arte, me puse a mirar el vídeo.
Para mi ha resultado tan inspirador como el discurso de Jobs o de Guardiola que ya comenté en este blog.

Me quedo con el secreto de los freelance:

La gente consigue un trabajo porque... consigue un trabajo. Pero siguen trabajando porque:

• Su trabajo es bueno
• Es fácil trabajar con ellos
• Entregan el trabajo a tiempo

Y lo mejor de todo es que no necesitas las tres. ¡Con sólo dos ya está bien!

Tolerarán si eres desagradable pero haces un buen trabajo y entregas a tiempo.

Te perdonarán que entregues tarde si tu trabajo es bueno y les gustas.

Y no tienes que ser muy bueno si entregas a tiempo y es agradable trabajar contigo.

Sobretodo, disfrutar y cometer errores interesantes.

Make Good Art. 

Agile Estimating and Planning

De Mike Cohn. 2005. Publicado por Prentice Hall. 368 páginas

Aunque ya tiene unos años, sigue siendo la referencia en la estimación y planificación de proyectos ágiles.
Es muy probable que la mayoría del material que presenta ya te haya llegado de alguna manera u otra, pero resulta muy útil acudir a la fuente.

La planificación de los proyectos tiene los siguientes beneficios:

• Reduce el riesgo
• Reduce incerteza
• Ayuda a la toma de decisiones
• Establece confianza
• Transmite información

Todos los interesados en el proyecto han de saber que las estimaciones se van haciendo más precisas a medida que avanza el proyecto, y eso se puede expresar gráficamente con el cono de incertidumbre. Las estimaciones, por tanto, deberían expresar esta incerteza, por ejemplo indicándolas como un rango. Por otro lado, una estimación no es lo mismo que un compromiso.

En los proyectos ágiles se estiman funcionalidades y no actividades, y se recomienda estimar en tamaño y no en duración. La medida se puede hacer en puntos de historia o en días ideales.

Para ayudar a planificar, puede resultar interesante medir la velocidad del equipo, que se entiende como el número de puntos de historia que un equipo puede resolver durante una iteración.

La planificación ágil tiene las siguientes características:

• Se centra en la planificación, no en el plan
• Estimula el cambio
• Resulta en planes fáciles de cambiar
• Se extiende durante todo el proyecto

El autor recorre otros aspectos muy interesantes de la estimación y de la planificación, como las épicas y los temas, las estimaciones en equipo, la escala de estimación, el planning poker, el modelo de Kano de satisfacción del cliente, la planificación a diferentes niveles, las técnicas de DSDM, los buffers de funcionalidades y de calendario, y algunas herramientas visuales de planificación.

El autor le da valor a la planificación, que ya de por sí es un tema espinoso, pero si en el contexto del proyecto/empresa se trata de una necesidad, esta puede ser una lectura interesante.

La Técnica del Pomodoro

Cuando tenemos que trabajar en algo que requiere mucha concentración muchas veces sucede que tenemos interrupciones. A veces son distracciones del exterior (una llamada, alguien que nos habla) pero otras veces la distracción viene de nuestro interior (soñamos despiertos, nos acordamos de otro problema, consultamos el correo de forma compulsiva). Culpamos las distracciones externas y nos aislamos en una sala, para conseguir la misma falta de productividad: nuestras distracciones internas matan nuestro trabajo.

La Técnica del Pomodoro es un método de gestión del tiempo diseñado para superar las distracciones internas y permitir que nos enfoquemos en la tarea a desarrollar.

El método es muy sencillo. El tiempo de trabajo se divide en intervalos de 25 minutos (llamados timeboxes o “pomodoros”, la palabra italiana para “tomate”). Después de cada pomodoro te tomas un descanso de 5 minutos. Después de cuatro pomodoros te tomas un descanso más largo de 15 a 30 minutos.

Comienzas el día escribiendo en un papel la lista de tareas a realizar. Para cada pomodoro que dedicas a la tarea, escribes una X en la lista. Si te das cuenta que has tenido una interrupción del interior, marcas con un apóstrofe ('). Si tienes una interrupción del exterior tienes que parar el pomodoro y volver a empezar. El timebox es indivisible.

El relativo corto tiempo dedicado a una tarea te permite mantener el foco. Los descansos cortos te permiten mantener el flujo. Mientras estás en el timebox de descanso, deberías hacer algo que no tuviese nada que ver con la tarea, y si se trata de una actividad que requiera caminar o moverse, mejor.

Hay equipos que trabajan en pomodoros sincronizados. Hay entornos en los que si alguien alerta que está en un pomodoro, nadie le interrumpirá.

Hay más detalles de la técnica (como estimar las tareas y aprender de las estimaciones) y explicaciones del porqué de la duración de 25 minutos, la preferencia por un temporizador de verdad y el valor del sonido del tic-tic. Puedes encontrar el libro de Francesco Cirillo (que creó la técnica en los 90) en la página web de la Técnica del Pomodoro.