Items in a Sprint don’t get finished and there is spill over

There's no spill over in Scrum. A Sprint Goal is either met or it isn't, and any unfinished work is re-estimated on the Product Backlog for consideration in a future Sprint Planning session. That's it.

Velocity is the rate at which work is Done, not part done. Any work partly completed, once re-estimated on the Product Backlog, can be expected to lower the overall amount of work remaining.

As it's defined in the Scrum framework, work doesn't "spill over". When the Sprint timebox expires, undone work is returned to the Product Backlog, where the Scrum Team (primarily the Product Owner) can reorder it. If there is some partially done work, this could be a factor to consider when ordering the work in the Product Backlog. When the team is planning their next Sprint, they craft a Sprint Goal, but may also select other Product Backlog Items based on their capacity.

In Jira, at the end of the Sprint, you have the option to either move undone work into a new Sprint or to return it to the Product Backlog. Moving it to the Product Backlog first is more consistent with the Scrum framework, but if you know that it's likely to be selected, then it could be easier to move it to the Sprint first.

In my experience, work is either done or not done. There is no partial credit. When using story points, the team will "earn" the full value of the story points when the work is complete.

However, this gets into more philosophical questions about story points and the value of estimation. Personally, I don't see much value in estimating. It's more valuable to decompose the work into the smallest unit of demonstrable or deliverable value, then work on that. You can use flow metrics, like throughput and cycle time, to forecast the amount of work to plan in a Sprint or when a given Product Backlog Item will be done. Eliminating the estimation question saves a good deal of time in refinement, allowing the team to either do more refinement or focus on value-adding work like designing and delivering product changes.

Aside from the reason why you would use story points or estimation, if you regularly have stories that aren't finished at the end of a sprint, spend a little more energy on your refinement process. It could be that the stories are too vague or too large to get 'done' in a sprint. I also regularly encounter teams that have stories with dependancies on external resources. For example: a story where person X should do something, but person X is not on the team. Those kind of dependancies tend to lead to stories that are difficult to finish. Try to define the 'what' part of your stories to only include things your team can do themselves.

This is a common question, how to manage the story points on items not finished. Scrum / Agile do not award partial story points as said above. Either the full story point count is included in the velocity calculation or nothing. However at the end of a sprint the items not finished are moved to the backlog and then re-estimated, often to a lower value as some work was already completed. This is were the problem comes in. What happens to the story points "partially" completed? One option is to re-estimate the story points in Jira when the item is put back on the backlog, but keep track of the original story point value. For example put the original value in a Jira comment as Jira don't have "original" and "re-estimated" story point value fields (as far I know). Use the original value then in velocity calculations. 

Unfortunately you use some story point tracking tool, else the recommendation would be to not focus so strictly on precise accurate story point values. Scrum is geared to value work done and sprint goals met, not chasing story points. 

As most of the people have mentioned, the story should be re-estimated and go into the backlog/next sprint. This essentially means the story will carry a lower story point as some amount of work has been completed. You need to take this point in the sprint retrospective and check why the story could not be completed (could be it was not small enough to be done in the sprint or there were some blocker/dependencies which came into play).

Reason i am asking is that the company i work for has Tableo Tracking which tracks Scrum KPIs 

What KPI is used here exactly? If it is average velocity, it is something very specific to the team for them to know how much work they can get done (and the only purpose it is used for is to forecast). 

Focus should be on measuring the value that is delivered through the increment. Using velocity as a KPI and comparing between teams would be a wrong idea.

Good point by Ian there. If the team has planned 10 items in the sprint backlog which contribute to a sprint goal, even if 1 item is not completed, it means the sprint goal was not met. Now in that case, few questions arise:- 

1. What happens to the sprint then? If the sprint goal is not met, what does the team demonstrate in the sprint review? 
2. Does the team commit partially achieved sprint goal? 
3. If the team was unable to meet the sprint goal, does it add one point in team's failure board? 

In practical scenario, I have few workarounds for this (strictly remaining inside Scrum boundaries): - 

1. If by keeping aside the unfinished item, team is still able to deliver value to the customer, let the team commit finished items and demonstrate those in the sprint review. 
2. The unfinished item can be moved back in the product backlog. Depending upon the customer feedback in the Sprint review, the priority of that unfinished item can be arranged by the PO. 
3. The team should not be afraid of failures but take them as lessons and Retrospect :) Maybe the DoD or working agreement needs to be changed during the Sprint retrospective, team will discuss and derive a solution to improve the situation. 

Loads of great advice above. 

I think it is important to see story points for what they are and to understand what they are not. What they are is a relative size in numerical form. A guess. They are not something that can be earned, delivered or redeemed.

The problem with story points being in numerical form is that we want to do math with them. Story Point accounting. This leads us to things like “how can I account for part of the work” and “carry forward the Story Points”.

Story points don’t really provide a representation of work completed as there is no connection to what the velocity number represents. 13 points could mean 1 backlog item, 3 backlog items, 13 backlog items…

We want to be careful about normalizing “spill over” or “carry over” as teams can become comfortable with this. To borrow a term from PST Sandur Dur, they get a case of the TANS (There is Always Next Sprint).

The Sprint Backlog is ephemeral. It lasts as long as the Sprint does and a new one is created with the next Sprint. Rather than think about it in terms of “spilling over”, think about the started but not finished work being returned to the Product Backlog, discussed and sized, and pulled (or not, there is always a choice) into the new Sprint Backlog if it serve the next Sprint Goal.