Hi Karina,
Writing stories, or collecting information of what needs to be done from a business perspective, is a huge topic and beyond the scope of this book. Effect mapping is one way to do that, and it does share some ideas with the Mikado Method. See
http://www.use.se/index.php/2009/11/06/everyone-project-should-have-an-effect-map-im-doing-an-effect-map-one-for-my-iphone-app/
for a quick overview.
If you need to change the story (or Goal) you have to look at the impact of the change on your code base. In general, you can probably just assume the current state as a new starting position for the changed story. If you want or need to, and can, revert your partially implemented story you can do that.
If that happens often, maybe
you should not try to find a rock solid process to handle it, but rather see if you can change how you work, to avoid it altogether? This is just a thought, and has little to do with the Mikado Method. :-)