I believe most of the words and metaphors used in Agile/XP/Scrum where chosen with great precision. So, often exploring those words is the key to understanding what the guiding principle is. Once you have the guiding principle you can apply it to the situation you are seeing.

So back to points…

Points drive Velocity so I want to focus there a bit. Let’s look at the definition of Velocity to see if that helps;

ve·loc·i·ty

noun: velocity; plural noun: velocities

the speed of something in a given direction.

Recall in High School Physics that Velocity is expressed as a vector. The equation for computing velocity is something like change in speed dived by change in time, in a direction. This is different than speed.

For those not mathematically oriented I present the below picture;

Speed

In the above picture the vehicle connected to this wheel has zero Velocity. The wheel has great rotational speed. The wheel speed shows on the speedometer. Although there is a lot of work going on, the person driving is not getting to where they want to go. Below we see a example of a man with a place in mind to go using a beautiful Ferrari with velocity to get him there.

Velocity

Velocity (if you can control the direction) gets you to where you want to be. I believe choosing the word Velocity as the primary Scrum metric reflects the purpose of the measure. So the difference between speed and velocity is that velocity requires progress in a direction.

So back to points…

Applying this to your team means that you need to know the goal to set direction. The speed of the work that moves you to that goal goes into your Velocity measurement and everything else does not. For most teams the goal that sets your direction is the sprint/iteration forecast or release backlog. Although teams do all sorts of other work, only work toward this goal/direction gets estimated and assigned points. But make sure that ALL work needed for that is included. This is where the team’s ability (both What and How) to estimate is key to meaningful Velocity.

So if you believe the above way of thinking, then if you assign points to work that is not needed for the release (for example), your Velocity number may be measuring something other than Velocity.

Note that the measure is not speed (distance over time). If it was speed that we were interested in, then it wouldn’t matter what you would give points for because you would not be specifically interested in a goal oriented measure. Some teams that morph Velocity into Speed easily size and point stories where there is conflict about the value or priority of the story. Technical Stories and tasks pretending to be stories testing are examples. When points are put on anything that is not a user story then it dilutes the measurement because you are combining things that show progress in burning down the backlog and things that do not. It can turn Velocity into a measure of busyness. Like the spinning tire, there is a lot of activity but not all the activity translates to movement to the goal.

Also note that the measure is not capacity (the amount that something can produce). Teams that morph Velocity to Capacity point everything and everything goes into Velocity. The problem with this is that it is like the capacity of a machine where only some of its output is used for a finished product. Although it generates lots of parts they are not needed and may increase costs. For a Scrum team this means the Capacity measure is not helpful to know when you will arrive at the goal.

So why do teams find this difficult? I think teams get “wrapped around this axle” because management can’t resist ignoring two Scrum bedrock truths;

Low Velocity does not mean that the team isn’t doing anything. Many teams do not have dedicated resources. Many teams are assigned to production support. Many team members go to training, meetings, and have vacations (I know of teams that point these activities). Most of the time low real velocity is in fact due to management decisions, allocation and staffing projects, and other organization imposed distractions. Velocity in this situation should be low or variable. Velocity does not equal capacity. When management starts thinking it does it leads to team pointing dysfunction as they try to show they are all working as much as they can.

Never Use Velocity to Compare Teams. Management’s irresistible urge to ignore this is responsible for many dysfunctions. The one I will focus on is team obsession with figuring out how to tweak Velocity to look good relative to other teams. This led one team I know of to give points for vacations. It stops teams from improving because that often creates a temporary dip in Velocity. It stops teams from innovating and experimenting because the risk is too high. But the core fallacy is that since the teams are working to different goals/domains and use totally different relative point keystones, although we call them points it’s like comparing apples to hippopotamuses. I often (kinda) jokingly suggest that at team startup you should roll a die, use that number as a point multiplier so all the teams will have points that look different. If this were the case it would be less tempting make the leap to comparison.

So what does low Velocity mean? This deserves another Blog article but until then… Low, flat, or variable Velocity may mean;

• The team may be distracted by non-project goal work (like production support).
• The team may not have the capacity due to too few dedicated resources.
• The team may be trying to do too many things at once.
• The team may not have the skills needed for the project domain.
• There may be a quality issue requiring high levels or rework that robs velocity
• The team may be estimating in a way that decreases estimates as they learn or doing some other estimation practice that distorts velocity
• It may be ok

To sum up here are some key points to ponder on points;

• Since Velocity is a measure of progress, put points on only the work that moves the team in the direction of its goal.
• Time Boxing is a great way to steadily do all the rest of the work the team agrees to do because it limits the distraction.
• Resist the urge to think low Velocity means the team is not working.
• Resist the urge to compare one team to another because the velocity numbers look like they are on the same scale.
• Resist the urge to let #3 and #4 have an impact on the question if work gets points or not.
• Low velocity is not the problem but may be an indicator of a problem.