SCRUM es un marco de trabajo (Framework) para el desarrollo Ágil de productos software que ha ganado gran popularidad a nivel mundial gracias a su sencillez, adaptabilidad y su orientación a la creación de valor en cada incremento. Scrum es fácil de entender, pero a menudo difícil de implementar. Las empresas que tratan implementar el marco de trabajo Scrum a menudo cometen errores sobre cómo deben llevarse a cabo ciertas actividades, a estos errores los llamaremos "Malas Prácticas" de ahora en adelante. En el presente artículo, he enumerado varias malas prácticas cometidas en cada uno de los elementos de Scrum. Por supuesto, a nadie le gusta cometer errores, pero esto es parte del proceso de aprendizaje y la mejora continua.

1. El Marco de Trabajo Scrum
Scrum Bad Practices
Nombre: Boris D…
Correo-e: boris.java@gmail.com
Abstract. SCRUM es un marco de trabajo (Framework) para el desarrollo Ágil de productos software
que ha ganado gran popularidad a nivel mundial gracias a su sencillez, adaptabilidad y su orientación
a la creación de valor en cada incremento. Scrum es fácil de entender, pero a menudo difícil de
implementar. Las empresas que tratan implementar el marco de trabajo Scrum a menudo cometen
errores sobre cómo deben llevarse a cabo ciertas actividades, a estos errores los llamaremos "Malas
Prácticas" de ahora en adelante. En el presente artículo, he enumerado varias malas prácticas
cometidas en cada uno de los elementos de Scrum. Por supuesto, a nadie le gusta cometer errores, pero
esto es parte del proceso de aprendizaje y la mejora continua.
1 Introducción
Scrum en un principio fue creado y utilizado en el
ámbito industrial, su aplicación al desarrollo de
software tiene su origen en un estudio de 1986 sobre
los nuevos procesos de desarrollo utilizados en
productos exitosos en Japón y los Estados Unidos
(cámaras de fotos de Canon, fotocopiadoras de Xerox,
automóviles de Honda, ordenadores de HP y otros).
Scrum no es un proceso o una técnica para construir
productos; en realidad es un marco de trabajo iterativo
e incremental para el desarrollo de proyectos con
requerimientos cambiantes; se estructura en ciclos de
trabajo llamados Sprints, en los cuales se entrega un
incremento tangible del producto.
Scrum nos permite inspeccionar el software a medida
que se está construyendo, esto ayuda a establecer las
prioridades y ayudar a los equipos a focalizarse en
desarrollar aquellos requerimientos de más valor para
el negocio en el menor tiempo.
Fig 1. Componentes de Scrum
Scrum tiene los siguientes componentes:
Scrum Team:
 Product Owner
 Scrum Master
 Development Team
Scrum Events:
 Sprint Planning Meeting
 Daily Scrum Meeting
 Sprint Review Meeting
 Sprint Retrospective Meeting
Scrum Artifacts:
 Product Backlog
 Sprint Backlog
 The Increment
Cada componente dentro del marco de trabajo sirve a
un propósito específico y es esencial para la aplicación
exitosa de Scrum.
Las estrategias específicas para usar el marco de
trabajo Scrum son diversas, por ende es raro que dos
empresas diferentes lo adopten en la misma manera.
Sin embargo, existen ciertas “Malas Prácticas” que son
frecuentes cuando se utiliza este marco de trabajo.
Estas “Malas Prácticas” no todas las veces tienen
como causa el factor humano, algunas veces pueden
ser combinación de factores externos, etc. En este
artículo no se busca encontrar culpables, ni tampoco
defender a Scrum, simplemente desde mi experiencia
hare notar aquellas “Malas Prácticas” que se dieron
dentro de los diferentes componentes de Scrum y
proponer algunas soluciones para las mismas.

