Agile release planning can be either date-driven or scope-driven. The approach is mostly the same both ways. We estimate the product backlog, typically using story points for each backlog item, and then estimate or measure the team’s velocity in story points per sprint (for Scrum teams) to estimate either the date to deliver the scope, or the scope that fits within the date. Kanban teams may argue that estimates are waste – and in some cases they may be – but in some contexts a business needs to set clear expectations with customers, and estimating makes that possible.
The Snowball Effect
In traditional projects with long release cycles, projects tend to “snowball” out of control. No one can stand to have their feature deferred to the next release, because the next release is too far in the future. So feature creep happens. The release, snowball, on it’s way down the hill, begins to pick up more snow and debris as it rolls. At some point, it’s too big to manage and it’s going to roll a lot farther (in time) than you wanted it to. Date-driven release planning, with short timelines, is a great way to stop the snowball effect. I especially like frequent and periodic release schedules, such as quarterly releases. With this structure, think of each release as a bucket of limited size; the bucket will only hold so much work, and if you want to add more, you’ll have to take something out first. This forces a valuable conversation about priority. And because the next release is a few months away, instead of a year or more, it is much easier to defer features til the next release. You may even find (gasp!) that some of those features will ultimately not be important, and can be skipped altogether.
One of the 12 principles of the agile manifesto says “Simplicity – the art of maximizing the amount of work not done – is essential.” Use date-driven release planning to help avoid unnecessary work on your product or project.