There is a popular notion in the Agile world that with continuous deployment and frequent shipping, dates should cease to matter. The next big feature should be ‘just’ one release of many.
But the Capabilities provided by the software system many times have dependencies on other capabilities. Here's an example of a health insurance provider network system. There is a minimum number of features needed to provide a single Capability that the business can put to work making money. Certainty continuous delivery of features is always a good idea. But the business is looking for capabilities not just features. The Capability to do something of value. This is the Value used - and many times misused - in Agile.
It's not about working software (which is necessary). It's about that working software being able to produce measurable value for the business. That can be revenue, services, operational processes. In the enterprise these Capabilities need to be delivered in the right order at the right time for the right cost for the business to meet it's business goals. Rarely are they Independent in practice.
To discover what capabilities are needed, here's one approach taken from our Capabilities Based Planning paradigm
Here's a more detailed process description.
This of course goes for the #Noestimates notion as well - ask those paying if they have no interest in knowing when those capabilities will be available and how much they will cost. You may get a different answer that the one provided by the developer, who does not own the money, the business accountability, or the balance sheet performance goals.