2. 2
2 Scrum Team
En esta sección se presentan las diversas “Malas
Prácticas” encontradas en los diferentes miembros del
“Scrum Team”.
2.1 Product Owner
2.1.1 El Ignorante. El “Product Owner” debe conocer
el Producto y gestionar el “Product Backlog”. Existen
situaciones en las que el producto es demasiado grande
o complejo, tanto así que pocas personas conocen
cómo se interrelacionan los diversos módulos del
sistema. Sin embargo, esto no debería ser una excusa
ya que el “Product Owner” debería ser una de esas
pocas personas. Es más debería preocuparse por
investigar cómo está organizado el sistema y tener un
“Big Picture” para tener claro cuál es el objetivo del
producto, hacia dónde debe ir el proyecto.
2.1.2 El Ciego. Cuando el “Product Owner” no tiene
la habilidad para ver qué requisitos le dan valor al
negocio. Esto puede observarse cuando comete
bastantes errores a la hora de priorizar las historias de
usuario. Recuerdo que varias veces, a mitad del Sprint
se le ocurría cambiar las prioridades de las historias de
usuario, de manera que el “Development Team” tenía
que parar máquinas por unas horas hasta confirmar la
decisión del “Product Owner”, una vez confirmada la
mala noticia el “Development Team” tenía medio
Sprint para concluir las nuevas historias de usuario por
tener más prioridad. Como se imaginaran en caso de
no terminar a tiempo la reputación del “Development
Team” quedaba afectada (las gráficas mostraban que
ese team no terminaba sus historias de usuario
comprometidas). Para este punto la única solución que
me viene a la mente es saltar por encima del “Product
Owner” y preguntarle directamente al cliente que es lo
que cree que tenga mayor prioridad.
2.1.3 El Colibrí. Este tipo de “Product Owner” se
aparece por un instante en la sala de reuniones, sueltan
una idea, tienen una conversación corta y se van
volando (es bastante raro ver a un colibrí ya que este
se queda encima de una flor por un lapso corto de
tiempo). En estos casos es normal que surjan dudas
durante la fase de desarrollo, y cuando “Development
Team” intenta contactar al “Product Owner” éste no se
encuentra en la oficina, o bien está ocupado en otras
reuniones o en el peor de los casos se fue de
vacaciones.
Un “Product Owner” que está demasiado ocupado
puede llevar al equipo por el camino equivocado
porque simplemente no tuvo tiempo de explicar su
postura. Esto puede llevar a grandes problemas en el
futuro. Y aunque el “Product Owner” podría haber
incluido más detalles en el “Acceptance Criteria”, eso
tampoco garantiza que el “Development Team” pueda
entregar exactamente lo que el “Product Owner” tiene
en mente. Es importante que el “Product Owner”
aprenda a disponer mejor su tiempo y se dé cuenta que
tiene que dar más soporte al “Development Team”.
2.1.4 El Solitario. Muchas veces antes del “Sprint
Planning Meeting” el “Product Owner” escribe las
historias de usuario por sí mismo, así como el
“Acceptance Criteria”. Incluso he visto casos en los
que el “Product Owner” por iniciativa propia se
encarga del UI/UX de determinado feature, no digo
que este mal, pero debería consultar antes a algún
experto del área. Según la especificación de Scrum las
historias de usuario deben ser el resultado de la
conversación entre el “Product Owner”, el
“Stakeholder” y el “Development Team”; sin esa
conversación, una historia de usuario es poco más que
otro documento de requisitos, tal como se hacía en las
metodologías tradicionales.
2.1.5 El Pesimista. El “Product Owner” cree que el
“Development Team” puede implementar cualquier
requerimiento trabajando horas extras e incluso los
fines de semana.
Es probable que durante el Sprint el “Product Owner”
y el Stakeholder hayan tenido varias conversaciones y
que el “Product Owner” sienta la necesidad de tener
“más funciones". Muchos podemos caer en la trampa
de que ofrecer un mayor número de funciones es la
mejor manera de alcanzar nuestras metas. Pero la
realidad es que la mayoría de los usuarios finales solo
utilizan un conjunto muy pequeño de características
(por ejemplo pocos utilizan Microsoft Word al 100%).
El “Product Owner” debe comprender que incluir más
funciones al sistema conduce inevitablemente a
grandes retrasos y presión sobre el “Development
Team”, lo cual gradualmente resultará en incrementos
de software con menor calidad.
2.2 Scrum Master
2.2.1 El Falso Project Manager. Mucha gente asocia
instantáneamente que el “Scrum Master” es un
Director de Proyecto, un Project Manager, un Jefe de
Proyecto… pero la idea no es esa. El papel del “Scrum
Master” es un papel de apoyo, algunos lo traducen
como facilitador. Suele ser una persona con
experiencia en el uso de Scrum y ayuda a aplicarlo de
la forma más adecuada.
El problema ocurre cuando el “Scrum Master” cree
que es está a cargo de algunas funciones
administrativas, es bueno que alguien le recuerde cuál
es su papel en la organización.
2.2.2 El Dogmático. Algunos “Scrum Master” creen
que deben aplicar el “Scrum Guide” al pie de la letra,
lo cual inevitablemente puede causar molestias al resto
del equipo de trabajo provocando fricciones y un mal
ambiente laboral.
Como bien saben los extremos nunca son buenos en
ninguna situación, es la obligación del “Scrum
Master” encontrar un punto de equilibrio y no ser
demasiado estricto con el “Product Owner” y el
“Development Team” de manera que pueda
implementar Scrum de manera ágil en la organización.

