When sprint planning was first proposed software development cycles were measured in quarters or years. In that environment getting together to plan once every few weeks made a lot of sense, as the environment the software lived in wouldn’t be likely to change in that time.
That’s just not the case anymore, especially for online platforms. Software is deployed in weeks, or in some shops hours.
Creating a development plan for a fast release cycle costs too much.
Sprint planning is a significant investment of time and energy. The meeting requires everyone to get together for at least an hour, usually more. In order to make that investment pay off you have to speed up delivered software development by at least as many man hours. The shorter the sprint, the worse this ratio gets, and your process overhead goes through the roof.
Plans are unlikely to survive, even if sprints are short.
Traditional agile process has been a victim of its own success. Software delivery speed has gone up, and customers are no longer willing to wait months for a fix or for critical features to be developed. This means that whatever plans you make are increasingly likely to be interrupted by business needs. “Blowing up a sprint” isn’t a big deal if it happens once every few months, but it’s now happening all the time.
A better way is needed
Instead of trying to decide what’s getting done all at once, planning needs to happen all the time. Instead of building a backlog, when a story is created it is directly assigned to a developer, and the entire team weighs in on whether it should be done. Developers in turn, only start stories that their team considers worthy. When a story is blocked, before work starts again it must be considered alongside the new tasks that have arrived.
In other words, there’s no such thing as ‘blowing up the plan” only a succession of stories that are worth working on right now.
Enabling such a process is one of the goals of Uclusion, and we hope you’ll give it a try.
Top comments (0)