Review all the 5's for example to see that the represent the same relative size of work. Do this for each Story Point size in your Product Backlog. Make sure that different types of work line up so that, for example, a 2 sized defect is about the same relative size as a 2 sized enhancement.

At regular intervals go through the Product Backlog and make sure that all the 5's, for example, represent the same relative size of work. Times when you should do this:

• When the Team has done a whole bunch of estimates in one or two sittings.
• When the Team haven't done it for a few Sprints
• When the Team has a significant new understanding of how to build something as a result of invention, technology change, discovery etc.
• When the Team feels uncomfortable with the status of the estimates in the Product Backlog
• When the Product Owner is finding that the velocity seems to be inconsistent from Sprint to Sprint

Make sure that if you make significant changes in the Product Backlog that you provide a mapping back to previous Team velocity so that the Product Owner can continue to manage the plan.

Teams have found that the estimates have drifted over time, or that defects have a different basis to enhancements, or that release sprint have a different basis to production sprints. Using this approach helps with the stability of the estimates and therefore helps with the overall predictability of the plan.

This can be done by gut feel but you can also use data such as the actual duration of work associated with a User Story to help understand if the work really is sized correctly.