You can stabilize the estimates by establishing a keystone story. The idea here is to keep some degree of consistency as you go from sprint to sprint by having a User Story of known size against known definition of done so that all estimates for the team are based off this one User Story. Its like taking a brass plate to every meeting which involves estimation which has the User Story and Definition of Done inscribed on it so that everyone can easily come back to this baseline.

To create a “keystone”:

• If you already have an estimated Product Backlog in place, take an 2 or 3 sized User Story that the Scrum Team has implemented and declare that to be the keystone User Story.
• If you have no Product Backlog in place, establish your baseline User Story by finding the smallest User Story in the top 20 of the Product

Backlog. Declare that to be a 2 and the keystone User Story. Come back and revisit this keystone after a couple of sprints to see if it still makes sense.

Once teams have established one keystone User Story they will also look at setting up anchoring User Stories for other point values. This approach is very related to another approach Establish points guidelines for each point value except that rather than defining the characteristics of the User Story as that approach does, this approach defines known sized pieces of work.

Teams have found this helps stabilize the actual velocity, helps show when the Scrum Team is improving, or not, and generally provides more confidence for the estimates.

Some people then ask “Can we change the Keystone story?” The basic answe is “Yes”, but you need to provide a mapping of old versus new to the Product Owner. There are a number of reasons why this might make sense:

• Perhaps the story we have is not really representative work of the team and so we need a story that is more representative.
• Perhaps the story we have does not reflect the work the team does any more. For example we have now moved into a new technology area.

It is clear that we should establish a more appropriate keystone story for these situations. Where possible you should make sure you new keystone story maps in size to the old one. In other words, the new 2 is the same size as the old 2. This means that estimates you have in place do not need to change, and the velocity that you have established can be used by the Product Owner to understand what is happening with his plan. Irrespective in the light of the new keystone you should:

• Check the estimates that you have to see if they still make sense
• Discuss what the new keystone's impact is likely to be on the existing velocity numbers the team has with the Product Owner of the team.