You can have fixed time and variable scope, or variable time and fixed scope, but a product owner can’t pick both.

Lately, I’ve heard this quote several times.  At first, it makes sense. A product owner/stakeholder can either tell the team the requirements, and the team can then define the schedule.  Or the product owner can define a schedule, and the team will control how much can get done during that block of time.

This makes sense at first, but over the last few days I’ve had a “light-bulb” aha! moment regarding this.  And to be honest, it seems a little controversial. Ready? Here goes:

In a true agile, sprint-based effort, there’s no long term schedule developed at all.

Although this seems crazy, it can work in the right environment.  What it really takes is, the stakeholder/product owner has to really trust the development team, and trust that they are doing the best that they can and are working as fast as they can (but not faster, because that just introduces sloppiness and bugs).

The anecdotal evidence is that, in such a model, the product that is released will be more closely aligned with what the users really need (because of the continuous delivery and rapid adjustments and iterations towards the user’s constantly-changing requirements…this is called Boyd’s Law, and someday I’ll talk about it in more detail). If you were to compare the total time it takes to deliver with a traditional waterfall-based project, the agile model ends up delivering sooner, because in a waterfall model you end up doing a lot more rework because of requirements defects, emergent requirements, and changed scope.

So, in a “true” agile model, although the product owner doesn’t get a “final” delivery date, they have to trust that they are getting it faster than if they insisted upon a waterfall-ish requirements decomposition and schedule estimation.

Now, I believe that you can come up with high-level roadmaps if you really wanted to.  You can groom and analyze your backlog, decompose and effort estimate the user stories to a sprint level.  Then you can just count up the number of sprints, work in some slack for vacations and slippage (maybe 20% to 40%), and you can have a pretty good guesstimate for when feature sets will be released.  But to be honest, these milestone estimates are probably just as wrong as a waterfall-based estimate.

When you continue to evolve this strategic approach, you can see how it aligns with continuous integration, continuous delivery, and SaaS products.  Take webapps like Netflix, or Facebook, or Amazon. Are there version numbers? Releases? Not from the customer perspective. It’s not like you’re buying the upgrade from Excel 2010 to Excel 2013.  Instead, the CI/CD pipeline and development sprints mean that the user experience is just constantly improving, and the developers are easily able to rapidly integrate feedback into their design. Take it one step further, where the product ecosystem is separate microservices with separate teams, CI/CD pipelines, and sprints, and you end up with a wonderfully agile, flexible, responsive product line that delivers a great user experience.