Many well-intentioned managers have a fundamental misunderstanding about velocity. They think it is a measure of how hard the scrum team is working or how much they are producing. Neither of these is correct. Velocity is a tool for predictability.
Because of this misunderstanding, many managers think that the team should work toward increasing their velocity. If management focuses on velocity, this will create dysfunction. Imagine that your manager wants to see the team’s velocity increase. This is very easy to achieve; the team can simply increase their story estimates over time. Velocity will climb as high as anyone wants. This won’t correlate to any change in productivity or business performance, and the manager won’t get what they wanted. Worse, the team has just lost visibility and control of their schedule. What’s a scrum master to do?
How should a scrum team count the story points for user stories (product backlog items) that are started in one sprint but completed in a later sprint? This question comes up frequently and has surprisingly deep implications. It also has a simple answer. Let’s dive into an example that a client sent me.
I was inspired to create a retrospective game for agile teams, based on the game Dixit. 
A common problem among the scrum teams that I coach is user stories that are too big. When a user story is too big, it is hard understand, estimate, and implement. So what is a good size for a user story? My guidance is that the user stories at the top of the product backlog should be sized such that the scrum team could easily complete four to six stories a week.