3. 2.2.3 El Tirano. En el pasado el Jefe de Proyecto creía
que tenía todo el poder (por supuesto había jefes
buenos), era un tirano que todo lo sabía y que
orquestaba el proceso mediante preciosos Diagramas
de Gantt que casi nunca se cumplían.
Cuando el cliente tenía un problema, ahí estaba el Jefe
de Proyecto para aplicar castigo administrativo al
equipo. Los tiempos cambiaron, pero en ocasiones el
“Scrum Master” puede ser bastante irritante para el
“Development Team”, esto se ven en bugs de
producción críticos o en el desarrollo de nuevas
funcionalidades que deben terminarse lo más pronto
posible, es clásico escuchar: “Cuánto te falta? ¿Cómo
vas? ¿Ya está listo?”. Creen que al repetirlo muchas
veces el software se desarrollara más rápido, pero la
realidad es que un desarrollador irritado es menos
productivo. Es bueno que el “Scrum Master” recuerde
que los consejos son bienvenidos pero que no ordena.
2.2.4 El Mayordomo. El “Scrum Master” se encarga
de dar soporte al “Product Owner” y de gestionar los
impedimentos. Es probable que en algunos casos el
“Scrum Master” crea que su función principal es la de
facilitar la vida a los demás. Por tanto será el que
agenda las reuniones de los eventos de Scrum, toma
notas y realiza actas cuál secretario. También es el que
todos los días recuerda infructuosamente las buenas
prácticas de Scrum (como las secretarias que le dicen
a sus jefes la agenda del día). Es el que mira logs o
código de un issue critico muy urgente que no atiende
nadie. Es el que se encarga de recoger los post-it,
limpiar la pizarra o actualizar tableros (por poco y
barrer la sala de reuniones).
El “Scrum Master” debe recordar que en Scrum el
“Development Team” es auto organizado, por ende no
necesita rebajarse al nivel de un mayordomo y
facilitarles tanto la vida.
2.2.5 El Controlador. Si el “Scrum Master” enfoca
parte de su trabajo en producir una actualización diaria
del burn-down chart. Si el equipo considera útil tener
un burn-down chart y el “Scrum Master” acepta
actualizarlo, que así sea. Sin embargo, sigo creyendo
que un “Sprint Board” actualmente cumple el mismo
propósito de un simple vistazo sin agregar una nueva
capa administrativa.
Por otra parte hay situaciones en las que se da una
lucha de poderes entre el “Scrum Master” y el “Team
Leader”, y créanme no hay nada peor para el
“Development Team” que tener dos jefes preguntando
por el avance del proyecto.
Si están bien definidos los roles, no debería haber
conflictos ni choques entre las funciones del “Scrum
Master” y el “Team Leader”. El “Team Leader” es la
parte crítica y puramente técnica dentro del proyecto,
algunas veces puede encargarse de la interacción con
personas externas al proyecto. Es bueno que el “Scrum
Master” sea proactivo e intente ayudar, pero seamos
realistas, sus conocimientos técnicos son limitados.
2.3 Development Team
2.3.1 El Equipo Dependiente. En teoría el
“Development Team” debe ser auto organizado, ellos
deben decidir cómo convertir elementos del “Product
Backlog” en Incrementos de funcionalidad. Lo más
probable es que el “Development Team” tenga
demasiadas dependencias y poca libertad de decisión
en cuanto al producto. Esto puede darse tanto a nivel
de implementación y decidir que tecnologías utilizar
para un determinado proyecto o bien tener que esperar
que otro Team termine sus tareas antes de comenzar
con las tareas de desarrollo. Muchas veces no hay
manera de cambiar esta dependencia, sobre todo para
productos bastante grandes y con código existente. En
esos casos resulta casi imposible cambiar de
tecnología, y en cuanto a los cuellos de botella no
queda otra opción más que esperar que el otro Team
termine con su trabajo.
2.3.2 El Equipo Grande. Según la especificación de
Scrum, el tamaño óptimo del “Development Team”
debe ser entre tres y nueve integrantes. Tener más de
nueve miembros en el equipo requiere demasiada
coordinación y generan demasiada complejidad como
para que pueda gestionarse mediante un proceso
empírico. Cuando el equipo es grande, los eventos de
Scrum se vuelven bastante tediosos, por ejemplo
resultaría casi imposible terminar un “Daily Scrum
Meeting” en 15 minutos, recuerdo que una vez incluso
llegamos a estar una hora discutiendo sobre un tema
sin importancia.
El año 2003, Jeff Sutherland recomendaba que el
tamaño del “Development Team” sea menor a siete
integrantes, la guía de Scrum recomienda que el
“Development Team” debe ser lo suficientemente
pequeño como para permanecer ágil y lo
suficientemente grande como para completar una
cantidad de trabajo significativa. Tener menos de tres
miembros en el “Development Team” reduce la
interacción y resulta en ganancias de productividad
más pequeñas. Se considera que un “Development
Team” pequeño tendrá limitaciones en cuanto a las
habilidades necesarias durante un Sprint, haciendo que
no sea capaz de entregar un Incremento al finalizar el
Sprint.
2.3.3 El Equipo Omnipotente. El “Development
Team” además de ser auto organizado, es
multifuncional, es decir que poseen todas las
habilidades necesarias para crear un Incremento de
producto. Mientras más tiempo se conozca un
producto, es probable que las tareas de desarrollo
tomen menos tiempo y que el equipo se sienta
confiado y creer que pueden hacerlo todo. Para
demostrarlo van agregando más historias de usuario al
“Sprint Backlog”, incluso puede que terminen varios
Sprint de manera exitosa. Pero esta buena iniciativa
puede tener un impacto negativo a futuro, es probable
que con el tiempo se cansen o bien que los nuevos
features tengan mayor complejidad, y en los reportes
se verá una velocidad de desarrollo en descenso.

