Casos 2023
Caso 1
Un grupo de stakeholders está interrumpiendo constantemente al equipo, pidiendo directamente a los developers hacer desarrollos, esto hace que el equipo de Scrum no produzca a la velocidad a la que podría y el foco del equipo se ve disperso.
Caso 2
En un equipo de Scrum, los developers se reparten las user stories en lugar de repartirse tareas, esto hace que ningún developer conozca el trabajo de los demás developers (cada quién en su especialidad), causando dependencia de individuos y baja velocidad de producción de valor debido a un WIP demasiado alto (pérdida en el Foco).
Caso 3
El equipo de Scrum no logra (con mucha frecuencia) terminar el número de user stories seleccionadas durante el Sprint Planning, incluso usando patrones como el Yesterday Weather, amenudo “saltan” blockers durante el Sprint y esto hace que el equipo de Scrum no logre cumplir con sus compromisos.
Caso 4
Este equipo de Scrum es característico por tardarse varias horas en hacer el Sprint Planning, por lo general se les pide que estimen (planning poker) las historias de usuario. Al equipo ya se le lleva preparado el número de user stories que tienen que cumplir en el próximo Sprint.
Caso 5
Un Stakeholder muy alto jerárquicamente pide que los Sprint Reviews no duren más de media hora, por lo cual se procede a acortar los reviews, limitando la interacción que los otros stakeholders tienen durante el evento. Este stakeholder se mantiene tan ocupado que durante los últimos dos meses, no ha podido asistir al Sprint Review.
Caso 6
Un equipo de Scrum se caracteriza por no lograr terminar las User Stories a las cuales se comprometieron durante el Sprint Planning. Típicamente los QAs están holgados durante el Sprint y al finalizar el Sprint están llenos de trabajo por hacer. Frecuentemente los QAs regresan a última hora a los developers user stories con defectos, impidiendo que el equipo pueda presentar en el Scrum Review ese trabajo no completado.
Caso 7
Un equipo de Scrum tiene problemas constantes por que los ambientes no funcionan adecuadamente en el tiempo correcto. Esto los ha atrasado durante los últimos 5 Sprints.
Caso 8
Un equipo de Scrum desarrolla un producto en el cuál el OKR es la transaccionalidad (movimiento de dinero). El Product Owner no llega a cumplir el OKR deseado y los próximos cuatro Sprints están enfocados en aspectos de seguridad y estética del producto.
