Dr. Jeff Sutherland, the creator of Scrum answers this question directly in his Points vs. Hours Webinar on slide 6
What are Points? Points are a measure of team OUTPUT. Correlated to but not necessarily the same as effort.
JJ Sutherland, CEO of Scrum Inc. answers it even more directly in his lesson on Getting Velocity Right
Just because the team has gotten better at implementing any given story, the point value you should remain the same.
Since this question is controversial, here is research that answers some of the concerns voiced in other answers:
Yes. Scrum's goal is to increase velocity
Although velocity tends to oscillate over time, as a rule it should trend upwards about 10% per Sprint. -- JJ Sutherland
Slide 5 of Scrum Inc's
Lesson on Velocity shows a velocity chart with a 12x improvement over time AND titles the chart "Output Improvement" with "Points" as the y axis:
Go to ScrumLab.scruminc.com and look at the Metrics webinars. It shows how we measure company performance using improvement in velocity, the happiness metric, and the revenue per point. I hear so many slow teams complaining that going faster will just generate more crap. This is because Product Owners are not held accountable for doubling revenue per point. If you double velocity and double revenue per point the company will generate four times more money. This will make everyone happy. That is why you need the three metrics. -- Jeff Sutherland
Yes. Story Points Measure Output / Production
The management metric for project delivery needs to be a unit of production
Jeff Sutherland in his definitive article Why Story Points Are Better Than Hours
If the Team starts to estimate stories at lower values because they
have incurred substantially more experience and the stories seem
easier, Velocity will never seem to improve. This is one big reason
why estimating in hours doesn’t work. -- Scrum Inc CEO, JJ Sutherland
NO. Increasing Velocity Does Not Ruin Predictability
First of all, as a PO or executive predictability is very important, but productivity is even more important. Most POs if given the choice between maintaining production levels or significantly improving productivity at the expense of some small predictability would choose the increased productivity. That being said, the tradeoff is a false choice if a team employs the recommended Yesterday's Weather scrum pattern for sprint planning.
Using common sense... if a team produces 10 widgets a week, then finds a way to produce 40 widgets a week; their velocity has improved 4x. The PO is getting 4 times as many widgets in the same amount of time. Calling that flat velocity is contrary to the definition of the word.
YES. Gaming the System is Possible If The Whole Team Cheats
Finally - it's possible to game the system, but it's possible to game any system. Scrum minimizes the individual devs cherry picking stories by pulling from an ordered backlog and by measuring velocity on a team basis, not on an individual dev basis. If you measure dev by dev velocity you're not doing scrum. And it mitigates gaming the system through estimates by grooming stories as a group. To sandbag your estimates you have to do it in front of the group and the group has to collude with you. But if you want to game the system it doesn't really matter what process you use. Scrum does depend on a team of 4-6 motivated, capable employees interested in accomplishing goals together; but if you have employees who are cheating on work to game the system then your process isn't the problem.