In Scrum, velocity is pretty much the same as cycle time.
Velocity measures what a development team is able to deliver in terms of developed product backlog items within a sprint.
From this blog https://leanandkanban.wordpress.com/2009/04/18/lead-time-vs-cycle-time/ I got this nice definition
Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Cycle time is a more mechanical measure of process capability. Lead time is what the customer sees.
Lead time depends on cycle time, but also depends on your willingness to keep a backlog, the customer’s patience, and the customer’s readiness for delivery.
Another way to think about it is: cycle time measures the completion rate, lead time measures the arrival rate. A producer has limited strategies to influence lead time. One is pricing (managing the arrival rate), another is managing cycle time (completing work faster/slower than the arrival rate).
Sprint Retrospectives do increase velocity over time. Knowledge, insights are shared which leads to team learning which affects the velocity in a positive manner.
Hence, retrospectives act as a moderator between developing software and output.