4. 4
3 Scrum Events
En esta sección se presentan las diversas “Malas
Prácticas” encontradas en los meetings de Scrum.
3.1 Sprint Planning Meeting
3.1.1 La Carrera Sin Sentido. Es bien sabido que
durante el “Sprint Planning Meeting” se decidirá que
historias de usuario serán trabajadas durante el Sprint;
cuando se tienen varios “Development Team” algunos
se sientan motivados a competir. Es entonces cuando
un “Development Team” en particular quiere
demostrar que pueden producir una gran cantidad, y es
cuando caen en esta trampa. Otra situación parecida,
se da cuando tenemos un “Product Owner”
entusiasmado que intenta satisfacer cada solicitud
individual de los Stakeholders del proyecto y el
“Development Team” establece expectativas poco
realistas al comprometerse excesivamente con un
“Product Owner” demasiado entusiasmado.
Para no llegar a esta situación los “Product Owner”
deben aprender a decir NO a los Stakeholders del
proyecto cuando sea necesario. En cuanto al
“Development Team” antes de lanzarse a una carrera
sin sentido se les recomienda analizar los Burndown y
Velocity charts de anteriores Sprint para estimar
correctamente la capacidad de desarrollo del equipo.
3.1.2 El Falso Sprint Goal. A pesar de que la
especificación de Scrum establece la importancia de
tener un “Sprint Goal”, como resultado del “Sprint
Planning Meeting” muchos equipos se plantean un
falso “Sprint Goal”: “Completar todas las historias de
usuario comprometidas”.
El “Sprint Goal” proporciona orientación sobre qué se
necesita en el incremento, y es un objetivo que hace
que el “Development Team” pueda trabajar con cierta
sinergia. Un buen ejemplo de “Sprint Goal” podría
tener este aspecto: “Implementar la funcionalidad del
feature X para que la empresa Y obtenga beneficios
económicos de la venta de sus productos”.
3.1.3 Perdidos en el Espacio. Durante el “Sprint
Planning Meeting” el “Developmet Team” tiene la
responsabilidad de decidir la cantidad de trabajo que
considera factible para completarse durante el Sprint.
El “Product Owner” no puede y no debe dictar la
cantidad de historias de usuario que deben
completarse, en cambio el “Development Team” tiene
que auto-organizarse en base al “Sprint Backlog”,
conocer la disponibilidad y capacidad de los miembros
del equipo. Esto significa que el “Development Team”
debe ir preparado al “Sprint Planning Meeting”
habiendo leído y analizado previamente las historias
de usuario a ser tratadas. Seamos realistas, gracias a
Scrum el “Development Team” asiste a muchas
reuniones y además tiene muchas otras tareas a parte
de las comprometidas para el Sprint, en consecuencia
casi nadie revisa a profundidad las historias de usuario
antes de ir al “Sprint Planning Meeting”.
Para afrontar este problema es necesario que el “Scrum
Master” realice algunos cambios en el calendario de
manera que pueda reducir el número de reuniones e
incluso crear un espacio libre de tareas para que el
“Development Team” pueda prepararse y revisar con
cuidado las nuevas historias de usuario antes del
“Sprint Planning Meeting”; de lo contrario, caeremos
de nuevo en una reunión larga e improductiva.
3.2 Daily Scrum Meeting
3.2.1 El noticiero. En el “Daily Scrum Meeting”,
básicamente cada miembro del “Development Team”
debe responder brevemente a 3 preguntas:
 ¿En qué he trabajado desde el último “Daily
Scrum Meeting” hasta ahora?
 ¿En qué trabajaré para el próximo “Daily
Scrum Meeting”?
 ¿Hay algún impedimento para continuar el
trabajo?
Con el tiempo el “Daily Scrum Meeting” se convirtió
en una reunión de informe de hechos (noticiero), y los
miembros del “Development Team” esperan su turno
para poder "informar" estos hechos al “Scrum
Master”, al “Product Owner” o tal vez incluso a un
“Stake Holder”. Es en este punto donde el “Daily
Scrum Meeting” pierde su valor y se convierte en una
reunión poco interactiva en la cual todos de manera
mecánica responden las tres preguntas mencionadas
previamente, en resumen una pérdida de tiempo.
El proposito del “Daily Scrum Meeting” es que el
“Development Team” sea capaz de determinar qué es
lo que tienen que hacer ese día para lograr completar
el Sprint, y resaltar los impedimentos encontrados.
3.2.2 La Reunión Técnica. Hay ocasiones en las
cuales durante el “Daily Scrum Meeting”, los asuntos
se tratados llegan a un nivel muy bajo de detalles
técnicos, que probablemente no serán interesantes o
útiles para todos.
En estas situaciones es recomendable que al final de la
reunión, se reúnan las partes interesadas para hablar de
detalles netamente técnicos o bien durante la reunión
decir: "El issue A se puede resolver usando B, y yo
puedo ayudarte luego"
3.2.3 El Muro de los Lamentos. Dentro del
“Development Team” hay personas que por alguna
razón les gusta esperar hasta el próximo “Daily Scrum
Meeting” para notificar que tiene uno o más
problemas, por otro lado están aquellos que creen que
el “Daily Scrum Meeting” es un “Sprint Retrospective
Meeting” y empiezan a quejarse por diferentes
razones. Si encuentras un problema técnico, puedes
pedir ayuda a cualquier miembro del “Development
Team”, no hay razones para temer, nadie nació
sabiendo todo. Por otro lado, si tienes una queja
respecto a alguna persona, proceso, herramientas, etc,
recomiendo que esperes el próximo “Sprint
Retrospective Meeting”.

