What is Velocity? (in agile software development)

Velocity is a term used in agile software development to illustrate the "rate of progress" for a team or a set of teams (i.e. a project/program).

The simplest way to define velocity is: the number or user stories a team/project can do in one sprint ("do" here means that it really is done and potentially ready to ship).

Without the use of velocity you would not be able to draw your teams's burndown, as velocity is the slope of the burndown curve, i.e. how fast are you burning down the stories (or story points or hours) that you committed to for the ongoing sprint.
At a project/progam level, velocity is the rate at which the whole project is burning the User Stories (or requirements) from the backlog.

Also, without knowing your team/project's velocity you can not make longer term planning (over 1 sprint) or even release planning. Hence the importance of knowing your velocity!

In the first 1 or 2 sprints that you run, you will have to estimate your team/project's velocity as you don't have enough data to project your past performance into the future. However, after 3-4 sprints you should start using an average of your past velocity to plan the future and update the release plan.

Note that velocity is a range, not an exact number. For example, if you have developed 2, 5 and 4 stories respectively in your past 3 sprints, then you know that your velocity is 2-5, not 3 or 4. This range will allow you to communicate your best case scenario and your worst case scenario to your stakeholders instead of committing to one single number that is most likely wrong. Always use velocity as a range when communicating outside your team.

In short, velocity is how fast you are developing your software.

Some more resources:
An extensive example and definition of velocity.
A simple definition of velocity:
The mathematical definition of velocity (from Physics).

My thinking on velocity and Agile Estimation has evolved

If you want to know what I have learned since I wrote this article, check out my #NoEstimates white paper and the following articles:

• Simple estimation techniques work! Use the data you already have
• Story Points considered harmful, or why the future of estimation is really in our past
• A better way to predict project release date
• Focus on what matters, a #NoEstimates advocacy post
• The #NoEstimates how to

Punished by the Annual Performance Review

Many of us in the Agile community have voice our opposition to the individual performance reviews and target setting.
Now, a professor from the University of California, Los Angeles (UCLA) has come out with a similar position and not less than in the serious Wall Street Journal (copy of the article), yes, the same that your CEO religiously reads every morning in the 5 star hotels where he "lives" -- there's hope he read this article.

Professor Culbert goes on to say that annual performance reviews are not only counter-productive, they are immoral. He says it best:

I believe it's immoral to maintain the facade that annual pay and performance reviews lead to corporate improvement, when it's clear they lead to more bogus activities than valid ones. Instead of energizing individuals, they are dispiriting and create cynicism. Instead of stimulating corporate effectiveness, they lead to just-in-case and cover-your-behind activities that reduce the amount of time that could be put to productive use. Instead of promoting directness, honesty and candor, they stimulate inauthentic conversations in which people cast self-interested pursuits as essential company activities.

He goes on to say that the manager's job and responsibility is to enable and promote the employee's performance, not to "punish" it:

The boss's assignment is to guide, coach, tutor, provide oversight and generally do whatever is required to assist a subordinate to perform successfully. That's why I claim that the boss-direct report team should be held jointly accountable for the quality of work the subordinate performs. I'm sick and tired of hearing about subordinates who fail and get fired, while bosses, whose job it was to ensure subordinate effectiveness, get promoted and receive raises in pay.

Here are some of the dysfunctions that the annual performance review cause:

• They harm teamwork
• The "objective" nature is completely fake objectivity
• They create adversarial relationships between employee and manager
• Pay for "performance" is really market-driven pay (or raises) in disguise
• They impede personal development

How about you? What have been your experiences with the annual performance review? Write it up on the comments.

WAgile is hot, it's the new craze!

Have you heard of WAgile? No? It's the new craze!

Check it out here.

PS: it's a joke and it's supposed to be a stab at all of that lip-service agile! In the best Dilbert style!

Enjoy