While “agilefall” has many well documented downsides, I’ve found a counterintuitive bright side to the following aspect of it: “We have a product backlog with priorities, but we start working on a release with a long list of features already committed to the business.”
In this case, we have a pretty detailed view of scope as well as developer estimates of complexity. There is a lot of data to crunch.
From a pure business perspective, the key variable that matters is the release date. Dates have a significant implication for the rollout across the company and existing client base. Here’s a few business reasons why:
marketing and sales plans need to be made (since they’re separate “workstreams”)
overall costs and ROI of the program changes
coordination and resources need to be shared/reassigned with other internal teams
And most importantly, the date is completely non-technical. Anyone who graduated from primary school can understand it. So the nice thing is that the release dates help focus the discussion on what matters, while only needing to go into a minimal amount of technical detail.
Making the relatively liberal assumption that scope will not change, it’s possible to generate a pretty decent forecast of the date.
Moreover, it’s possible to model the impact of a higher or lower average future velocity on release dates. In other words, if there is a need for a plan, you can make the entire plan using the following approach:
dependent variables: incremental release dates
independent variable: hypothetical velocity
And then look at what happens to the release dates as you vary velocity.