Relative Estimations aka Story Points/T-shit Sizes/Animals are very popular among Agile Teams.

To harness all benefits of relative estimations each Team should create Estimations Reference Table.

From this simple tool you can expect benefits like this:

• Which stories we should/have to split into smaller ones so we can delivery them in one iteration
• Which stories team is able to deliver in one iteration (High Probability Prediction)
• More accurate plannings
• Reference point during estimations
• Common understanding around Estimation
• Great onboarding tool to estimations for a new team member
• …

Reference Table is only a small part of my workshop about Relative Estimations.

For more go to my website: www.agilejp.com and book an individual or group session.

Or go directly to our booking system here

How to?

There are two ways to go with building a reference table.
First one is when you start with a fresh team without any estimations and second one is when your team was already estimating but you never took it a step further.

For now let’s focus on a second case.
Each team has its own scale. Check out last 3-4 finished iterations and pick done stories with different estimations.
As you can see on the picture above in this particular case 8 story points was the highest estimation for this team. Try to keep examples as diverse as possible and done within one iteration.
As estimations get higher it will be harder and harder to find stories done within one iteration. At some point you will notice where team is struggling to deliver story in a one iteration.

Color code stories and breaking points as above to visualise the patterns.
This team struggle to deliver 5 story points while 8 story point takes more than 3 iterations. 8 has to be split.
Of course there could be a case when its impossible or there are good arguments against the split. Thanks to the reference table your team can make a conscious decision while planning and manage stakeholders in a better way.

As a last step you have to brainstorm the table with a team.
Present the idea behind the table and check each example with a team if based on the details inside the story they still feel that it’s a good representation of this particular estimation. If something doesn’t make sense, remove it.
After that you are done.

I advice to revisit the table once per 4-6 months unless something big changed in the team like for example team composition.