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”:
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:
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: