Incredibly simple: It's always 3 points.

(or pick a different constant). This is the approach we took at our last job and I think it worked out relatively well.

The idea is that you have a backlog full of actual stories and one of them happens to be an integration story with a device you know nothing about. If someone asked me to size that story(actual integration) without any more knowledge, I would give a very conservative estimate. If I did similar integrations in the past, I might pick a story points on high end. If I never did similar work and don't even know where to begin. I pick a million points.

So then obviously product owner comes back and says, we can't have a million points, so let's create another story about research. The goal of the research story IS NOT to code the integration. It IS NOT about solving every possible problem you might face. The primary and only goal of the research story is to give better point estimate for the actual work story. Don't get lost trying to figure out how to use every single API call and come up with actual integration design/code. Instead, approach it from a high level to understand the complexity that's ahead of you.

At the end of the research story, your #1 deliverable (along with possible research notes, prototypes... etc) is a point estimate for the integration and possibly break down of integration story into several smaller parts. Keep in mind that each of those still has an unknown component given enough research, you should be able to control for that unknown part (i.e. you read about usage of some API and it looks like its going to be 5 points, well, pick 8 just to be safe).

What we found is that the developer assigned the research task always runs out of steam at almost a constant number of hours (obviously there is some fluctuation, but it averages out at the end). After that you could spend twice as many hours, but your integration story estimate won't get any better.

Incredibly simple: It's always 3 points.

(or pick a different constant). This is the approach we took at our last job and I think it worked out relatively well.

The idea is that you have a backlog full of actual stories and one of them happens to be an integration story with a device you know nothing about. If someone asked me to size that story(actual integration) without any more knowledge, I would give a very conservative estimate. If I did similar integrations in the past, I might pick a story points on high end. If I never did similar work and don't even know where to begin, I would just pick a million points.

So then obviously product owner comes back and says, we can't have a million points, so let's create another story about research. The goal of the research story IS NOT to code the integration. It IS NOT about solving every possible problem you might face. The primary and only goal of the research story is to give better point estimate for the actual work story. Don't get lost trying to figure out how to use every single API call and come up with actual integration design/code. Instead, approach it from a high level to understand the complexity that's ahead of you.

At the end of the research story, your #1 deliverable (along with possible research notes, prototypes... etc) is a point estimate for the integration and possibly break down of integration story into several smaller parts. Keep in mind that each of those still has an unknown component given enough research, you should be able to control for that unknown part (i.e. you read about usage of some API and it looks like its going to be 5 points, well, pick 8 just to be safe).

What we found is that the developer assigned the research task always runs out of steam at almost a constant number of hours (obviously there is some fluctuation, but it averages out at the end). After that you could spend twice as many hours, but your integration story estimate won't get any better.