DDD/CQRS/Event sourcing and Agile/Scrum - Is it so obvious?

I was sitting here and was creating a roadmap for a system that I am currently working on. Nothing special, but still, it's big eShop system with big backend system and has lot of integrations with 3rd party systems and has complex business rules and so on.
Anyway, now why I am writing this, is because I think that all who are reading about CQRS, Event sourcing, Agile, Scrum etc., should be interested in it. Perhaps all top guys like Greg Young, Udi Dahan and lot of others knows that, but I have tried to ask google and got zero results on what I am about to write.
Or perhaps it's so obvious that no one is writing about it? let's see

I will not go into details what is Scrum and Agile and CQRS and Event sourcing, I assume that you know what it is, and instead of that I will share my thoughts on how all these 'things' works together and what a great value it can bring to you.

So, first of all some preconditions:

• My team works in Scrum environment (we pass NOKIA test)
• We have applied CQRS architecture along with Event sourcing
• We use DDD
  

Now, as I was saying, because I am ScrumMaster, so I was helping our Product Owner to create a roadmap for our current project. We have a loads of work/features to implement and also there is a very big pressure from stakeholders to go live as soon as possible. There is along story why we need go live as soon as possible, but thing is that we must, otherwise business will suffer a lot. So puzzle is something like this:
- You have to deliver X features till Y date, but to develop those X features with quality there is no way you can do it till Y date. So what to do ?

So I was splitting stories and batching them and preparing them for Product Owner that she could prioritize those and then I have realized:

1. What you gain from CQRS? You have write only domain (there are of course more, but this is the most important for this article)
2. What you gain from event sourcing ? You have a full audit of your system. You know every single step that was made on your system, I mean every.
3. How product is build in Agile environment? You do it step by step, creating tested and shippable increments that at the end of the day builds up a product
   

So, I think some of you are getting the picture already. Now if we have a really good user stories, our stories are written in INVEST way, so we can create the most important related features/stories in first sprints and if that is enough for business - we can go live. Yes, that is right, go live. Deploy system to production environment, start promoting and do all the rest that business needs.
Meanwhile Scrum team will start implementing future features, that are related to our deployed features and requires generated data from them. And thing is that once we are done with our so called future features, we can take out event log from our production environment, plug it in to our staging environment, click 'replay' button and wait till our data, generated in production environment, will be grabbed by newly implemented features. Those features then will update their state (internal event handlers), update required storages (external event handlers) etc. And once it done, we can go live again, but this time our system will have newly implemented features, and moreover, it will look like those features were there from the beginning!
For example we need reporting functionality for sales department (we call it bounded context, because its separate, autonomous mini application) that says how many sales were done and so on. So once we have reporting features implemented we can replay events (sales events) that happened on production environment and let 'reporting features' do what they suppose to do when that kind of event occurs! Isn't it amazing ? You can create future while present is running, gathering data and then integrate all this and put it back for production usage, like it was there from the beginning! (I am repeating myself i guess :))

Of course, I hear you saying that there are features that can not be plugged in like that, and I totally agree with you, but perhaps it means then that those must go together in one sprint, or must be rethought if those, related features, are really important to business and must be included in sprint. Because at the end of the day, its all about business and what value one or other feature will create.

So, that would be it. I hope it will help someone. I really would like to get some feedback on this, so if you have something to say about this, you are more then welcome.