Knowledge

Transitioning to Relative Estimation

Agile approaches use relative estimations to size requirements during the planning phase. Instead of the traditional man/days measure, you use story points that follow a Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, 34, … Playing “planning poker” allows the team to attribute story points to each user stories the requirements backlog. In this blog post, Ilan Goldstein explains how you can transition from a traditional estimation technique to relative estimation.

When you transition to relative estimating with your project team, your goal is to reduce ambiguity and subjectivity as much as possible. The process proposed in this post if the following:
1) Create a set of time man/hours ranges that map to the relevant story point values
2) Go through previous work with your team and determine how many man/hours each old feature took
3) Based on the story point values defined above categorise old features based on the times identified in step (2). Example: old “Feature XYZ” becomes a reference story with a point value of 8.
4) Continue this until you have a corresponding feature for each value in your planning poker points value

You can now start playing planning poker with the new user stories by comparing them to the reference stories, throwing away the time calibrations. As a final step, once a user story is finished, you can track the hours worked to see how close we were to the original calibration time ranges to see if you need to adapt it.