Velocity

According to scrum values, velocity is how much product backlog effort a team can handle in one sprint. Velocity is used for predicting when the project will be done. When a project is started we have a general scope, a projected cost, and a probable date. When we go sprint by sprint we learn more about the scope based on the reality of the situation. We go faster or slower, may find better opportunities or challanges. So predicting when a project will be over based on velocity may not work out well as mostly seen in agile or scrum based projects.

Lets take a different approach and ignore velocity and capacity and work based on a goal. The team with the product owner selects a bunch of items of high priority for the next sprint and establish a goal for the team to meet. As the sprint moves either the items which were more than the team could  do be removed or get more PBI's that could fit into the goal into the sprint if they have the time for it. At the end of the sprint the Product Owner, Team and Key stakeholders can inspect and adapt based on what was completed.

If we used short cycles of development of a week to 2 weeks at a maximum which will give a quick feedback on the progress towards our goals, commitments and projections. A build up chart might help to gauge how far we have progressed towards our goal. Any time a team spends on worrying about velocity or capacity is waste and not adding any value. It slows down progress, impedes agility and robs time and effort that could otherwise go to creating value.

Use last sprint's velocity as a guidance to what can be done in next sprint but focus on goal and measure progress based on how far or near you are to your goal and make changes that help you to get to your goal.