Imagine you have user story 1 which requires the implementation of a method:
public static void MyMethod(string paramA);
Several classes will be using this method, and MyMethod does everything required to complete user story 1, but nothing more.
You are pretty sure that in a future iteration another story (user story 2) will come along which will require the method to become:
public static void MyMethod(string paramA, int paramB);
The previous calls to MyMethod will need to be refactored, and some new calls to MyMethod will need to be added to meet the requirements of user story 2 (Note after story 2 it never makes sense to call MyMethod with only paramA).
When working on user story 1 is agile thinking to:
1) Only implement: public void MyMethod(string paramA);
2) Implement: public void MyMethod(string paramA, int paramB); - But do nothing with the second parameter for now. Calls pass in 0 to the second parameter at this point.
3) Implement: public void MyMethod(string paramA, int paramB); - But do nothing with the second parameter for now. Calls pass in the correct value (according to the expectation of user story 2)
4) Implement: public void MyMethod(string paramA, int paramB); - And all calls Completely to cover user story 1 and 2
On one end of the spectrum are the Agile purists that insist that everything can be accomplished by refactoring later. On the other end are the old-school Big-Design-Up-Front crowd that think you should build a complete architecture first and then snap features onto it. Your question is perfect because it exposes the failings of both philosophies if you mindlessly follow their processes. What you want is maximum efficiency. So you need to analyze what Story 1 and Story 2 are in your situation. Is your software shippable without S2 or did you just split up the stories to help with estimating and planning? If S1 is "Add to shopping cart" and S2 is "Check-out" it is silly to not build the interface to support S2 because your software is worthless without it. In every project there is a certain set of known "Have-to-have" features that make your software even worth shipping. If Both of your stories are from that set then I would say build the interface to support both now and don't waste time refactoring later (#3).
Usually if S1 and S2 are both in the must-have set they will be close together on the Backlog. If this is not the case then you either have a huge amount of must-haves and your project isn't going to gain that much advantage using Agile techniques or S2 really isn't a must have. So if you are expecting a large chuck of time (months?) to pass between the commitment to S1 and S2, then I would go with the 1 parameter interface. Time is always a huge contributer to uncertainty.