Reference Story
In Agile product development, a reference story serves as an aid for a team to estimate the effort required for the work of a user story that is actually to be processed. The reference story is a user story whose requirements, complexity and implementation are comprehensible to all team members. In this way, it is used for relative estimation.
How are reference stories used in Scrum?
The team first considers the effort of the story that serves as a reference and then evaluates it with the corresponding story points. New requirements in the form of user stories are now evaluated in relation or reference with the effort of this reference story. If the Scrum team estimates the effort for the implementation of the new [User Story](/en/agile-dictionary/user-story/"User Story") to be higher, for example, this is evaluated with higher Story Points.
Why are reference stories useful for your team?
Scrum and other agile methodologies measure the effort required to implement tasks not in "person-days" or time in general, but in abstract Story Points. The reason is that all team members and other employees in the company should be aware that the effort figures are relative effort estimates and not concrete time figures. Exact time specifications and time estimates are in many cases much too inaccurate to be able to achieve meaningful results with this. However, with the help of the reference stories and the sum of points in a Sprint, a suitable estimate of the effort to be created per team can be made with a little experience.
How does the estimation of a user story work in relation to the reference story?
For the estimation of a story as a Product Backlog item, special poker cards are used in Scrum for the so-called Estimation Poker (also called Scrum Poker or Planning Poker. Depending on the team, this estimation usually takes place in Refinement or in Sprint Planning.
In Estimation Poker, each team member receives their own deck of cards. The members each simultaneously draw the poker card with the number of story points they estimate as realistic for the implementation of the story. They base this estimate on the effort of the reference story previously determined in the group.
After revealing the cards and discussing any differences in the estimates and ideas for implementation on the part of the developers, it becomes clear whether the team would like to consult the product owner again for further clarification of the requirements within the story.
Tip:
Very high effort estimates of, for example, 40 or 100 story points indicate that the user story can be split into multiple stories.
Once the estimation for the User Story is complete after another round of Planning Poker, the estimated Story Points are noted on the Product Backlog item in preparation for Sprint Planning.
Conclusion on reference stories in Agile Estimating
If a well estimable story is used as a reference, the estimation of new stories by the team is done on a common basis. Only in this way can the members approach a jointly estimated effort and commit to these stories later in the sprint.
The stories completed in a Sprint are in turn used to calculate the Velocity (the team's working speed), on the basis of which it is easier to plan future Sprints in a meaningful way.