A team's velocity is the sum of the estimates of the user stories that were done during the iteration.
Some people use velocity as a measure of productivity. Productivity is the rate of production measured in terms of the rate of output per unit of input, but I like to think of velocity as the capacity of the team because it represents the maximum number of story estimation units a team can take on in a planning game based on yesterday's weather. I prefer to measure productivity in terms of the goal and getting stories done is not the goal, generating revenue is. Getting stories done is the means to achieve the goal.
Productivity could be something like the business value delivered per iteration per unit of story estimation, but business value is typically subjective and therefore not easily quantifiable. Productivity is perhaps better represented by the revenue generated per iteration per unit of story estimation, e.g. £10,000 per ideal pair day. A complementary measure of productivity uses pure monetary terms and is the ratio of the revenue generated to the cost of delivering the functionality responsible for generating that revenue, e.g. £10,000 / £5000 = 2.
A product stream should work to maximize return on investment and the team should challenge itself to increase its velocity. Pressuring people to work harder, work longer hours, and take on an increased workload is not the way to increase velocity. It's the way to start a death march. Causing people to sacrifice their work-life balance is detrimental to the health of the people and the product because tired people drop quality and create more defects. People should be allowed to practice energized work where they work only for those hours where they are genuinely productive and maintain high quality. And a team must be given the space and the time to find the velocity at which it can work and deliver at a sustainable pace.
The way to reveal extra capacity and increase velocity is to relentlessly remove obstacles, eliminate waste and improve continuously. Help the team focus on the product, on quality, and to deliver only the functionality that adds value to the product and generates revenue. Keep the process simple and intuitive so that people don't have to stop and think what the next step is. And protect peoples' flow-time by preventing interruptions. Help the team avoid creating inventory, i.e. functionality that is complete but cannot generate revenue because it is not deployed to the production environment. Quickly remove obstacles that are identified in the daily stand-ups and minimize dependencies so the tream doesn't have to rely on others to get stuff done. This also cuts down on the time spent waiting around and chasing down and the effort required to hand stuff over.
Previous Topic
