In Agile SCRUM we size things to put an estimate of the effort and complexity involved in producing the work product. We might say that the size of something is extra-small, small, medium, large, etc. These sizes translate into velocity points. How many of these points we complete each sprint tells our product owner how much work he should expect to get done in a release. It is one of the most visible measurements of productivity that will be seen by upper management.
In my teams, the primary things that are sized are user stories and defects. User stories represent new work and defects represent work to fix a defect in the application. I have found that they way teams tend to do their sizing is different for user stories and defects. It is like a different scale is used.
In general a medium sized defect winds up taking a lot less work than a medium sized user story.
This creates an issue when measuring velocity and ultimately when measuring productivity. If your team spends a much larger percentage of time working on defects in one release than in the next, you will see a drop in velocity.
As we know velocity is watched by many folks in any organization. Perceived drops in velocity will raise questions and cause concern. It should! However, in this case what is seen as a drop in velocity really isn't. It is simply an issue with how sizing is being done.
I am now pushing my teams hard to consider sizes of defects in context of user stories that are also sized the same.
It is very important for a scrum team to size work efforts consistently. Always push the team to compare the work effort of an item they are sizing to other items they have sized in the past- Especially when sizing defects. If you don't then your velocity metric will be misleading.