Reimplementación de Scrum: Perfeccionando la planificación de Sprint

En primer lugar, tras una intervención en la forma en como veníamos haciendo las planificaciones de Sprint, las hemos optimizado mucho. Un error que tuvimos era comenzar la reunión sin ningún tipo de “agenda”. Si bien no es necesaria la formalidad, desde el último Sprint Planning comenzamos a seguir un hilo conductor. El Sprint Planning se puede dividir  en dos partes:

¿Qué se tiene que hacer?
Participan el Product Owner y el equipo. Definimos qué objetivos queremos lograr en este Sprint. En esta instancia el Product Owner participa definiendo las prioridades como siempre. Los objetivos son definidos y explicitados de manera que todos seamos concientes del objetivo del Sprint.

¿Cómo se tiene que hacer?
En esta etapa, el equipo granula un poco más las historias de usuarios de manera de obtener tareas específicas. Parte de este trabajo se hace en esta etapa inicial, pero otra gran parte se va realizando en los Daily Meeting, a medida que se van definiendo bien las tareas.

El error más grande que tuvimos en nuestro primer Sprint, fue la estimación de las tareas. Siendo ésta la segunda aplicación de Scrum, puede identificar un patrón. Es muy difícil para un equipo estimar el tiempo que le va a llevar realizar el trabajo, si nunca lo hizo antes. Además, se cae en dos errores aparentemente comunes:

  • No definir el alcance de una tarea: Las tareas se definen a muy alto nivel. Por ejemplo “Alta, baja y modificación de Usuarios” puede sonar a tarea sencilla. Pero puede afectar varias áreas: el análisis del modelo de negocios, la interfaz, el acceso a base de datos, etc. Por esto, uno de los primeros aprendizajes fue definir el alcance y limitaciones de una tarea, y tratar de definir todo el trabajo que abarca que un ABM de usuarios esté terminado.
  • Sobrestimar capacidades o subestimar tareas: Esto sucede sobretodo en equipos nuevos o con poca experiencia. El equipo con el que contamos se consolidó recientemente (aproximadamente cuando comenzamos a implementar Scrum) y la arquitectura y tecnologías con las que trabajamos deben ser asimiladas y comprendidas por cada integrante del equipo.

A medida que el equipo se va introduciendo en el ritmo, todo se va mejorando de a poco. Todavía queda trabajo por hacer, pero es bueno ver que no nos estamos quedando en la zona de confort.

Be Sociable, Share!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *