Ya hablamos de la importancia de redactar la Definition of Ready durante el Sprint Cero. Vamos ahora con el otro documento que no debe faltar antes de comenzar con los desarrollos en un proyecto Scrum: la Definition of Done.
La Definition of Ready en Scrum
Durante el Sprint Zero (o como quieras llamarle a la fase de planificación previa a los Sprints) el Equipo Scrum (Product Owner, Equipo de Desarrollo y Scrum Master) debe dejar definidas y por escrito un par de reglas muy importantes de cara al buen entendimiento del equipo: la Definition of Ready y la Definition of Done.
En este post hablaremos de la Definition of Ready y de cuán importante es dejarla bien redactada y visible a todos.
Comenzamos.
El mal Product Owner
En el post sobre el Product Owner estuvimos hablando sobre qué se espera de un profesional que desempeñe este rol.
Ser Product Owner implica una gran responsabilidad y un profundo conocimiento, así que es fácil encontrarte con muchos Product Owners que no cumplen con todos los requisitos que se piden a este fundamental rol de Scrum.
Y por desgracia, es demasiado común encontrarte Product Owners reciclados a partir de puestos de negocio que no saben, o no quieren saber, y que pueden convertir tu proyecto en un auténtico desastre.
En este post analizaremos esta aciaga figura: la del mal Product Owner.
Cómo priorizar el Product Backlog
Una de las principales obligaciones del Product Owner es la de priorizar el Product Backlog.
Esto es especialmente importante ya que, de no hacerlo, no podríamos generar valor de forma iterativa e incremental tal y como dicta Scrum. Solamente priorizando podrás ir poniendo en producción de lo más importante a lo más secundario.
Recuerda que en agilidad debe existir una entrega de valor continua al cliente. Y evidentemente ¿qué le entregarás antes, funcionalidades con verdadero valor de negocio, o aquellas de relleno?
En este post analizaremos esta importante y delicada tarea.
La Deuda Técnica
Una cuestión que todo Equipo Scrum deberá tener muy presente a lo largo de los Sprints es cómo abordar la deuda técnica que vaya surgiendo, a veces inevitablemente.
Es muy importante reflejarla en el Backlog ya que te permitirá obtener información muy valiosa respecto a tu productividad. Pero, sobre todo, debes minimizarla en la medida de lo posible.
En este post desmenuzaremos este peligro que acecha a nuestros proyectos continuamente. Saber identificarlo ayudará, en parte, a evitarlo.
Vamos a ello.