5. 3.3 Sprint Review Meeting
3.3.1 El Equipo Yo-Yo. El objetivo del “Sprint
Review Meeting” es mostrar al “Product Owner” y a
los “Stakeholders” que fue lo que el “Development
Team” desarrolló durante el Sprint. En algunas
ocasiones el “Development Team” invierte una gran
cantidad de esfuerzo para completar el Sprint, y es
cuando deciden mostrar una lista de lo que hizo cada
miembro del “Development Team”, cuánto tiempo
dedicó a eso y cómo lo hizo. Estos detalles técnicos no
son valiosos para los “Stakeholders” y eso puede llegar
a ser bastante frustrante para los miembros del
“Development Team”.
Sin embargo, en lugar de realizar una “exposición” de
detalles técnicos a los “Stakeholders”, el
“Development Team” debe demostrar el valor que
posee el Incremento a ser presentado, debe mostrar
cómo funcionan los nuevos features, qué mejoras
realizó el equipo y preguntar a los “Stakeholders” por
sus comentarios (feedback).
3.3.2 La Pizza sin Queso. Los “Stakeholders” asisten
al “Sprint Review Meeting” con muchas ansias y
ciertas expectativas en el producto que está siendo
desarrollado por el “Development Team”, entonces
pueden imaginar la frustración que sienten al saber que
las historias de usuario comprometidas no están
terminadas (es como tener un gran antojo por comer
una pizza y que el mesero te traiga una sin queso).
El producto pierde valor para los “Stakeholders” cada
vez que se muestran features que están casi terminados
y la confianza en el “Development Team” también se
ve afectada, lo más probable es que estos features
tengan que mostrarse nuevamente durante el próximo
“Sprint Review Meeting”. Se recomienda que el
“Development Team” explique con anticipación el por
qué no pudieron terminar las historias de usuario
comprometidas, esto no es para culpar al
“Development Team”, sino que se trata de compartir
información valiosa que podría llevar a acciones
futuras que mejoren el proceso de desarrollo.
3.3.3 La Bomba de Tiempo. Todos hemos pasado por
la vergüenza de ver fallar nuestro producto en pleno
“Sprint Review Meeting”, lo cierto es que muchas
veces el producto se convierte en una bomba de tiempo
que por algún mágico motivo decide estallar justo el
momento de la presentación. Algunos creen que la
causa principal es entrar al “Sprint Review Meeting”
sin estar preparado, otros indican que no se hizo un
buen Test del producto, otros creen que el producto es
inestable lo cual de ser cierto dañaría la reputación del
“Development Team”. Lo cierto es que pueden haber
diferentes razones, esperando no encontrarnos en la
última situación, la única solución parcial y preventiva
es que el “Development Team” se prepare antes del
“Sprint Review Meeting” de manera que cuando
muestren el Incremento a los “Stakeholders”, puedan
estar orgullosos del trabajo que hicieron y fortalezcan
su relación de confianza.
3.4 Sprint Retrospective Meeting
3.4.1 Los Procrastinadores. El “Sprint Retrospective
Meeting” ocurre inmediatamente después del “Sprint
Review Meeting” y poco antes del próximo “Sprint
Planning Meeting”. Incluso un “Scrum Master”
experimentado cae en la tentación de posponerlo para
el siguiente Sprint. Más allá de la tarea de
"inspeccionar” y “adaptar", el “Sprint Retrospective
Meeting” también servirá como un momento de cierre
del actual Sprint y un momento de desahogo para el
“Development Team”, de manera que pueda centrarse
en el nuevo Sprint.
Posponer el “Sprint Retrospective Meeting” al
siguiente Sprint puede interrumpir el flujo de trabajo
del “Development Team”. Por ejemplo si durante el
Sprint se identificaron los cuellos de botella del
proceso de desarrollo, el “Development Team” tendra
que seguir batallando con ellos por otro Sprint. Un
equipo estresado no trabaja eficientemente y por ende
la calidad del producto se puede ver afectada.
3.4.2 Lo que el Viento se Llevó. El “Sprint
Retrospective Meeting” es una oportunidad para el
“Scrum Team” de inspeccionarse a sí mismo y
elaborar un plan de mejoras que en lo posible deberán
ser abordadas durante el siguiente Sprint. Algunas
veces por falta de tiempo o por no contar con las
herramientas adecuadas muchas opiniones se
quedaran en la sala de reuniones, y desaparecerán de
las mentes de los asistentes.
Es por ello que durante el “Sprint Retrospective
Meeting”, el “Scrum Team” debe tomarse las cosas en
serio y tomar notas de manera detallada, o inclusive
sacar fotos o grabar la sesión; todo esto con el fin de
no perder ninguna de las opiniones emitidas durante la
reunión.
4 Scrum Artifacts
En esta sección se detallan algunas de las malas
prácticas encontradas en los “Scrum Artifacts”.
4.1 Product Backlog
4.1.1 El Buzón de Papa Noel. Nos encontramos en
esta situación cuando tenemos un “Product Backlog”
demasiado repleto. El “Product Backlog” debe tener
una dimensión determinada, no debe convertirse en
una lista infinita de requerimientos. Esto para que al
final pueda gestionarse como un proyecto predictivo
mediante la construcción de prototipos.
Es verdad que Scrum nos ayuda bastante cuando los
requerimientos poseen cierta incertidumbre por lo que
no podemos saber todo a priori. Habrán cosas que
averiguaremos por el camino, es por eso que hay que
ir poco a poco, y no con todo de golpe. Esto no quita
la posibilidad de tener otras listas de requerimientos
independientes del “Product Backlog”, las cuales a
futuro se pueden ir agregando al “Product Backlog”.

