From the customers perspective...

... a story starts and ends with the customer experience. There are no technical stories.

The technical temptation

From a technical point of view two stories A and B that share some basic functionality might look like an opportunity to extract the technical commonalities in a story C. What tends to happen is that you wind up with three stories A, B, C that can be easily "estimated" and have an obvious order of implementation - you start with implementing the technical commonality C and then, once that is stable you can do A and B on a tried and trusted foundation.
Nice, isn't it?
No - it is not!
Now you would have three stories and none of them conforms to the I (independent) of the INVEST concept for good stories. And what's worse: you end up with a story that is not testable by the user - story C. To add insult to injury, it is even your first story, further delaying the deployment of code that is useful to the end-users.

A solution?

For me the solution to this scenario is to really plan, estimate and analyze in four dimensions. Take the time into account. If you implement A first then A is much bigger than B because once it is finished B gets all the development effort from A for free – or at least the part that turns out to really be usable for both A and B. So B is actually bigger on the inside - unless you travel on a different timeline where B gets developed first. In that case A would be the story that gets the benefits.
In either case, the important message is:

Don't burden the customer with technical stories to get better story-sizing, just look at every story in the context of the moment when it gets implemented.

Value gets delivered only when new capabilities are available to end-users.

Untill next time
  Michael Mahlberg