Empiric story reference base

Planning has an important role in Agile. The team uses planning to estimate the complexity of a requirement (userstory). The number of complexity points handled in previous timeframes then helps to decide what could fit into the next timeframe. However the complexity changes in time. Things get easier doing it a second time or easier ways are found for problems. This makes the planning even harder. Creating a reference base might bring stability in planning. These references make it possible to create a release planning without planning all the requirements upfront.

Problem
The planning starts with a single reference that the team uses as an offset for the initial planning. After a while they forget what the initial reference was and choose another reference. Ending up with a fluctuating planning.
In order to prevent this happening often the whole backlog is planned upfront. Resulting in an equally planned backlog. However this can have a couple of downsides. For instance when a team have not worked together before, the initial planning becomes invalid in a couple of sprints. Work was underestimated or got easier after doing it a couple of times. Replanning the whole backlog then is needed in order to get a valid release planning. It gets even harder when the team changes or not all of the userstories are known at the start of a release.
Reference base
Creating a reference base helps to stabilize the planning in time. After the first sprint the team can create an reference base. This reference base can help to plan the next sprint more accurate.
The reference base is created during or after the retrospective. The following steps can be taken:

1. Mark the reference stories; The stories that went as they should have can be marked as a reference story. Stories that were exceptional or unusual can be put aside.
2. Rate the stories; The team can decide whether the story was over or under rated. Sometimes a story is rated 8 but to be on the safe side the team chooses 13. In the retrospective the team can decide whether it was actually an 8 or 13.
3. Categorize; The marked stories should than be categorized by type of work.
4. Decide whether to add; The stories than should be evaluated. Is a story the same as an existing story or does it help to add this story to the reference base.
5. Add the stories; Add the new stories to the reference base. Include the number of point, expertise needed for this story, etc.
6. Check whether stories are still valid; Sometimes a tool can change the validity of a story. For instance work that is handled by a tool or the amount of points changed due to a tool. Check with the team what needs to be done.

The reference base can change every sprint. Stories that don’t suit anymore can be removed, others can be replaced or stories can be added.
Using the reference base
The reference base can be used for verifying or to plan another stories. The more stories you have in the reference base the more it helps planning that story. Due to the use of the reference base the points assigned to a story remain more stable. This does not mean that a similar story keeps the same points forever. For instance tooling can cause to change the amount of points. So in time the reference base changes, but it is a stabilizing factor.
Conclusion
The empiric reference base helps the team to stabilize the planning. This makes it possible to make a more accurate release planning. It might even speed up a planning session.