6. 6
4.1.2 El Baúl de los Recuerdos. El refinamiento del
“Product Backlog” es el acto mediante el cual el
“Product Owner” y el “Development Team” colaboran
con el fin de añadir detalles, estimaciones y orden a los
elementos del “Product Backlog”. El “Product Owner”
puede modificar los elementos del “Product Backlog”
en cualquier momento; el “Product Owner” decide en
base a conversaciones con los “Stakeholders” que
historias de usuario tienen mayor prioridad y cuales
tienen menor prioridad, con el tiempo las historias de
usuario de baja prioridad quedan dispersas a lo largo
del “Product Backlog”. Es común que el “Product
Owner” se cambie de vez en cuando, por lo tanto estas
historias de usuarios quedan en el olvido creándose de
esta manera “El baúl de los recuerdos” dentro del
“Product Backlog”, alguna vez sentí curiosidad por ver
todas las historias de usuario relacionadas con una
parte del producto y me lleve una gran sorpresa al
encontrar una gran cantidad de historias de usuario
antiguas, nuevas y otras que jamás se implementaran
por diferentes razones. Como se mencionó en el
anterior punto es importante que el “Product Backlog”
tenga una dimensión determinada y cuente con una
lista finita de elementos, es por ello que recomiendo
realizar una limpieza del “Product Backlog” por lo
menos dos veces al año.
4.2 Sprint Backlog
4.2.1 Construyendo una Pirámide. En ciertas
ocasiones el “Scrum Master” alienta deliberadamente
al “Development Team” a sobrecargar el “Sprint
Backlog”, creyendo que esto hará que el equipo se
"estire" y mejore su velocidad de desarrollo. Rara vez
esta estrategia tiene éxito, lo cierto es que esta
sobrecarga hace que los equipos sean menos
productivos y que la calidad del producto se vea
afectada.
Los buenos equipos deportivos desarrollan con el
tiempo un "hábito de ganar", por otro lado los buenos
“Scrum Team” desarrollan un "hábito de completar" el
Sprint. Este hábito tendrá problemas para desarrollarse
si el “Development Team” se enfrenta a un Sprint que
está sobrecargado.
4.2.2 Ladrones en la Noche. El “Sprint Backlog” es
una predicción hecha por el “Development Team”
acerca de qué funcionalidad formará parte del próximo
Incremento y del trabajo necesario para entregar esa
funcionalidad en un Incremento “Done”. Sin embargo,
muchas veces realizamos esta predicción sin tomar en
cuenta que durante el Sprint pueden aparecer los
famosos “Production Bugs”. Estos bugs son en
realidad ladrones de recursos, debido a que
generalmente estos bugs tienen mayor prioridad que
las historias de usuario comprometidas y deben ser
trabajados inmediatamente. Ante esta situación, el
“Development Team” debería reservar un porcentaje
de tiempo fijo para trabajar en estos errores durante el
Sprint, de esta manera se reduce el riesgo de llegar al
final del Sprint con las manos vacías.
4.3 The Increment
4.3.1 El Suicidio. Muchos “Scrum Team” definen que
para que se dé un Incremento se debe satisfacer una
condición de “Done”. Cada “Scrum Team” debe tener
un entendimiento compartido de lo que significa que
el trabajo esté terminado (“Done”). Cada Incremento
se integra con todos los Incrementos anteriores y es
probado exhaustivamente, asegurando que todos los
Incrementos funcionan en conjunto.
A medida que los “Scrum Team” maduran, la
definición de “Done” se amplía para incluir criterios
más rigurosos buscando una mayor calidad, es en este
punto donde muchos “Scrum Team” pueden cometer
el error de ponerse la soga al cuello. Por ejemplo, en
un proyecto Angular en el que estuve trabajando la
definición de “Done” era la siguiente: New Branch +
Clean angular code + Jasmine Unit Tests + Protractor
Tests + Code Review + Merge Branch + QA
Validation + “Product Owner” Approval
Créanme que por cambiar el texto de un simple botón
tenías que pasar por toda esta burocracia, imagínense
que QA encuentre un bug, se debe crear un nuevo
branch para arreglar dicho bug y pasar por todos los
pasos mencionados. Tal como imaginaran esto generó
continuos retrasos en el “Development Team” ya que
un cambio en el requerimiento suponía cambios en
cada uno de los criterios previamente mencionados.
5 Conclusiones
Scrum es un marco de trabajo fácil de entender, pero
difícil de implementar. Es normal que cuando una
empresa intente utilizar este marco de trabajo cometa
una o varias de las malas prácticas mencionadas
anteriormente.
Este artículo no pretende definir soluciones para cada
una de esas malas prácticas, en lugar de eso es una
pequeña enciclopedia de malas prácticas fruto de mi
experiencia laboral. El objetivo es que logren
reconocer si están cometiendo alguna de estas malas
prácticas y apliquen mi consejo o bien encuentren una
solución que se adapte a sus necesidades.
No deben frustrarse si cometieron alguna mala
práctica, deben recordar que la agilidad implica
experimentación, cuestionamiento y un constante
aprendizaje.
Apéndice I
En este caso, todo el artículo fue elaborado en base a
mi experiencia laboral, y como mencione en un
principio no pretende ser una introducción a Scrum.
Agradecimientos
Agradecimientos a Jeff Sutherland y Ken Schwaber.

7. Referencias
[1] Andre Stellman & Jennifer Greene. Learning
Agile. (November 2014)
[2] Diego Martín Alaimo. Proyectos ágiles con
Scrum: flexibilidad, aprendizaje, innovación y
colaboración en contextos complejos. (October
2013)
[3] Henrik Kniberg. Scrum and XP from the
Trenches. (August 2007)
[4] https://www.scrum.org/resources/scrum-guide
[5] https://scrumguides.org/
[6] https://www.scrumalliance.org/learn-about-
scrum/the-scrum-guide