Scrum uses velocity as a metric. How do we increase velocity in scrum
Velocity is a metric as you already noted, a tool to help estimate how much work your team can realistically finish within a sprint. It's not a goal number! See https://en.m.wikipedia.org/wiki/Goodhart%27s_law for an explanation why making metrics into goals is a bad idea.
I suspect that the question behind your question is how to increase productivity. Scrum works from the assumption that developers inherently want to perform well and has several mechanisms to support this goal.
- Identify impediments, and have a dedicated role (the scrum master) to deal with them. Productivity is often improved not by working faster, but by not wasting time on unproductive things. The goal here is to deal with external causes of reduced productivity.
- Improve your process through retrospectives (inspect and adapt.) This is the task of the team as a whole, they know best where the weak spots in their process are.
Of course you need to realize that productivity can't be monotonically increased. Reliability and repeatability are goals that are at least as important in getting a working and satisfying solution out to the customer.
Here are some very basic and general tips to improve productivity
As others pointed out in the comments, velocity is a relative measure that could vary from one team to another.
- Requirement clarity: If your developers are often waiting for clarifications during the sprint, make sure all requirements and acceptance criteria are fully known latest at the time of sprint planning. Otherwise, don't include that story in that sprint.
- Context-switching: If developers are wasting time and effort in context-switching, the Product Owner (PO) should set the priority at the time of Sprint Planning and no one should be allowed to change that during the sprint.
- Impediments: If your developers are often delayed by impediments, the Scrum Master (SM) should focus on removing / preventing impediments. Organizational impediments (such as creating a ticket to get the Sys Admin to grant access) are often well known but hardest to tackle.
- Cross-functional: If your development team has people with single skills (For example, designers will do only design) then there will be a lot of idle time. Designers will be busy in the first part, developers will be busy in the middle and testers will be busy at the end of the sprint. So, push your team to be cross-functional.
Also, as others have pointed out in the comments, ask a more detailed question stating what steps you have tried and what is not working.