Ending a sprint: a state of mind and discipline
Sticking to established sprint windows, whether 1, 2, 3 or 4 weeks in duration, is a state of mind that requires discipline. Things don’t always go to plan during a sprint. Elaboration of requirements, refinements to designs, organizational change, other external influences can result in the development team not getting through all the planned features for the sprint. Some features remain in the “To Do” or “Doing” columns at the end of the sprint window. To get through those remaining features requires more time.
The common inclination can be to extend the sprint window. “We need another week to get through the remaining features, let’s keep going”. The Sprint Review gets pushed back one week until the development team gets the remaining items in the “Done” column. But, is this the right thing to do? Extending sprints is a slippery slope. Where does it end? ‘90% Done’ syndrome that can plague waterfall projects starts materializing.
It’s better to stick to the established sprint window and bring closure to that work component. Even if it’s a foregone conclusion that all there is time and budget for is another week of development to get through the remaining items. It’s best to containerize that other week in its own sprint. This reinforces bringing finality to components of work and enables realization of early business benefits by releasing now what is ready to go versus holding on until the ‘last remaining components are completed’.
In practice, those ‘last remaining components’ can often not be the last. Again, elaboration of requirements, refinements to designs and organizational and external influences can impact the development of those remaining features and possibly newly requested features, which in turn can impact the schedule).
All the more reason to bring finality to components of work and to release those (if at all possible) to realize incremental business value. This is a state of mind that requires discipline.
