TL;DR
Neither of your stated options are truly agile. You are misusing points in an attempt to represent progress or to "hold people accountable." Neither is appropriate within the Scrum framework.
Points are an estimating tool. They are only meaningful in the aggregate, and are primarily needed for estimating team capacity during Sprint Planning. Using them as a productivity metric is misleading, and continued misuse of the story-point system will eventually harm both the team and the project.
Points are Not Rewards
This way the team gets some points in both the sprints.
In Scrum, a story is either done or not-done; it is never partially-done. You can certainly rig the system by artificially decomposing stories so that you can "earn" points in a Sprint by completing certain stories even when the real underlying feature isn't complete, but this doesn't serve any practical purpose other than to inflate velocity. Inflated velocity will ultimately skew your estimates, hurt the team, and damage your project. Don't do that.
Points are also not rewards. They aren't lollipops that you hand out for a job well done; they are simply a work-effort metric. Specifically, story points:
- Are converted to a velocity metric by aggregating over an historical window, tracking the team's capacity for work over time.
- Are used as a sanity-check to determine if a story can deliver its intended value within a single iteration.
Points Measure Capacity
Points are both an estimating tool and a means of tracking team capacity over time. When estimating, story points tell you:
- How much effort the team thinks a story will take.
- Whether or not the story (in its entirety) can fit within the current iteration.
- Whether the team should accept the story into the sprint as-is, or whether the team needs to work with the Product Owner to refine, clarify, decompose, discard, or re-scope the story to achieve the current Sprint Goal.
Points also act as a proxy for team capacity over time. Earning points adds no value to the project, but being able to say that the team can usually complete an average of 12-16 points in a typical iteration helps the team estimate its capacity to accept stories during Sprint Planning. This helps the team avoid over-committing, prevents setting the team up for failure by creating an unsustainable work-load, and avoids planning a sprint that will not meet the stated Sprint Goal for the iteration.
Stories Should Fit Within One Sprint
If your stories can't fit within a single sprint, then you either have an epic that must be decomposed, or your sprint length has not been optimized for your project. There is always a trade-off involved in determining the optimal sprint length for a project, but the challenge of writing stories that fit into a finite time-box remains a constant challenge.
In Scrum, a story should be a full-stack, vertical slice of functionality that engages the whole cross-functional team. Testing is never a separate story; rather, it is an integral task required to ensure that a given feature meets the formal "definition of done" as defined by the project.
Stories that are expected to extend past the end of an iteration indicate a process problem that must be fixed during Backlog Grooming or Sprint Planning. Likewise, stories which don't meet the definition of done are also process problems that the team urgently needs to address.