Estoy trabajando en una tienda similar. Como otros han señalado aquí, lo que describe puede ser ágil pero no scrum. También agregaría que si los registros y sprints posteriores tienen sentido o no depende de si se trata de un nuevo trabajo o mantenimiento y soporte continuo. Si es lo primero, entonces un enfoque en cascada tendría más sentido para un equipo de una sola persona. Si no, desde una perspectiva de PM, lo que están haciendo parece un buen enfoque si tienen múltiples proyectos en su cartera.
Para los entusiastas de Agile, la mera mención de usar cascada es un sacrilegio. Pero las personas necesitan usar el sentido común.
Permítanme dar un ejemplo de un proyecto mío reciente. Lideraba un equipo de 3 desarrolladores en un cronograma agresivo de 5 meses para rediseñar dos sitios web principales. Tuvimos reuniones diarias de pie. Pero fue un proyecto en cascada porque era un equipo pequeño, un ciclo de vida limitado, y los desarrolladores eran contratistas a corto plazo comprometidos con el proyecto solo hasta el lanzamiento. El proyecto siguió un ciclo de vida en cascada muy tradicional. Absolutamente nada de malo en eso. Excepto que trabajamos de manera "ágil", mantuvimos las reuniones de pie y mantuvimos las mejores prácticas de desarrollo ágil. Nuestro pequeño equipo estaba exento de las reuniones semanales de planificación de sprints del equipo más grande. ¿Por qué? Porque no tuvimos implementaciones semanales. Y nuestro equipo no dependió ni influyó en el trabajo realizado por ningún otro equipo. De hecho, trabajamos casi de manera autónoma. Después del lanzamiento de los sitios web, pasamos a un proceso ágil para el mantenimiento y soporte continuo. Los otros desarrolladores ahora están trabajando en otro lugar. Todas las mejoras se planifican según implementaciones periódicas.
El punto es que es mejor usar los procesos que tengan más sentido para el tamaño, la complejidad y la madurez de cada proyecto. Si está investigando mucho, entonces es difícil hacer una estimación para los próximos cinco meses, por lo que ágil es probablemente un mejor enfoque que la cascada.
Parte del problema es que algunas personas parecen pensar que puedes planificar los próximos cinco sprints con anticipación. Ese ha sido el caso conmigo antes. No deberías estar planeando más de dos sprints porque si lo estás, estás derrotando el propósito de tener sprints. Se supone que un sprint es un compromiso para ofrecer una cantidad realista de mejoras dentro de un período de tiempo determinado. No debes comprometerte con algo de lo que no estás seguro. La planificación de Sprint es, por naturaleza, una planificación a corto plazo, pero ese es el punto. Si tiene un cronograma a largo plazo, piense en dividir las cosas en entregas más pequeñas. O configurar reuniones de punto de control en función de dónde se encuentre en el SDLC.
Se supone que la planificación de Sprint es un compromiso realista sobre lo que se garantiza que se completará dentro de un cierto período de tiempo. Si encuentra que la planificación no tiene en cuenta variables desconocidas, tal vez debería comenzar a dar rangos o estimaciones pesimistas. O como otro sugirió, use puntos de la historia. Los sprints tampoco deben reservarse por completo para permitir el deslizamiento y otras tareas importantes que surjan.